solarwind wrote:
> Does anyone have any idea how I can have a 64 bit floating point type
> in HI-TECH C or Microchip C18?
>
Sadly I think the only way is to define a structure with sufficiant
storage and then write your own functions/macros to work on it.
On Sat, Jan 10, 2009 at 9:29 PM, peter green <spam_OUTplugwashTakeThisOuTp10link.net> wrote:
> Sadly I think the only way is to define a structure with sufficiant
> storage and then write your own functions/macros to work on it.
Thanks for your reply. Looks like it's time to switch to PIC32 as
their C32 compiler supports 64 bit long double data types - just what
I need. I ordered my PIC32 chip in December, still has not arrived...
--
solarwind
It would probably be easiest to take someone's existing library and
adapt it. For example, one could take floating point libraries written
for other processors and port them to a PIC. Alternatively, one could
take PIC floating point libraries and modify them to work with a 64bit
float (often called a "double" in C). I think that one of these
approaches is probably much easier than starting from scratch.
Sean
On Sat, Jan 10, 2009 at 9:29 PM, peter green <.....plugwashKILLspam@spam@p10link.net> wrote:
> solarwind wrote:
>> Does anyone have any idea how I can have a 64 bit floating point type
>> in HI-TECH C or Microchip C18?
>>
> Sadly I think the only way is to define a structure with sufficiant
> storage and then write your own functions/macros to work on it.
>
>
>
> -
On Sat, Jan 10, 2009 at 11:13 PM, Sean Breheny <shb7KILLspamcornell.edu> wrote:
> It would probably be easiest to take someone's existing library and
> adapt it. For example, one could take floating point libraries written
> for other processors and port them to a PIC. Alternatively, one could
> take PIC floating point libraries and modify them to work with a 64bit
> float (often called a "double" in C). I think that one of these
> approaches is probably much easier than starting from scratch.
>
> Sean
When I started this calculator project, I was totally not expecting to
be writing floating point libraries from scratch - in assembler. What
a nightmare. This would also force me to program my entire application
in assembler as well. I'd rather wait for my PIC32 to arrive, grab
Microchip's PIC C 32 and use its 64 bit floating point math library.
--
solarwind
The whole point of my reply was to suggest that you NOT write your
library from scratch but rather modify someone else's library. I would
think that you could find ones written in C.
Even if you wrote one in assembler, that would not force you to write
the rest of your code in asm. You can link together asm and C modules.
That being said, if the C32 compiler supports this natively, then I
agree that that's the best way to go.
By the way, have you verified that the 64 bit double has enough
precision for your calculator app? Note that there are several
standards for floating point numbers and that "long double" doesn't
mean the same thing for all systems. For example, I think on PCs a
"long double" is usually 80 bits.
> On Sat, Jan 10, 2009 at 11:13 PM, Sean Breheny <EraseMEshb7spam_OUTTakeThisOuTcornell.edu> wrote:
>> It would probably be easiest to take someone's existing library and
>> adapt it. For example, one could take floating point libraries written
>> for other processors and port them to a PIC. Alternatively, one could
>> take PIC floating point libraries and modify them to work with a 64bit
>> float (often called a "double" in C). I think that one of these
>> approaches is probably much easier than starting from scratch.
>>
>> Sean
>
> When I started this calculator project, I was totally not expecting to
> be writing floating point libraries from scratch - in assembler. What
> a nightmare. This would also force me to program my entire application
> in assembler as well. I'd rather wait for my PIC32 to arrive, grab
> Microchip's PIC C 32 and use its 64 bit floating point math library.
> --
> solarwind
On Sat, Jan 10, 2009 at 11:51 PM, Sean Breheny <shb7spam_OUTcornell.edu> wrote:
> Hi solarwind,
>
> The whole point of my reply was to suggest that you NOT write your
> library from scratch but rather modify someone else's library. I would
> think that you could find ones written in C.
>
> Even if you wrote one in assembler, that would not force you to write
> the rest of your code in asm. You can link together asm and C modules.
>
> That being said, if the C32 compiler supports this natively, then I
> agree that that's the best way to go.
>
> By the way, have you verified that the 64 bit double has enough
> precision for your calculator app? Note that there are several
> standards for floating point numbers and that "long double" doesn't
> mean the same thing for all systems. For example, I think on PCs a
> "long double" is usually 80 bits.
>
> Sean
Thanks! Searching now!
Tell me if I'm right:
Ok, according to wikipedia
(http://en.wikipedia.org/wiki/Floating_point), the IEE 754 64-bit
floating point has a 52 bit mantissa. Since the first bit is implied,
we can say 54 bits mantissa, that is, 54 bits of precision. So: 1111
1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 11 in
binary = 16777215 in decimal which is 8 decimal digits of precision
(including implied 1 on most significant bit) and more than enough
exponent range to keep me happy. I would easily go with a 128 bit
floating point if I find any.
Update: my mistake, the calculation is wrong. With 54 bits, the
maximum value I can have is 18014398509481983 which is 17 digits.
Update: quote from wikipedia:
* Single precision, called "float" in the C language family, and
"real" or "real*4" in Fortran. This is a binary format that occupies
32 bits (4 bytes) and its significand has a precision of 24 bits
(about 7 decimal digits).
* Double precision, called "double" in the C language family, and
"double precision" or "real*8" in Fortran. This is a binary format
that occupies 64 bits (8 bytes) and its significand has a precision of
53 bits (about 16 decimal digits).
They say around 16 digits for 64 bit float, but it was 17 in my
calculation. They're saying 7 digits for 32 bit float but I got 8 in
my calculation.
HI-TECH C is using 24 bit float (I'm having problems with their 32 bit
option) and in their manual it says they have a 15 bit mantissa and
the MSB is implied, therefore I should get at least 5 digits of
precision. When I compute sin 60 degrees, the answer should be
0.866025404 but I'm only getting 0.8660xxx... where the x are
incorrect digits. Odd...
I'd suggest that you read the entire wikipedia article on floating
point which you linked to earlier. It raises several issues with
floating point accuracy which may be relevant here.
It is possible that the sin(x) function in Hi-Tech is not written
optimally. It is also possible that one of the other floating point
precision issues is at work here.
Sean
On Sun, Jan 11, 2009 at 12:29 AM, solarwind <@spam@x.solarwind.xKILLspamgmail.com> wrote:
> HI-TECH C is using 24 bit float (I'm having problems with their 32 bit
> option) and in their manual it says they have a 15 bit mantissa and
> the MSB is implied, therefore I should get at least 5 digits of
> precision. When I compute sin 60 degrees, the answer should be
> 0.866025404 but I'm only getting 0.8660xxx... where the x are
> incorrect digits. Odd...
>
>
> --
> solarwind
> -
On Sun, Jan 11, 2009 at 12:29 AM, solarwind <KILLspamx.solarwind.xKILLspamgmail.com> wrote:
> HI-TECH C is using 24 bit float (I'm having problems with their 32 bit
> option) and in their manual it says they have a 15 bit mantissa and
> the MSB is implied, therefore I should get at least 5 digits of
> precision. When I compute sin 60 degrees, the answer should be
> 0.866025404 but I'm only getting 0.8660xxx... where the x are
> incorrect digits. Odd...
>
>
> --
> solarwind
> -
> Update: my mistake, the calculation is wrong. With 54 bits, the
> maximum value I can have is 18014398509481983 which is 17 digits.
>
> Update: quote from wikipedia:
>
> * Single precision, called "float" in the C language family, and
> "real" or "real*4" in Fortran. This is a binary format that occupies
> 32 bits (4 bytes) and its significand has a precision of 24 bits
> (about 7 decimal digits).
>
> * Double precision, called "double" in the C language family, and
> "double precision" or "real*8" in Fortran. This is a binary format
> that occupies 64 bits (8 bytes) and its significand has a precision of
> 53 bits (about 16 decimal digits).
>
> They say around 16 digits for 64 bit float, but it was 17 in my
> calculation. They're saying 7 digits for 32 bit float but I got 8 in
> my calculation.
when you look at the number 18014398509481983 you see 17 digits but this
is the largest number that 54 bits can hold. You could not store
18014398509481984 in this 54 bit field, likewise you could not store
28014398509481983. So when counting digits, loot at all the positions
where you can store ALL possible decimal digits i.e. 0..9 In other words,
54 bits can hold
0000000000000000
to
9999999999999999
and not
0xxxxxxxxxxxxxxxx
to
9xxxxxxxxxxxxxxxx
It doesn't appear to be designed with a microcontroller in mind, but
it does support up to 149 digits of accuracy (62 BYTE mantissa, if I
read the intro page correctly!)
solarwind wrote:
> HI-TECH C is using 24 bit float (I'm having problems with their 32 bit
> option) and in their manual it says they have a 15 bit mantissa and
> the MSB is implied, therefore I should get at least 5 digits of
> precision. When I compute sin 60 degrees, the answer should be
> 0.866025404 but I'm only getting 0.8660xxx... where the x are
> incorrect digits. Odd...
>
Probaly "just enough" for the applications that
the actual tools (PIC and the compiler) was ment
for in the first place. That is, *not* a "calculator".
I'd think that most calculators uses some fixed
point BCD or decimal arithmetic to get a constant
and predictable precision and known (or none?)
rounding errors.
> I'd think that most calculators uses some fixed point BCD or decimal
> arithmetic to get a constant and predictable precision and known (or
> none?) rounding errors.
You always have rounding errors when expressing irrational and infinite
rational numbers in a format with limited precision and finite rational
numbers in a format with less precision than the number requires.
How these rounding errors (which after the conversion into the used
format usually are below the last significant digit) propagate depends
on the algorithms used. With some calculations, these initially
invisible errors can be quite quickly propagate up in significance.
Think just of difference... a single difference in an algorithm can pull
your rounding error from past the 17th decimal (if you're calculating
with 17 decimals) into the 10th easily. Or further up.
Gerhard Fiedler wrote:
> You wrote:
>
>> I'd think that most calculators uses some fixed point BCD or decimal
>> arithmetic to get a constant and predictable precision and known (or
>> none?) rounding errors.
>
> You always have rounding errors when expressing irrational and infinite
> rational numbers in a format with limited precision and finite rational
> numbers in a format with less precision than the number requires.
>
> How these rounding errors (which after the conversion into the used
> format usually are below the last significant digit) propagate depends
> on the algorithms used. With some calculations, these initially
> invisible errors can be quite quickly propagate up in significance.
> Think just of difference... a single difference in an algorithm can pull
> your rounding error from past the 17th decimal (if you're calculating
> with 17 decimals) into the 10th easily. Or further up.
>
> Gerhard
Anyway, these issues are usualy more thought over in the
software for a "calculator" than it usualy is in the
standard floating point library functions in compilers for
microcontrollers. Which was my point.
solarwind wrote:
> Does anyone have any idea how I can have a 64 bit floating point type
> in HI-TECH C or Microchip C18?
Consult the manual. All supported data types are listed. It's either
supported or not, probably not. Microcontrollers generaly deal with real
world measurements where even 32 bit floating point is overkill. I wouldn't
be surprised if it's not implemented because they didn't want to waste time
on something nobody would care about.
Since you're making a calculator, you probably need your own wider
representation anways. Calculators often work in a decimal representation.
That minimizes rounding that looks strange in decimal, and avoids conversion
for display. Decimal takes more cycles to manipulate, but just about
anything will look instantaneous in human time.
You probably want something like 10 to 12 digit numbers. Since you only
need to store a few of them, you can use a whole byte for each 0-9 digit and
one more byte for the exponent. Writing basic arithmetic routines for this
number format will be a good learning experience.
solarwind wrote:
> When I started this calculator project, I was totally not expecting to
> be writing floating point libraries from scratch - in assembler.
I don't see why not. In fact, I think this was pointed out to you.
> This would also force me to program my entire application
> in assembler as well.
Huh? Where did you get that from? You can write assembler routines that
are C callable. Also, you could write your arithmetic library in C.
solarwind wrote:
> When I compute sin 60 degrees, the answer should be
> 0.866025404 but I'm only getting 0.8660xxx... where the x are
> incorrect digits. Odd...
Not odd, roundoff error. It takes a bunch of calculations to do SIN, and
the errors can accumulate.
> Since you're making a calculator, you probably need your own wider
> representation anways. Calculators often work in a decimal
> representation.
> That minimizes rounding that looks strange in decimal, and avoids
> conversion
> for display. Decimal takes more cycles to manipulate, but just about
> anything will look instantaneous in human time.
Amen to this. I strongly recommend a decimal format for a calculator. The
experts seem to agree. For example the both TI-83/84 and TI-89 families use
a decimal representation internally.
> You probably want something like 10 to 12 digit numbers. Since you only
> need to store a few of them, you can use a whole byte for each 0-9 digit
> and
> one more byte for the exponent.
I would disagree here. You will need many coefficients for computing series
for things like SIN(x) and a two-digit-per-byte representation would make
sense. However, I would convert to one-digit-per-byte for the actual
computations.
>Writing basic arithmetic routines for this
> number format will be a good learning experience.
> sergio masci wrote:
>> when you look at the number 18014398509481983 you see 17 digits but
>> this is the largest number that 54 bits can hold.
>
> Log10(2**54) = 16.26, so "16 digits" is the correct answer.
>
Exactly. Where I think solarwind went wrong here is thinking that because
*some* 17 digit numbers are representable he has 17 digits of precision.
This is of course wrong. He had the same problem thinking that 15 bits
should give him 5 digits precision, but, of course 15 bits is limited to a
maximum value of 65536, which is only 4+ digits long.
Bob Ammerman wrote:
> Olin (I think) wrote:
> > Since you're making a calculator, you probably need your own wider
> > representation anways. Calculators often work in a decimal
> > representation. That minimizes rounding that looks strange in decimal,
> > and avoids conversion for display. Decimal takes more cycles to
> > manipulate, but just about anything will look instantaneous in human
> > time.
>
> Amen to this. I strongly recommend a decimal format for a calculator.
> The experts seem to agree. For example the both TI-83/84 and TI-89
> families use a decimal representation internally.
Indeed, many of the earlier 8-bit microprocessor architectures had explicit
support for "packed BCD" (two decimal digits per byte) arithmetic, either
through a separate set of decimal add/subtract instructions, a decimal
arithmetic "mode" for the ALU, or by the use of an extra "half-carry"
status flag and an "adjustment" instruction that got used after any of the
normal binary arithmetic instructions.
There was even at least one architecture (I forget which one) that
supported doing arithmetic directly on ASCII digit characters, but frankly,
I never saw the point of that, and obviously, it never caught on elsewhere.
It had both "DAA" (decimal adjust for arithmetic) and "AAA" (ASCII adjust
for arithmetic) instructions.
Anyway, I echo the recommendation to implement a packed-decimal arithmetic
library for the calculator, and the 8-bit PICs do at least include a
"digit carry" (DC) status bit to aid with that, although you need to write
explicit code to take advantage of it (an exercise left for the reader).
> Indeed, many of the earlier 8-bit microprocessor architectures had explicit
> support for "packed BCD" (two decimal digits per byte) arithmetic, either
> through a separate set of decimal add/subtract instructions, a decimal
> arithmetic "mode" for the ALU, or by the use of an extra "half-carry"
> status flag and an "adjustment" instruction that got used after any of the
> normal binary arithmetic instructions.
>
> There was even at least one architecture (I forget which one) that
> supported doing arithmetic directly on ASCII digit characters, but frankly,
> I never saw the point of that, and obviously, it never caught on elsewhere.
> It had both "DAA" (decimal adjust for arithmetic) and "AAA" (ASCII adjust
> for arithmetic) instructions.
>
> Anyway, I echo the recommendation to implement a packed-decimal arithmetic
> library for the calculator, and the 8-bit PICs do at least include a
> "digit carry" (DC) status bit to aid with that, although you need to write
> explicit code to take advantage of it (an exercise left for the reader).
>
> -- Dave Tweed
On Sun, Jan 11, 2009 at 2:08 AM, Sean Breheny <spamBeGoneshb7spamBeGonecornell.edu> wrote:
> I'd suggest that you read the entire wikipedia article on floating
> point which you linked to earlier. It raises several issues with
> floating point accuracy which may be relevant here.
>
> It is possible that the sin(x) function in Hi-Tech is not written
> optimally. It is also possible that one of the other floating point
> precision issues is at work here.
>
> Sean
Probably not written optimally. Time to compare taylor series with
cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't
take long at all.
16 digits is MORE than enough for me. Every pocket scientific
calculator I have encountered shows up to 10 digits with a 2 digit
exponent. That's all I need.
On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <RemoveMErammermanTakeThisOuTverizon.net> wrote:
> Amen to this. I strongly recommend a decimal format for a calculator. The
> experts seem to agree. For example the both TI-83/84 and TI-89 families use
> a decimal representation internally.
Got any links to what exactly this decimal representation is and how it works?
>> It is possible that the sin(x) function in Hi-Tech is not written
>> optimally. It is also possible that one of the other floating point
>> precision issues is at work here.
This sort of issue is why the IEEE floating point standards specify
that intermediate calculations should be performed with greater
precision (typically 80 bits) than the size of the data type
involved. It's not surprising that a 24bit FP number would end up
with some significant error in a SIN calculation if all the
intermediate calculations are also done with 24bit FP.
You might want to find a book on "numerical methods"; a good one
should cover some of the details on how errors accumulate, how to
predict the maximum error, and so on. (It's been a long time. I
don't recall that there was much discussion on how to minimize such
errors, or if that's even possible...)
>Indeed, many of the earlier 8-bit microprocessor architectures
>had explicit support for "packed BCD" (two decimal digits per
>byte) arithmetic, either through a separate set of decimal
>add/subtract instructions, a decimal arithmetic "mode" for
>the ALU, or by the use of an extra "half-carry" status flag
>and an "adjustment" instruction that got used after any of
>the normal binary arithmetic instructions.
The 14 bit control word 16F range has a half carry flag, I don't know if it
has been carried through into the PIC30 family and derivatives (I believe
the 18F range has it, but haven't checked).
>There was even at least one architecture (I forget which one)
>that supported doing arithmetic directly on ASCII digit characters,
>but frankly, I never saw the point of that, and obviously, it
>never caught on elsewhere. It had both "DAA" (decimal adjust
>for arithmetic) and "AAA" (ASCII adjust for arithmetic) instructions.
I worked on a small business machine from a company called Qantel, that
worked on ASCII digits. Because it was designed for business use it made
sense to do it that way. The CPU architecture was built around bit slice
chips, the early ones used 74 series ALU, the later ones used 2901 bit slice
units.
But the chip that Dave remembers I am fairly sure was the original 8086
family. I do remember seeing the instructions listed.
>> There was even at least one architecture (I forget which one)
>> that supported doing arithmetic directly on ASCII digit characters,
>> but frankly, I never saw the point of that,
IIRC, COBOL supported data types along those lines, and the odder
instructions ended up in architectures so that the architectures could
better support COBOL.
COBOL, of course, wanted exact BCD-like data types so that dollars and
cents wouldn't accidentally get lost due to floating point roundoff
errors. Or something like that.
> The 14 bit control word 16F range has a half carry flag, I don't
> know if it has been carried through into the PIC30 family and
> derivatives (I believe the 18F range has it, but haven't checked)
18F has DC, as well as the helpful DAW instruction, which can be
used, for example to make DC a low nybble carry in eg decimal
additions
solarwind wrote:
> Probably not written optimally. Time to compare taylor series with
> cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't
> take long at all.
You can probably run a 8 bit PIC at 20MHz and still not have it take long at
all in human terms. You've probably got around 300mS before anyone even
begins to get annoyed that SIN or COS or any other complicated trancendental
function returns a answer. Even for simple things like add, subtract,
multiply, divide, etc, you've probably got 100mS.
> On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <rammermanEraseME.....verizon.net>
> wrote:
>> Amen to this. I strongly recommend a decimal format for a calculator. The
>> experts seem to agree. For example the both TI-83/84 and TI-89 families
>> use
>> a decimal representation internally.
>
> Got any links to what exactly this decimal representation is and how it
> works?
>
>
> --
> solarwind
solarwind wrote:
> Got any links to what exactly this decimal representation is and how
> it works?
You can find links yourself, but basically you manipulate strings of numbers
in the 0-9 range. Each of these numbers represents one decimal digit.
For ease of manipulation, I'd probably use whole bytes for each digit as the
common format of the math routines. As Bob suggested, you can store
constants more compactly and expand them on the fly into these byte per
digit numbers when you need them.
> solarwind wrote:
>
>> HI-TECH C is using 24 bit float (I'm having problems with their 32 bit
>> option) and in their manual it says they have a 15 bit mantissa and
>> the MSB is implied, therefore I should get at least 5 digits of
>> precision. When I compute sin 60 degrees, the answer should be
>> 0.866025404 but I'm only getting 0.8660xxx... where the x are
>> incorrect digits. Odd...
>>
>>
>
> Probaly "just enough" for the applications that
> the actual tools (PIC and the compiler) was ment
> for in the first place. That is, *not* a "calculator".
>
> I'd think that most calculators uses some fixed
> point BCD or decimal arithmetic to get a constant
> and predictable precision and known (or none?)
> rounding errors.
>
> Jan-Erik.
>
The old 8-bit personal computers used packed BCD floating point math. It
is a good option for a calculator because it will preserve the precision
of the user input.
For instance, a binary floating point type cannot represent 0.1 (one
tenth) exactly.
Try this:
long i;
float f;
for( i = 1000000, f = 0.0; i; i-- )
f += 0.1;
printf( "1000000 x 0.1 = %f", f );
With packed BCD floats you will get exactly two decimal digits per byte
in the mantissa.
Best regards,
Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/
I havent been following this thread, basically due to who started it. But I wonder...has anyone asked....what is the OP trying to do? Sometimes the application calls for a different processor.
On Mon, Jan 12, 2009 at 12:51 PM, alan smith <EraseMEmicro_eng2yahoo.com> wrote:
> I havent been following this thread, basically due to who started it. But I wonder...has anyone asked....what is the OP trying to do? Sometimes the application calls for a different processor.
He's building a calculator. The processor selection took place in
many, many threads a month or three ago - I imagine if you did a
search over the archive you can check out the discussions that
resulted.
-Adam
--
Please rate and vote for my contest entry:
mypic32.com/web/guest/profiles?profileID=50331
As many others here are indicating, and as you discovered when you did
your SIN output test, math libraries leave much to be desired.
Even though it looks good to say that with 64 bits you get such and
such precision, you need to ask yourself whether the operations you
will be perfroming actually handle that precision (SIN might downgrade
your 64 bit into a 32 bit or worse).
You probably don't need to worry about precision right now, though.
Build the calculator so it can use any set of functions or libraries
and switch it out later. I can almost gaurantee that you'll be wishing
you had made it more modular as you get near the end.
-Adam
On Sat, Jan 10, 2009 at 5:35 PM, solarwind <RemoveMEx.solarwind.xEraseMEEraseMEgmail.com> wrote:
> Does anyone have any idea how I can have a 64 bit floating point type
> in HI-TECH C or Microchip C18?
>
> --
> solarwind
> -
> On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <RemoveMErammermanspam_OUTKILLspamverizon.net> wrote:
> > Amen to this. I strongly recommend a decimal format for a calculator. The
> > experts seem to agree. For example the both TI-83/84 and TI-89 families use
> > a decimal representation internally.
>
> Got any links to what exactly this decimal representation is and how it works?
Slow down there solarwind, you're just exchanging one set of problems for
another.
It is clear from your posts that all this computer maths stuff is a little
beyond you at this time. I'm not saying that you're stupid just that
you don't have the knowedge yet AND this isn't something you can pick up
in five minutes.
As others have already said, try to find and use existing libraries. You
have said that you don't want to do a lot of work converting these but if
this is true I can see that there is a stack of other work which you will
not want to do if you choose NOT to use someone elses libraries.
Go with simple IEEE 745 single precision (32 bit) for now. Get your
calculator going with limited precision and show it off. Feel good about
what you've accomplished and then decide if you really want to spend your
time making your calculator more accurate or if you'd prefer to start
another more interesting project.
On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <RemoveMEsmplxTakeThisOuTspamallotrope.net> wrote:
> Slow down there solarwind, you're just exchanging one set of problems for
> another.
>
> It is clear from your posts that all this computer maths stuff is a little
> beyond you at this time. I'm not saying that you're stupid just that
> you don't have the knowedge yet AND this isn't something you can pick up
> in five minutes.
Who ever said I want to do it in five minutes? I don't care how long
this project takes, but I'll do it. I'll learn whatever I need to as I
go along. So far, I went from knowing next to nothing about pic
microcontrollers and microcontroller asm to almost thoroughly
understanding the assembler part, the instructions and I even managed
to get UART, SPI, I2C, parallel and driving my LCD exactly the way I
want it. In both C AND ASM. Now I just learned about floating point
arithmetic and will be working with MAPM for a while.
> As others have already said, try to find and use existing libraries. You
> have said that you don't want to do a lot of work converting these but if
> this is true I can see that there is a stack of other work which you will
> not want to do if you choose NOT to use someone elses libraries.
I totally understand what you're saying, but precision is important.
I'll be porting over MAPM.
> Go with simple IEEE 745 single precision (32 bit) for now. Get your
> calculator going with limited precision and show it off. Feel good about
> what you've accomplished and then decide if you really want to spend your
> time making your calculator more accurate or if you'd prefer to start
> another more interesting project.
I wont be using anything less than a 64 bit floating point or MAPM.
All that's left to do with the calculator is keypad scanning and these
math operations. Everything else is working fine. I can even interact
with the calculator via UART. I made the thing on a prototyping board
and put UART headers and hooked up LCD. I can use it like a normal RPN
calculator (with 24 bit float) from my PC keyboard.
>As many others here are indicating, and as you discovered
>when you did your SIN output test, math libraries leave
>much to be desired.
>
>Even though it looks good to say that with 64 bits you get
>such and such precision, you need to ask yourself whether
>the operations you will be perfroming actually handle that
>precision (SIN might downgrade your 64 bit into a 32 bit
>or worse).
See the hpmuseum link below for accuracy of early computers.
A very good example of this is the HP35 calculator, which originally had ROM
chips that were too small for them to fit in a full length transcendental
function set, so several least significant digits had errors in them when
doing functions such as SIN(). Later when larger ROMs became available HP
gave a free upgrade.
Good grief, it came out in 1972. I still remember all the hype, with it
being the first hand held scientific calculator. Still have a copy of the HP
journal somewhere with the write up on it. This http://en.wikipedia.org/wiki/HP-35 link has a reference to an online copy,
down the bottom.
Also the last link on the Wikipedia page has some further info on Cordic
algorithms and the ROM bug.
It's funny you mention that. A previous coworker loves his HP15c, but
at one point needed to do calculations beyond what it was capable of
doing in terms of significant digits.
He wrote an emulator for it, and used MAPM to give himself 180
significant digits, among other changes:
>>As many others here are indicating, and as you discovered
>>when you did your SIN output test, math libraries leave
>>much to be desired.
>>
>>Even though it looks good to say that with 64 bits you get
>>such and such precision, you need to ask yourself whether
>>the operations you will be perfroming actually handle that
>>precision (SIN might downgrade your 64 bit into a 32 bit
>>or worse).
>
> See the hpmuseum link below for accuracy of early computers.
>
> A very good example of this is the HP35 calculator, which originally had ROM
> chips that were too small for them to fit in a full length transcendental
> function set, so several least significant digits had errors in them when
> doing functions such as SIN(). Later when larger ROMs became available HP
> gave a free upgrade.
>
> See bottom of page http://members.chello.cz/eckstein/HP-35RD.html for some
> details. See also http://www.hpmuseum.org/hp35.htm for more information.
>
> Good grief, it came out in 1972. I still remember all the hype, with it
> being the first hand held scientific calculator. Still have a copy of the HP
> journal somewhere with the write up on it. This
> http://en.wikipedia.org/wiki/HP-35 link has a reference to an online copy,
> down the bottom.
>
> Also the last link on the Wikipedia page has some further info on Cordic
> algorithms and the ROM bug.
>
> On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <RemoveMEsmplxKILLspamallotrope.net> wrote:
> > Slow down there solarwind, you're just exchanging one set of problems for
> > another.
> >
> > It is clear from your posts that all this computer maths stuff is a little
> > beyond you at this time. I'm not saying that you're stupid just that
> > you don't have the knowedge yet AND this isn't something you can pick up
> > in five minutes.
>
> Who ever said I want to do it in five minutes? I don't care how long
> this project takes, but I'll do it. I'll learn whatever I need to as I
> go along.
On Mon, 2009-01-12 at 07:23 -0500, Olin Lathrop wrote:
> solarwind wrote:
> > Probably not written optimally. Time to compare taylor series with
> > cordic. If I run a 32 bit PIC at 80 MHz for one computation, shouldn't
> > take long at all.
>
> You can probably run a 8 bit PIC at 20MHz and still not have it take long at
> all in human terms. You've probably got around 300mS before anyone even
> begins to get annoyed that SIN or COS or any other complicated trancendental
> function returns a answer. Even for simple things like add, subtract,
> multiply, divide, etc, you've probably got 100mS.
FWIW, even some modern calculators can take a while. A friend of mine
had a calculator that took nearly a second when involving certain
functions (sin/cos/tan come to mind, ln/log I believe as well).
> FWIW, even some modern calculators can take a while. A friend of mine
> had a calculator that took nearly a second when involving certain
> functions (sin/cos/tan come to mind, ln/log I believe as well).
The compute time in some of the calculator 30 years ago is legendary.
Sinclair made a calculator that used a bit serial processor. One of the
trig functions took 8 minutes and generally got the wrong answer.
On Mon, Jan 12, 2009 at 3:27 PM, solarwind <spamBeGonex.solarwind.xSTOPspamEraseMEgmail.com> wrote:
> On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <KILLspamsmplxspamBeGoneallotrope.net> wrote:
>
>> Go with simple IEEE 745 single precision (32 bit) for now. Get your
>> calculator going with limited precision and show it off. Feel good about
>> what you've accomplished and then decide if you really want to spend your
>> time making your calculator more accurate or if you'd prefer to start
>> another more interesting project.
>
> I wont be using anything less than a 64 bit floating point or MAPM.
> All that's left to do with the calculator is keypad scanning and these
> math operations. Everything else is working fine. I can even interact
> with the calculator via UART. I made the thing on a prototyping board
> and put UART headers and hooked up LCD. I can use it like a normal RPN
> calculator (with 24 bit float) from my PC keyboard.
>
> On Mon, Jan 12, 2009 at 3:27 PM, solarwind <@spam@x.solarwind.x@spam@spam_OUTgmail.com> wrote:
> > On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <spamBeGonesmplxKILLspamallotrope.net> wrote:
> >
> >> Go with simple IEEE 745 single precision (32 bit) for now. Get your
> >> calculator going with limited precision and show it off. Feel good about
> >> what you've accomplished and then decide if you really want to spend your
> >> time making your calculator more accurate or if you'd prefer to start
> >> another more interesting project.
> >
> > I wont be using anything less than a 64 bit floating point or MAPM.
> > All that's left to do with the calculator is keypad scanning and these
> > math operations. Everything else is working fine. I can even interact
> > with the calculator via UART. I made the thing on a prototyping board
> > and put UART headers and hooked up LCD. I can use it like a normal RPN
> > calculator (with 24 bit float) from my PC keyboard.
> >
>
> Hey, IEEE float was good enough for Microsoft:
>
> http://blogs.msdn.com/oldnewthing/archive/2004/05/25/141253.aspx
> Probaly "just enough" for the applications that
> the actual tools (PIC and the compiler) was ment
> for in the first place. That is, *not* a "calculator".
>
> I'd think that most calculators uses some fixed
> point BCD or decimal arithmetic to get a constant
> and predictable precision and known (or none?)
> rounding errors.
>
> Jan-Erik.
JE, I get this message added right after every single message you posted
for the last few days. It seems stuck in your outbox?
--
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
Wouter van Ooijen wrote:
>> Probaly "just enough" for the applications that
>> the actual tools (PIC and the compiler) was ment
>> for in the first place. That is, *not* a "calculator".
>>
>> I'd think that most calculators uses some fixed
>> point BCD or decimal arithmetic to get a constant
>> and predictable precision and known (or none?)
>> rounding errors.
>>
>> Jan-Erik.
>
> JE, I get this message added right after every single message you posted
> for the last few days. It seems stuck in your outbox?
>
Nop, it's probably stuck in your inbox... :-)
Serously, has anyone else seen this ? I do not see them,
and I always get a copy of anything I send to the list.
I would thought that I'd had quite a few "complaints"
by now if that would have been the case.
>> JE, I get this message added right after every single message you posted
>> for the last few days. It seems stuck in your outbox?
>>
>
> Nop, it's probably stuck in your inbox... :-)
I think you are right. It must be stuck in Wouter's inbox.
> Serously, has anyone else seen this ? I do not see them,
> and I always get a copy of anything I send to the list.
I do not see them either so I think you are right.
> I would thought that I'd had quite a few "complaints"
> by now if that would have been the case.
>
Wouter van Ooijen wrote:
> JE, I get this message added right after every single message you
> posted for the last few days. It seems stuck in your outbox?
Jan-Erik Soderholm wrote:
> Serously, has anyone else seen this ? I do not see them,
> and I always get a copy of anything I send to the list.
>
> I would thought that I'd had quite a few "complaints"
> by now if that would have been the case.
I just looked at the complete text of your email message, headers and all,
and there is no other hidden message anywhere. It's not multi-part MIME.
The problem is apparently at Wouter's end or possibly with the server, but
it's hard to imagine a email bug that would cause the symptom he described.
I'd really like to hear what it was if it's ever figured out.
A long time ago I had a bug in some email software that was converted from
single threaded to multi-threaded, but not quite correctly. Every once in a
while one message would get snippets of another message interleaved with it.
Oops.
Wouter van Ooijen wrote:
>> Probaly "just enough" for the applications that
>> the actual tools (PIC and the compiler) was ment
>> for in the first place. That is, *not* a "calculator".
>>
>> I'd think that most calculators uses some fixed
>> point BCD or decimal arithmetic to get a constant
>> and predictable precision and known (or none?)
>> rounding errors.
>>
>> Jan-Erik.
>>
>
> JE, I get this message added right after every single message you posted
> for the last few days. It seems stuck in your outbox?
>
>
I received this message some days ago but the date was wrong: a message
from the next week!
Here part of the header:
> Received: from [192.168.1.33] (81.232.163.33) by
> pne-smtpout1-sn1.fre.skanova.net (7.3.129) (authenticated as
> u12103129)
> id 47A97950057FC2D2 for TakeThisOuTpiclist.....TakeThisOuTmit.edu; *Sun, 11 Jan 2009 12:57:09* +0100
> Message-ID: <TakeThisOuT49707613.6020604KILLspamspamtelia.com>
> *Date: Fri, 16 Jan 2009 12:57:07* +0100
> From: Jan-Erik Soderholm <.....jan-erik.soderholmRemoveMEtelia.com>
> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
I noted that some times, maybe the clock of SO was wrong.
On Tue, 2009-01-13 at 18:05 -0500, Walter Banks wrote:
>
> Herbert Graf wrote:
>
> > FWIW, even some modern calculators can take a while. A friend of mine
> > had a calculator that took nearly a second when involving certain
> > functions (sin/cos/tan come to mind, ln/log I believe as well).
>
> The compute time in some of the calculator 30 years ago is legendary.
> Sinclair made a calculator that used a bit serial processor. One of the
> trig functions took 8 minutes and generally got the wrong answer.
Hehe, well that's not very useful! Even today though, some calculators
do certain operations very slowly, while others are lightning fast. It
can get quite annoying when trying to solve long equations.
IIRC my friend's "slow" calculator was a Casio, my "instant" calculator
was a Sharp.
> On Tue, 2009-01-13 at 18:05 -0500, Walter Banks wrote:
>
>> Herbert Graf wrote:
>>
>>
>>> FWIW, even some modern calculators can take a while. A friend of mine
>>> had a calculator that took nearly a second when involving certain
>>> functions (sin/cos/tan come to mind, ln/log I believe as well).
>>>
>> The compute time in some of the calculator 30 years ago is legendary.
>> Sinclair made a calculator that used a bit serial processor. One of the
>> trig functions took 8 minutes and generally got the wrong answer.
>>
>
> Hehe, well that's not very useful! Even today though, some calculators
> do certain operations very slowly, while others are lightning fast. It
> can get quite annoying when trying to solve long equations.
>
> IIRC my friend's "slow" calculator was a Casio, my "instant" calculator
> was a Sharp.
>
> TTYL
>
>
at school we used to have "calculator races"
we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
and it would take it several seconds to come up with the answer, the 2
line calculators were actually slower.
There was even some difference between identical calculators.
>
> at school we used to have "calculator races"
> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
> and it would take it several seconds to come up with the answer, the 2
> line calculators were actually slower.
> There was even some difference between identical calculators.
>
Difference in speed, or difference in answers? Were the answers always the
same?
On Wed, Jan 14, 2009 at 9:48 PM, Marcel Birthelmer
<RemoveMEmarcelb.listsspamBeGonegmail.com> wrote:
> Difference in speed, or difference in answers? Were the answers always the
> same?
Marcel Birthelmer wrote:
>> at school we used to have "calculator races"
>> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
>> and it would take it several seconds to come up with the answer, the 2
>> line calculators were actually slower.
>> There was even some difference between identical calculators.
>>
>>
>
> Difference in speed, or difference in answers? Were the answers always the
> same?
>
yeah answers were the same, it was probably a 10% variance in clock
speed, I always wanted to overclock mine ;->
:: e used to have "calculator races"
:: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
:: and it would take it several seconds to come up with the answer,
:: the 2
Well just for fon I trie that on my Casio fx-5000f - it has
regurgitated the answer of 0.42298298
On Wed, Jan 14, 2009 at 11:39 PM, cdb <TakeThisOuTcolinspambtech-online.co.uk> wrote:
> Well just for fon I trie that on my Casio fx-5000f - it has
> regurgitated the answer of 0.42298298
>
> Colin
> :: e used to have "calculator races"
> :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
> :: and it would take it several seconds to come up with the answer,
> :: the 2
>
> Well just for fon I trie that on my Casio fx-5000f - it has
> regurgitated the answer of 0.42298298
>
> Colin
> --
> cdb, colinEraseMEbtech-online.co.uk on 15/01/2009
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.1and1.co.uk/?k_id=7988359
>
>
>
>
>
>
>
>
On Wed, Jan 14, 2009 at 11:39 PM, cdb <@spam@colinRemoveMEEraseMEbtech-online.co.uk> wrote:
> :: e used to have "calculator races"
> :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
> :: and it would take it several seconds to come up with the answer,
> :: the 2
>
> Well just for fon I trie that on my Casio fx-5000f - it has
> regurgitated the answer of 0.42298298
My calculator just gave me an answer of
0.42298298052002545978980951342094
(calculator in Windows XP).
Which made me think: Since the original question was about
implementing a calculator on a fairly hefty chip, why not look at
the source for the Linux equivalent to "calculator" and use those
algorithms? They have already been vetted, and should give him
all the accuracy he wants?
And FYI: my scientific calculator from the local dollar store gave
me an answer of 0.42298298 as fast as I could press the buttons.
--
Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
> :: e used to have "calculator races"
> :: we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
> :: and it would take it several seconds to come up with the answer,
> :: the 2
>
> Well just for fon I trie that on my Casio fx-5000f - it has
> regurgitated the answer of 0.42298298
>
> Colin
> --
> cdb, EraseMEcolin@spam@btech-online.co.uk on 15/01/2009
>
> Web presence: http://www.btech-online.co.uk
>
> Hosted by: http://www.1and1.co.uk/?k_id=7988359
>
>
>
>
>
>
>
> at school we used to have "calculator races"
> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
> and it would take it several seconds to come up with the answer, the 2
> line calculators were actually slower.
> There was even some difference between identical calculators.
>> at school we used to have "calculator races"
>> we would enter sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
>> and it would take it several seconds to come up with the answer, the 2
>> line calculators were actually slower.
>> There was even some difference between identical calculators.
>
> ( ([sqrt(N)] ^11 ) -1 ) x 889
>
> eg without "aleegraic notation:
>
> 2 sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt sqrt -1 x 889 =
>
> N = 2, 3, 4, ...Then see how close the answer comes to the "right one",
> andhow long it takes.
>
> Starter for 10: points
>
> What does this calculate.
>
> Special credit:
>
> Why / how.?
>
>
>
> Russell
>
>
> That's pretty interesting. Looks like log base 10 to me.
>
> Don't know how ((x^(1/2048))-1)*889 does it though. Explanation?
Step on the journey.
Take N = any power of 2 and do the SQRTing N times and then divide by 2^N *
:-).
AFAIR it surprised Scott D when I raised it some years ago BUT he promptly
dug into it and explained it.
One can probably blithely say something like "power series" and walk away
quickly before anyone notices. Or look for Scott's comments. Or have a play
with what is does after you try the 2^N version above. Light bulbs start to
shine a little.
Note that the 889 and 11 sqrts [squirt 11 times?] was empirically derived to
give best typical accuracy on a typical calculator for small numbers. You
can do more or less sqrts and change the constant to get the correctish
anwer again. If you had infinite precision it would help. A job for
Solarwind's calculator.
Russell
* Clue - log base 2 results if you get divisions and sqrt count correct.
There was a discussion about a week ago about what floating point formats
were used in hand calculators. I ran into a description of the HP 45 calculator
on a website dedicated to HP calculators.
The HP calculator CPUs were optimized for floating point
numbers. Each main register consisted of 14 of 4 bits each
(56 bits per register) This allowed each register to hold a
10 digit mantissa, a 2 digit exponent and signs for the mantissa
and exponent. Each digit or sign occupied 4 bits. This is
commonly referred to as Binary Coded Decimal (BCD)
encoding.
PIC24 based scientific calculator in watch-sized module. All open
source. Available as a kit. 100 Hours of runtime on 2xcr2032
batteries. Runs at 250kHz.
Uses Microchips C30, which apparently includes 64bit floats (makes
sense; it probably uses a generic Gnu floating point library.)
Personally, I hate it when I find someone has already done the
pointless project I had in mind (and gone further than I had intended
on going.) The whole point of doing something pointless was to be
unique. Sigh.
On Wed, Jan 21, 2009 at 10:38 AM, William Chops Westfield
<spamBeGonewestfwEraseMEmac.com> wrote:
> This also cropped up recently on hackaday:
> http://www.calcwatch.com/
>
> PIC24 based scientific calculator in watch-sized module. All open
> source. Available as a kit. 100 Hours of runtime on 2xcr2032
> batteries. Runs at 250kHz.
>
> Uses Microchips C30, which apparently includes 64bit floats (makes
> sense; it probably uses a generic Gnu floating point library.)
>
> Personally, I hate it when I find someone has already done the
> pointless project I had in mind (and gone further than I had intended
> on going.) The whole point of doing something pointless was to be
> unique. Sigh.
>
> BillW
>
Haha! I know what you mean. And THANK YOU for letting me know that C30
has 64 bit float! Since 16 bit PICs are available in DIP packages, it
makes it very easy for use in projects!
This experiment is fun for me, I don't care if people think it's
pointless. To me it has a point.
> The whole point of doing something pointless was to be unique. Sigh
Google's a heartbreaker sometimes innit
OTOH, I've had ideas and then found them on the web. Temporary
collapse of spirits, but often it turns out that what somebody else has
done isn't that good anyway and can be improved significantly
It's in my nature to be inquisitive and inventive so I can take a few
knockbacks because there's always something else needs working
on. Things I know aren't on the web. Doesn't mean they don't exist
but anything worth selling or sharing usually ends up in cyberspace