lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]
The example is good, and it shows the "graceful" decent from integer realm to floating point realm.
My reasoning for "100% backwards complience" on this patch is that it only affects accuracy of calculations, and never makes it worse than unpatched Lua is. 

Let's see through the steps below (double int64):

> y=1
> for i=1,60 do y=y*2 end
> print(y)
1152921504606846976

This number is <= 2^63-1 so it's stored with full accuracy as int64.

> x= (y*1000)/1000
> print(x)
1.1529215046068e+18
The *1000 takes the number off the int64 range, into floating point realm.
Such a "step down" most likely loses some accuracy, and also numbers fallen to FP realm will stay there for future calculations.
This is why the last line behaves the way it does: in this particular case int64->double conversion lost no accuracy, and x==y although one is FP and the other is int64. In places where the programmer _knows_ "lifting" back to integer realm is necessary, they should do a 'tonumber()' that lifts the number back into integer realm. 

> print( x==y, x+1 == y+1 )
true	false

'x' was in FP realm (x+1==x), 'y' was in int64 realm.

But:

> x= tonumber(x)
> print(x)
1152921504606846976
> print( x==y, x+1 == y+1 )
true	true
It is true that this is a corner case where use of the patch can be detected by applications. Even then, the logic is in my opinion easy to follow, and the reasons behind this behaviour (not slowing down each FP operation) are imho solid. Note that earlier LNUM (<2008) used to lift results automatically back to integer realm, but this called for _each_ FP operation to be checked separately, which slowed FP ops by some percentage. I think the current way is better, since most calculations in practise are either happening in integer realm, or FP realm. 

-asko


Roberto Ierusalimschy kirjoitti 25.3.2008 kello 0:23:

Yes, LNUM patch is at the moment The way to optimize Lua integer
performance.
I have yet to hear what Lua authors think of the latest version, but it would seem to me to be beneficial for the whole language to include the 
patch (or: parts of it).
The patch is quite useful, but I am still not comfortable with the idea of two kinds of numbers. The problem is that, although the difference is mostly invisible, it is not completely invisible. For instance, consider 
the following fragment (ran under (double int64)):

y = 1
for i=1,60 do y=y*2 end
x = (y*1000)/1000
print(x == y, x+1 == y+1)   --> true    false
I know this is a rather artificial example, but I find the result somewhat 
unsettling.

-- Roberto