Exact match. Not showing close matches.
PICList
Thread
'[PIC] 64 Bit Float'
2009\01\10@173558
by
solarwind
Does anyone have any idea how I can have a 64 bit floating point type
in HITECH C or Microchip C18?

solarwind
2009\01\10@213013
by
peter green
solarwind wrote:
> Does anyone have any idea how I can have a 64 bit floating point type
> in HITECH 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.
2009\01\10@224707
by
solarwind
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
2009\01\10@231349
by
Sean Breheny
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 HITECH 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.
>
>
>
> 
2009\01\10@232451
by
solarwind
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
2009\01\10@235158
by
Sean Breheny
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
On Sat, Jan 10, 2009 at 11:24 PM, solarwind <.....x.solarwind.xKILLspam.....gmail.com> wrote:
{Quote hidden}> 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
> 
2009\01\11@001310
by
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 64bit
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.

solarwind
2009\01\11@001941
by
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.
2009\01\11@002048
by
solarwind
They're probably not counting the implied bit in the mantissa?
2009\01\11@002945
by
solarwind
HITECH 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
2009\01\11@020134
by
apptech
With 64 bits FIXED you can get 19 digits, plus sign, FWIW
Russell
2009\01\11@020914
by
Sean Breheny
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 HiTech 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:
> HITECH 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
> 
2009\01\11@021228
by
Sean Breheny
2009\01\11@053501
by
sergio masci

On Sun, 11 Jan 2009, solarwind wrote:
{Quote hidden}> 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
Regards
Sergio
2009\01\11@064708
by
William \Chops\ Westfield
You could look at existing higherprecision floating point libraries
like:
http://www.nongnu.org/hpalib/
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!)
BillW
2009\01\11@065731
by
JanErik Soderholm
solarwind wrote:
> HITECH 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.
JanErik.
2009\01\11@072504
by
Gerhard Fiedler
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
2009\01\11@074027
by
JanErik Soderholm
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.
2009\01\11@093734
by
olin piclist
solarwind wrote:
> Does anyone have any idea how I can have a 64 bit floating point type
> in HITECH 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 09 digit and
one more byte for the exponent. Writing basic arithmetic routines for this
number format will be a good learning experience.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\11@094100
by
olin piclist
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.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\11@094410
by
olin piclist
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.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\11@094851
by
olin piclist
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.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\11@130742
by
Bob Ammerman

> 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 TI83/84 and TI89 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 09 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 twodigitperbyte representation would make
sense. However, I would convert to onedigitperbyte for the actual
computations.
>Writing basic arithmetic routines for this
> number format will be a good learning experience.
Again: amen
 Bob Ammerman
RAm Systems
2009\01\11@130748
by
Bob Ammerman
> 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
RAm Systems
2009\01\11@145238
by
Dave Tweed

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 TI83/84 and TI89
> families use a decimal representation internally.
Indeed, many of the earlier 8bit 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 "halfcarry"
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 packeddecimal arithmetic
library for the calculator, and the 8bit 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
2009\01\11@154707
by
Sean Breheny
I think that the Intel 8086 and 8088 (as well as their progeny) have
all of these instructions (BCD ones and DAA/AAA).
I learned assembly language first on the 8088 and I distinctly
remember wondering what the heck those instructions were for!
Sean
On Sun, Jan 11, 2009 at 2:52 PM, Dave Tweed <RemoveMEpicTakeThisOuTdtweed.com> wrote:
{Quote hidden}> Indeed, many of the earlier 8bit 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 "halfcarry"
> 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 packeddecimal arithmetic
> library for the calculator, and the 8bit 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
> 
2009\01\11@185855
by
solarwind
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 HiTech 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.

solarwind
2009\01\11@190035
by
solarwind
On Sun, Jan 11, 2009 at 9:48 AM, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspam_OUTembedinc.com> wrote:
> Log10(2**54) = 16.26, so "16 digits" is the correct answer.
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.

solarwind
2009\01\11@190149
by
solarwind
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 TI83/84 and TI89 families use
> a decimal representation internally.
Got any links to what exactly this decimal representation is and how it works?

