On Saturday 02 April 2011 17:52:58 Roberto Inzerillo wrote:
> > It's an issue with the finite precision of floating point variables.
> > Everyone is suprised when first seeing this. Only values which happen to
> > be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
> > accurately. Everything else, even simple _decimal_ values such as "0.1"
> > or "0.775" cannot be represented exactly in _binary_. Usually this
> > doesn't matter, since when you print a value to screen - or to a string
> > buffer, you'll limit the precision. Something like 0.7749998175 will be
> > printed as "0.775" if you limit to 3 digits. Obviously the property
> > browser doesn't limit to 3 digits, but shows more, hence you see a
> > difference.
>
> That sounds reasonable to me, I've already read something about that, still
> I don't grab what's going on in this specific case.
>
> I mean, the values that FGFS assigns to the standby-mhz property on its own
> are exactly precise! No trailing decimals after the first three. When not
> using Arduino to feed those data, FGFS doesn't get it wrong, never! 120.3
> is exactly 120.3, just like 131.925 or any other frequency value, they're
> all exact without any other decimal digit. And they're all values assigned
> by the 3d knob property-assign animation statement. That means to me it's
> possible to store in the property tree float ... ooopsss ... double values
> with an exact decimal precision. How do I deal with that? What am I still
> missing? Why the property-assign can do that excatly and a generic protocol
> can't?
The problem comes down to decimal numbers can not exactly represent all
rational numbers (think 1/3 or 2/3 for example) and binary number systems
(like floating point numbers) have similar problems with 1/5 so while you can
exactly represent 0.775 with just 3 decimal digits using 16 binary digits you
get 0.110001100110011{base2} which is
1/2+1/2^2+0/2^3+0/2^4+0/2^5+1/2^6+1/2^7+0/2^8+0/2^9+1/2^10+1/2^11+0/2^12+0/2^13+1/2^14+1/2^15
or 0.7749939{base 10}. Notice that like 1/6 (0.1666...) in decimal numbers we
get a repeating pattern at the end of the binary number.
> > Also, the properties use double floating points (64bit). You're protocol
> > uses float (32bit) - so you loose some precision, which makes the effect
> > slightly worse.
>
> Well, readme.protocol does not mention a double format, float only; should
> I think double is anyway, just undocumented? I should really study more C++
> and read the code by myself, damn!!!!
One solution others have used is to express the frequency in kHz instead of
MHz so use 131925 instead of 131.925 and some nasal magic to copy your kHz
value to the MHz value.
Ron
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
