Searching \ for '[PIC] 64 Bit Float' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: '64 Bit Float'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 64 Bit Float'
2009\01\10@173558 by solarwind

picon face
Does anyone have any idea how I can have a 64 bit floating point type
in HI-TECH C or Microchip C18?

--
solarwind

2009\01\10@213013 by peter green

flavicon
face
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.



2009\01\10@224707 by solarwind

picon face
On Sat, Jan 10, 2009 at 9:29 PM, peter green <spam_OUTplugwashTakeThisOuTspamp10link.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

face picon face
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 <.....plugwashKILLspamspam@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.
>
>
>
> -

2009\01\10@232451 by solarwind

picon face
On Sat, Jan 10, 2009 at 11:13 PM, Sean Breheny <shb7spamKILLspamcornell.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

face picon face
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.xKILLspamspam.....gmail.com> wrote:
{Quote hidden}

> -

2009\01\11@001310 by solarwind

picon face
On Sat, Jan 10, 2009 at 11:51 PM, Sean Breheny <shb7spamspam_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.



--
solarwind

2009\01\11@001941 by solarwind

picon face
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

picon face
They're probably not counting the implied bit in the mantissa?

2009\01\11@002945 by solarwind

picon face
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

2009\01\11@020134 by apptech

face
flavicon
face
With 64 bits FIXED you can get 19 digits, plus sign, FWIW

   Russell

2009\01\11@020914 by Sean Breheny

face picon face
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.xKILLspamspamgmail.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
> -

2009\01\11@021228 by Sean Breheny

face picon face
Take a look at:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=61605&start=0

especially the sites it links to:

http://www.diycalculator.com/
http://www2.hursley.ibm.com/decimal/

On Sun, Jan 11, 2009 at 12:29 AM, solarwind <KILLspamx.solarwind.xKILLspamspamgmail.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
> -

2009\01\11@053501 by sergio masci

flavicon
face


On Sun, 11 Jan 2009, solarwind wrote:

{Quote hidden}

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

face picon face
You could look at existing higher-precision 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 Jan-Erik Soderholm

face picon face
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.

2009\01\11@072504 by Gerhard Fiedler

picon face
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 Jan-Erik Soderholm

face picon face


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

face picon face
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.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\01\11@094100 by olin piclist

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\11@094410 by olin piclist

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\11@094851 by olin piclist

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\11@130742 by Bob Ammerman

picon face

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

Again: amen

-- Bob Ammerman
RAm Systems



2009\01\11@130748 by Bob Ammerman

picon face
> 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

face
flavicon
face
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).

-- Dave Tweed

2009\01\11@154707 by Sean Breheny

face picon face
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 <RemoveMEpicTakeThisOuTspamdtweed.com> wrote:
{Quote hidden}

> -

2009\01\11@185855 by solarwind

picon face
On Sun, Jan 11, 2009 at 2:08 AM, Sean Breheny <spamBeGoneshb7spamBeGonespamcornell.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.

--
solarwind

2009\01\11@190035 by solarwind

picon face
On Sun, Jan 11, 2009 at 9:48 AM, Olin Lathrop <TakeThisOuTolin_piclistEraseMEspamspam_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

picon face
On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <RemoveMErammermanspamTakeThisOuTverizon.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

2009\01\11@224116 by andrew kelley

picon face
> Got any links to what exactly this decimal representation is and how it works?
>
>
> --
> solarwind


http://en.wikipedia.org/wiki/Binary-coded_decimal


andrew

2009\01\12@015941 by William \Chops\ Westfield

face picon face

On Jan 11, 2009, at 3:58 PM, solarwind wrote:

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

BillW

2009\01\12@040917 by Alan B. Pearce

face picon face
>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.

2009\01\12@044807 by William \Chops\ Westfield

face picon face
>> 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.

BillW

2009\01\12@055553 by Jinx

face picon face
> 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

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\12@072528 by Bob Ammerman

picon face
> On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <rammermanEraseMEspam.....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

See:

http://dragonfire.unitedti.org/asmin28/lesson/day18.html

2009\01\12@072717 by olin piclist

face picon face
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.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\01\12@082502 by Isaac Marino Bavaresco

flavicon
face
Jan-Erik Soderholm escreveu:
{Quote hidden}

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/

2009\01\12@125145 by alan smith

picon face
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

picon face
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

face picon face
On Mon, Jan 12, 2009 at 12:51 PM, alan smith <EraseMEmicro_eng2spamyahoo.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

face picon face
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/Arbitrary-precision_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/mapm-main.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.xEraseMEspamEraseMEgmail.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
> -

2009\01\12@144806 by sergio masci

flavicon
face


On Sun, 11 Jan 2009, solarwind wrote:

> On Sun, Jan 11, 2009 at 1:02 PM, Bob Ammerman <RemoveMErammermanspam_OUTspamKILLspamverizon.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.

