weird bug?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

weird bug?

Jason Clow
Hi,
I've been using Lua on QNX RtP lately, and this morning I noticed something strange: the number 65 is always displayed as 64.999999...

I think the actual value is 65, because if I do something like x = 64 + 1 (which will look like 64.9999...), then add one to it again, it will be 66, rather than 65.9999...

This does not occur in Linux, Win32 or Mac OS X, so I thought it might have been a bug in QNX, either GCC (2.95.2) or their libc. I asked some other QNX users, but they were about as helpful as a poke in the eye with a sharp stick.

Could this be a bug with Lua? Maybe the function that converts a number to a string?

Even if I use format("%.0f", 65), it is still displayed as 64.9999...

Any ideas?

Regards,
Jason

==
|    ._  _   Lune MUW Server
|_(_)| )(/_  http://lune.sourceforge.net/

_____________________________________________________________


Reply | Threaded
Open this post in threaded view
|

Re: weird bug?

Luiz Henrique de Figueiredo
>I've been using Lua on QNX RtP lately, and this morning I noticed something strange: the number 65 is always displayed as 64.999999...

That's very weird. Is it really "65", I mean, an *integer*?

>Could this be a bug with Lua?

Very unlikely.

>Maybe the function that converts a number to a string?

Lua uses sprintf for this. Perhaps sprintf is broken in QNX.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: weird bug?

Steve Williams
> >I've been using Lua on QNX RtP lately, and this morning I noticed
something strange: the number 65 is always displayed as 64.999999...
>
[...]
> >Maybe the function that converts a number to a string?
>
> Lua uses sprintf for this. Perhaps sprintf is broken in QNX.

Sounds like normal floating point inaccuracies when trying the entire
fractional part of a number.  This happens on every platform.  If you
restrict the precision to two or three when displaying the number, then you
will get 65.00 or 65.000.

Steve 'Sly' Williams - Code Monkey - http://www.kromestudios.com



Reply | Threaded
Open this post in threaded view
|

Re: weird bug?

Alan Watson-4
> Sounds like normal floating point inaccuracies when trying
> the entire fractional part of a number.

65 is held exactly in all of the floating point systems I've
ever come across. I'd agree with Luiz that it sounds like
the conversion to decimal in sprintf is broken.

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM

Reply | Threaded
Open this post in threaded view
|

Re: weird bug?

Luiz Henrique de Figueiredo
In reply to this post by Jason Clow
>Sounds like normal floating point inaccuracies when trying the entire
>fractional part of a number.  This happens on every platform.

Really, even for integers? I'd expect this to happen only for numbers that
have a fractional part which is not an exact binary fraction, but not for
integers and never for small integers such as 65.

Also, it depends whether the number is read or computed. For instance,
print(sin(30)) will almost never print 0.5 but rather 0.4999999999999999,
because it's computed. In this case, changing the number of decimals printed
does help. In Lua, "print" always outputs enough digits so that the number
may be reproduced from the textual form (16 for doubles).
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: weird bug?

Alan Watson-4
> In Lua, "print" always outputs enough digits so that the
> number may be reproduced from the textual form (16 for
> doubles).

I'm not sure that 16 digits is enough.

First, doubles might be bigger than IEEE doubles. This is
not a problem, because ANSI C provides a constant DBL_DIG in
<float.h> that is defined as the "number of decimal digits,
q, such that any floating point number with q decimal digits
can be rounded into a floating point number ... and back
again without change to the q decimal digits". For an IEEE
double it is actually 15.

However, even if we make the assumption that doubles are
IEEE doubles, 15 (or 16) digits is not when %g is used. If
you use %g, you need a precision of at least DBL_DIG + 2.

Why? When we print with %e, the mantissa consists of an
integer part with one digit plus a fraction part whose
number of digits is equal to the precision. Thus:

  printf("%.*e", DBL_DIG - 1, x);

should print x unambiguously.

However, %g uses %f if the exponent of the argument is >= 4
or < the precision. Thus, 1.0000...e-4 is printed as
0.00010000..., and so we effectively lose 4 digits of
precision. Thus, we need to use something like:

  printf(f, "%.*g", DBL_DIG + 3, x);

I think this is right, but I've just had a large lunch, so
someone should check it; it's quite possible that I'm off by
a digit or two.

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM