Re: 1e50 == 1?

[Eike Decker <eike@...>]

now I might have miscalculated it, but wouldn't the string 
("1+"):rep(1e50) need

200000000000000000000000000000000000000000 Gigabyte RAM? 


Eike

> Hello Lua-L,
> 
> I was messing around today and may have found some kind of bug in Lua's
> addition method; I was posting here to confirm.
> 
> I was actually testing for stack overflows, etc., due to too complex
> statements, but ran across this instead which didn't seem accurate. This was
> tested in both 5.1.2 and 5.1.3rc5:
> 
> loadstring("return "..("1+"):rep(1e50).."1")()
> Returns: 1
> 
> Surely this is incorrect. Different interpreters tend to have different
> limits (I have seen that the 5.1.3rc5 interpreter reports "1" when doing
> ("1+"):rep(1e10) while 5.1.2 takes a while to do the calculation and ends up
> with the correct result). 
> 
> Can anyone else confirm that they are having this problem as well? I have
> only tested in Windows and Cygwin, but see the same problem in both places.
> 
> If the problem does exist, can anyone see how to fix it? My belief (without
> any looking into the code whatsoever) is that Lua is performing some kind of
> optimization incorrectly. The compiled code doesn't seem to appear out of the
> ordinary:
> 
> 
> function <lua.lua:1,3> (13 instructions, 52 bytes at 0x12d1128)
> 0 params, 6 slots, 0 upvalues, 0 locals, 7 constants, 0 functions
>         1       [2]     GETGLOBAL       0 -1    ; assert
>         2       [2]     GETGLOBAL       1 -2    ; loadstring
>         3       [2]     LOADK           2 -3    ; "return "
>         4       [2]     LOADK           3 -4    ; "1+"
>         5       [2]     SELF            3 3 -5  ; "rep"
>         6       [2]     LOADK           5 -6    ; 1e+50
>         7       [2]     CALL            3 3 2
>         8       [2]     LOADK           4 -7    ; "1"
>         9       [2]     CONCAT          2 2 4
>         10      [2]     CALL            1 2 0
>         11      [2]     CALL            0 0 2
>         12      [2]     CALL            0 1 1
>         13      [3]     RETURN          0 1
> 
> 
> (Note this was actually an older version of this code, so you see the
> "assert" in there. My older version was:
> 
> assert(loadstring("return "..("1+"):rep(1e50).."1"))()
> 
> No big difference, I just have a habit of using assert with loadstring to
> avoid "attempt to call a nil value")
> 
> Anyway, I'll keep looking through the C code, but I was just curious if
> anyone's picked this up before? I know I'm being picky, but personally I'd
> prefer this to be fixed, though I don't necessarily agree with taking all
> that time to get the correct value. Even just a "arithmetic expression too
> complex" error would be better than the incorrect result "1." I can
> understand incorrect results for things like floating point errors, etc., but
> even 1+1 is not 1... preferably this would not turn out this way :)
> 
> 
> Thanks for any response,
> -- Matthew P. Del Buono a.k.a Shirik
>