solarwind
2009\01\11@224116
by
andrew kelley
2009\01\12@015941
by
William \Chops\ Westfield
On Jan 11, 2009, at 3:58 PM, solarwind wrote:
>> It is possible that the sin(x) function in HiTech 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...)
BillW
2009\01\12@040917
by
Alan B. Pearce
>Indeed, many of the earlier 8bit 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 "halfcarry" 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.
2009\01\12@044807
by
William \Chops\ Westfield
>> 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 BCDlike data types so that dollars and
cents wouldn't accidentally get lost due to floating point roundoff
errors. Or something like that.
BillW
2009\01\12@055553
by
Jinx
> 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
2009\01\12@072320
by
olin piclist
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.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\12@072528
by
Bob Ammerman
> 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 TI83/84 and TI89 families
>> use
>> a decimal representation internally.
>
> Got any links to what exactly this decimal representation is and how it
> works?
>
>
> 
> solarwind
See:
http://dragonfire.unitedti.org/asmin28/lesson/day18.html
2009\01\12@072717
by
olin piclist
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 09 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.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\12@082502
by
Isaac Marino Bavaresco

JanErik Soderholm escreveu:
{Quote hidden}> solarwind wrote:
>
>> HITECH 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.
>
> JanErik.
>
The old 8bit 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/
2009\01\12@125145
by
alan smith
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.
2009\01\12@132412
by
Walter Banks
Over the weekend I was creating some constant tables
with a EXCEL spreadsheet. The implementation appears
to be IEEE 754 4 byte floats.
Walter Banks
2009\01\12@132707
by
M. Adam Davis
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
2009\01\12@133537
by
M. Adam Davis
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).
Even if you don't go this route, you really need to look into and
understand Arbitrary Precision math:
http://en.wikipedia.org/wiki/Arbitraryprecision_arithmetic
If you want to implement this, here's a free C library that may give
you some ideas:
http://www.tc.umn.edu/~ringx004/mapmmain.html
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 HITECH C or Microchip C18?
>
> 
> solarwind
> 
2009\01\12@144806
by
sergio masci

On Sun, 11 Jan 2009, solarwind wrote:
> 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 TI83/84 and TI89 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.
Regards
Sergio Masci
2009\01\12@162730
by
solarwind

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.
> Regards
> Sergio Masci

solarwind
2009\01\13@041252
by
Alan B. Pearce
>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/HP35RD.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/HP35 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.
2009\01\13@094405
by
M. Adam Davis
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:
http://www.precisionstrobe.com/jc/hp15ce/hp15ce.html
Adam
On Tue, Jan 13, 2009 at 4:12 AM, Alan B. Pearce
<EraseMEAlan.B.PearcespamspamBeGonestfc.ac.uk> wrote:
{Quote hidden}>>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/HP35RD.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/HP35 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.
>
> 
2009\01\13@105355
by
sergio masci
On Mon, 12 Jan 2009, solarwind wrote:
{Quote hidden}> 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.
Ok then. Has anyone refered you to this yet?
http://docs.sun.com/source/8063568/ncg_goldberg.html
It's pretty good and I would recommend you read it if you haven't
aready.
Regards
Sergio Masci
2009\01\13@171101
by
Herbert Graf
On Mon, 20090112 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).
TTYL
2009\01\13@174243
by
solarwind
2009\01\13@180727
by
Walter Banks
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.
w..
2009\01\13@181727
by
Mark Rages
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.
>
Hey, IEEE float was good enough for Microsoft:
http://blogs.msdn.com/oldnewthing/archive/2004/05/25/141253.aspx

Mark Rages, Engineer
Midwest Telecine LLC
EraseMEmarkragesEraseMEmidwesttelecine.com
2009\01\13@182751
by
sergio masci