Regards
Sergio Masci

2009\01\12@162730 by solarwind

picon face
On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <RemoveMEsmplxTakeThisOuTspamspamallotrope.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

face picon face
>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.

2009\01\13@094405 by M. Adam Davis

face picon face
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.PearcespamspamspamBeGonestfc.ac.uk> wrote:
{Quote hidden}

> -

2009\01\13@105355 by sergio masci

flavicon
face


On Mon, 12 Jan 2009, solarwind wrote:

{Quote hidden}

Ok then. Has anyone refered you to this yet?

http://docs.sun.com/source/806-3568/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

flavicon
face
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).

TTYL

2009\01\13@174243 by solarwind

picon face
On Tue, Jan 13, 2009 at 1:32 PM, sergio masci <smplxSTOPspamspamspam_OUTallotrope.net> wrote:
> http://docs.sun.com/source/806-3568/ncg_goldberg.html
>
> Regards
> Sergio Masci

Thanks.

--
solarwind

2009\01\13@180727 by Walter Banks

picon face


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

face picon face
On Mon, Jan 12, 2009 at 3:27 PM, solarwind <spamBeGonex.solarwind.xSTOPspamspamEraseMEgmail.com> wrote:
> On Mon, Jan 12, 2009 at 5:26 PM, sergio masci <KILLspamsmplxspamBeGonespamallotrope.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
EraseMEmarkragesspamEraseMEmidwesttelecine.com

2009\01\13@182751 by sergio masci

flavicon
face


On Tue, 13 Jan 2009, Mark Rages wrote:

{Quote hidden}

oops: should read IEEE 754

(I do know what floating point is - honest)

Regards
Sergio Masci

2009\01\13@191143 by Wouter van Ooijen

face picon face
> 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

2009\01\13@192454 by Jan-Erik Soderholm

face picon face
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.

Jan-Erik.

2009\01\13@201922 by Xiaofan Chen

face picon face
On Wed, Jan 14, 2009 at 8:24 AM, Jan-Erik Soderholm
<.....jan-erik.soderholmspam_OUTspamtelia.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

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\14@070739 by olin piclist

face picon face
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.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\01\14@080818 by Nicola Perotto

picon face


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.....spamTakeThisOuTmit.edu; *Sun, 11 Jan 2009 12:57:09* +0100
> Message-ID: <TakeThisOuT49707613.6020604KILLspamspamspamtelia.com>
> *Date: Fri, 16 Jan 2009 12:57:07* +0100
> From: Jan-Erik Soderholm <.....jan-erik.soderholmspamRemoveMEtelia.com>
> User-Agent: 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
flavicon
face
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

2009\01\14@212953 by Jake Anderson

flavicon
face
Herbert Graf 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.

2009\01\14@214842 by Marcel Birthelmer

picon face
>
> 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

picon face
On Wed, Jan 14, 2009 at 9:48 PM, Marcel Birthelmer
<RemoveMEmarcelb.listsspamspamBeGonegmail.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

flavicon
face
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

flavicon
face


:: 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, spamBeGonecolin@spam@spamspam_OUTbtech-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







2009\01\15@012833 by solarwind

picon face
On Wed, Jan 14, 2009 at 11:39 PM, cdb <TakeThisOuTcolinspamspambtech-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

Note,

http://www.google.com/search?hl=en&q=sin(cos(tan(sin(cos(tan(sin(cos(tan+1+degree)))))))))&btnG=Search

is not the same as

http://www.google.com/search?hl=en&q=sin(cos(tan(sin(cos(tan(sin(cos(tan+1)))))))))&btnG=Search

--
solarwind

2009\01\15@014543 by Jake Anderson

flavicon
face
cdb wrote:
{Quote hidden}

yeah but how fast?

2009\01\15@050900 by cdb

flavicon
face


:: yeah but how fast?

Within a second, it took me longer to enter it.

Colin
--
cdb, RemoveMEcolinEraseMEspamspam_OUTbtech-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







2009\01\15@103101 by William Couture

face picon face
On Wed, Jan 14, 2009 at 11:39 PM, cdb <@spam@colinRemoveMEspamEraseMEbtech-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

2009\01\15@113138 by Walter Banks

picon face
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

face
flavicon
face
> 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

face picon face
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_OUTspam.....paradise.net.nz> wrote:
{Quote hidden}

> -

2009\01\16@005358 by apptech

face
flavicon
face
> 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

picon face
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

face picon face
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

2009\01\21@114339 by olin piclist

face picon face
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) 742-9014.  Gold level PIC consultants since 2000.

2009\01\21@160031 by solarwind

picon face
On Wed, Jan 21, 2009 at 10:38 AM, William Chops Westfield
<spamBeGonewestfwEraseMEspammac.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.


--
solarwind

2009\01\22@191348 by Jinx

face picon face
> 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...