[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **At the edge of LNUM patch**
**From**: Asko Kauppi <askok@...>
**Date**: Tue, 25 Mar 2008 10:21:28 +0200

`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