On Tue, 13 Jan 2009, Mark Rages wrote:
{Quote hidden}> 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
oops: should read IEEE 754
(I do know what floating point is  honest)
Regards
Sergio Masci
2009\01\13@191143
by
Wouter van Ooijen
> 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.
>
> JanErik.
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
2009\01\13@192454
by
JanErik Soderholm
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.
>>
>> JanErik.
>
> 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.
JanErik.
2009\01\13@201922
by
Xiaofan Chen
On Wed, Jan 14, 2009 at 8:24 AM, JanErik Soderholm
<.....janerik.soderholmspam_OUTtelia.com> 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?
>>
>
> 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.
>
Xiaofan
2009\01\14@065839
by
olin piclist
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?
I haven't noticed anything like that here.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\14@070739
by
olin piclist
JanErik 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 multipart 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 multithreaded, but not quite correctly. Every once in a
while one message would get snippets of another message interleaved with it.
Oops.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\14@080818
by
Nicola Perotto

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.
>>
>> JanErik.
>>
>
> 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
> pnesmtpout1sn1.fre.skanova.net (7.3.129) (authenticated as
> u12103129)
> id 47A97950057FC2D2 for TakeThisOuTpiclist.....TakeThisOuTmit.edu; *Sun, 11 Jan 2009 12:57:09* +0100
> MessageID: <TakeThisOuT49707613.6020604KILLspamspamtelia.com>
> *Date: Fri, 16 Jan 2009 12:57:07* +0100
> From: JanErik Soderholm <.....janerik.soderholmRemoveMEtelia.com>
> UserAgent: Thunderbird 2.0.0.19 (Windows/20081209)
I noted that some times, maybe the clock of SO was wrong.
2009\01\14@120256
by
Herbert Graf
On Tue, 20090113 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
2009\01\14@212953
by
Jake Anderson

Herbert Graf wrote:
{Quote hidden}> On Tue, 20090113 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.
2009\01\14@214842
by
Marcel Birthelmer
>
> 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?
2009\01\14@225313
by
solarwind
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?
I'm willing to bet they were.

solarwind
2009\01\14@233444
by
Jake Anderson
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 ;>
2009\01\14@234015
by
cdb
2009\01\15@012833
by
solarwind
2009\01\15@014543
by
Jake Anderson
2009\01\15@050900
by
cdb
2009\01\15@103101
by
William Couture
On Wed, Jan 14, 2009 at 11:39 PM, cdb <@spam@colinRemoveMEEraseMEbtechonline.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 fx5000f  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
2009\01\15@113138
by
Walter Banks
This looked familiar. Two of the tests from our fixed point
sanity tests are similar
The angles in this case are in degrees
// This should return a 7.0 simple accuracy check
r = asin(acos(atan(tan(cos(sin(7.0))))));
// Check loss or precision with small numbers should be 1.0
r = asin(acos(atan(tan(cos(sin(1.0))))));
> sin(cos(tan(sin(cos(tan(sin(cos(tan1)))))))))
Largly tests the implementation of tan whose errors
are generally larger than those created by sin or cos.
Depending on input the result may be very large.
Regards,

Walter Banks
Byte Craft Limited
http://bytecraft.com
cdb wrote:
{Quote hidden}
> 
2009\01\15@211228
by
apptech
> 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
2009\01\15@212752
by
M. Adam Davis
That's pretty interesting. Looks like log base 10 to me.
Don't know how ((x^(1/2048))1)*889 does it though. Explanation?
Adam
On Thu, Jan 15, 2009 at 9:11 PM, apptech <@spam@apptechspam_OUT.....paradise.net.nz> wrote:
{Quote hidden}>> 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
>
>
> 
2009\01\16@005358
by
apptech
> 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.
2009\01\21@092037
by
Walter Banks
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.
http://www.hpmuseum.org/
The following quote is from that site
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.
Regards,

Walter Banks
Byte Craft Limited
http://bytecraft.com
2009\01\21@103920
by
William \Chops\ Westfield
This also cropped up recently on hackaday:
http://www.calcwatch.com/
PIC24 based scientific calculator in watchsized 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
2009\01\21@114339
by
olin piclist
William Chops" Westfield" wrote:
> The whole point of doing something pointless ...
That's a good one.
********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 7429014. Gold level PIC consultants since 2000.
2009\01\21@160031
by
solarwind

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 watchsized 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.

solarwind
2009\01\22@191348
by
Jinx
> 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
More... (looser matching)
 Last day of these posts
 In 2009
, 2010 only
 Today
 New search...