[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why do some math functions return -0
- From: KHMan <keinhong@...>
- Date: Mon, 20 Sep 2010 01:15:08 +0800
On 9/20/2010 12:45 AM, Mike McGonagle wrote:
I am running on a Mac OS X 10.4.11 with lua 5.1.2, comiled in 2007.
here are the first few lines of output...
i:0.000000 r:0.000000 c:-0.000000 b:0.000000 br:-0.000000 bc:-0.000000
i:1.000000 r:0.000000 c:1.000000 b:0.000000 br:-0.000000 bc:1.000000
i:2.000000 r:0.000000 c:2.000000 b:0.000000 br:-0.000000 bc:2.000000
i:3.000000 r:0.000000 c:3.000000 b:1.000000 br:-0.000000 bc:-0.000000
i:4.000000 r:0.000000 c:4.000000 b:1.000000 br:-0.000000 bc:1.000000
i:5.000000 r:0.000000 c:5.000000 b:1.000000 br:-0.000000 bc:2.000000
i:6.000000 r:0.000000 c:6.000000 b:2.000000 br:-0.000000 bc:-0.000000
i:7.000000 r:0.000000 c:7.000000 b:2.000000 br:-0.000000 bc:1.000000
i:8.000000 r:0.000000 c:8.000000 b:2.000000 br:-0.000000 bc:2.000000
i:9.000000 r:1.000000 c:-0.000000 b:0.000000 br:1.000000 bc:-0.000000
As you notice, not all the 0's are negative. I don't know, maybe this
really isn't an issue, as so far I have not run into anything other
than this output being not exactly what I expect. I do know that I
have a later version of lua on my machine, but I don't really have the
time at the moment to check it... so maybe I should just try that and
then get back to the list...
Nothing negative on Lua 5.1.2/Cygwin. The common element for the
-0 results looks to me like %. The code for the % hasn't changed
at all from 5.1.2 to 5.1.4, I think. But there is a -ve in the
#define luai_nummod(a,b) ((a) - floor((a)/(b))*(b))
Seems like a platform issue, but -0 sure looks like the wrong
answer. Would be interesting to check a calculation with a simple
C program and look at the exact bit pattern that is generated.
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia