View previous topic :: View next topic |
Author |
Message |
magic
Joined: 23 Oct 2003 Posts: 3
|
float value problem |
Posted: Tue Feb 03, 2004 6:20 am |
|
|
float d;
d = (float)280.46061837 + (float)-730905.68950490;
this value computed by PCM --> d:-730625.206232
this value computed by windows calculator--> -730625.22888653
why is the each value different?
Thanks for helps. |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Tue Feb 03, 2004 8:04 am |
|
|
How many significant digits were you expecting? You only get 6 with the floating point format used in the CCS compiler. The calculator does have more. |
|
|
Ttelmah Guest
|
Re: float value problem |
Posted: Tue Feb 03, 2004 8:04 am |
|
|
magic wrote: | float d;
d = (float)280.46061837 + (float)-730905.68950490;
this value computed by PCM --> d:-730625.206232
this value computed by windows calculator--> -730625.22888653
why is the each value different?
Thanks for helps. |
Accuracy, accuracy, accuracy...
Float numbers in the CCS format (and other 4byte forms), only use 23bits for the 'value'. This gives a 'resolution', of 1 in 8388608 (normally referred to as 6 3/4 digits). Any digits beyond this, are effectively garbage. It is also worth though realising, just how much accuracy this gives (it corresponds to an error of less than 100yards, in the entire circumference of the Earth). If you need more accuracy than this, you will have to write your own numerical formats (though realise that these will be proportionately slower - long arithmetic is a lot of work for a small processor...).
Best Wishes |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
Re: float value problem |
Posted: Tue Feb 03, 2004 8:15 am |
|
|
magic wrote: | float d;
d = (float)280.46061837 + (float)-730905.68950490;
this value computed by PCM --> d:-730625.206232
this value computed by windows calculator--> -730625.22888653
why is the each value different?
Thanks for helps. |
I suspect the difference is beacuse of the length of the float data type. I know the CCS uses a 32 bit float. I suspect the Windows calculator uses something longer. When the decimal ASCII number is converted to a binary floating point there is usually some error. If the data types are different the errors will be different. To retain all of the precision of your input numbers you would need a 45 bit mantissa and a 24 bit exponent which is bigger than any floating point type I have ever seen.
The way to avoid these errors is to avoid using floating point data types. Floating point is slow, inaccurate, and hardly ever really needed. For your numbers a 48 bit scaled integer looks like the solution.
On the other hand why do you need such precision? Surely no physical measurenent is so precise. Actually measuring anything beyond about 28 bits is futile on this planet. You are not calculating the Gross National Product to the penny because I know bankers and accountants never use floating point. Is this some pure math research project? _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
magic
Joined: 23 Oct 2003 Posts: 3
|
|
Posted: Tue Feb 03, 2004 8:44 am |
|
|
this is for sidereal time(star time) computing...i wasnt expect that result...very strange for me.
may be i should use seperately compute way for fractions and integer parts?
Last edited by magic on Tue Feb 03, 2004 8:54 am; edited 1 time in total |
|
|
Ttelmah Guest
|
Re: float value problem |
Posted: Tue Feb 03, 2004 9:00 am |
|
|
magic wrote: | float d;
d = (float)280.46061837 + (float)-730905.68950490;
this value computed by PCM --> d:-730625.206232
this value computed by windows calculator--> -730625.22888653
why is the each value different?
Thanks for helps. |
For your 'sidereal time', consider using a scaled integer.
The 32bit integer format, gives an overall accuracy of 1 part in 2billion.
Basically, store the time in (say) seconds. Then all values will be integers. The 32bit value, will happily store the number of seconds in a year.
This is the approach used for currency calculations (normally effectively working in pence/cents), than then just adding the required decimal point for output.
Best Wishes |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Tue Feb 03, 2004 9:56 am |
|
|
Ah! So I was right!
The application is for astronomy.
Nothing ON THIS PLANET needs that sort of accuracy. ;-) _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
magic
Joined: 23 Oct 2003 Posts: 3
|
|
Posted: Sun Feb 08, 2004 8:46 am |
|
|
thanx to all. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Mon Feb 09, 2004 7:51 am |
|
|
I don't know how the Windows calculator does it but pocket and solar calculators never come out of the decimal system. All the calculations are done in binary coded decimal (BCD) in direct emulation of how we would multiply or divide if doing it by hand. This is plenty fast enough for the human interface to a pocket calculator in which anything as fast as the blink of an eye is fast enough. Now the PIC has the 4 bit nibble SWAP instruction and I suspect BCD might of at one time been a goal but I'm not aware if there is a BCD math package for the PIC out there.
As far as sidereal time and astronomy take a look at the CORDIC algorithm. It is exquistly binary and will give you sines and cosines to unlimited precision without ever going in and out of numerical bases( decimal to binary).
If you want the precision a mars mission needs the CORDIC is the way to go.
As Ttelmah advises ..if you're earthbound 32 bit floating point will often suffice.
The CORDIC binary angles are based on the fact that the tangent of 45 (decimal) degs is 1 in all number systems.
26.56(approx) degs is 1/2 so 1.1 binary is 45+26.56 degs. Since this is pure binary it's just a matter of picking the number of bits. It's binary to the core so all calculations are just shifts and adds and very fast. |
|
|
|