RE: At the edge of LNUM patch

["Grellier, Thierry" <t-grellier@...>]

Example:
	a= 12
	b= 12/5		-- drops to FP realm 
         ^^^ could also have 12\5 not to drop to FP realm 
             or well come back to integer realm (x\1)?
             Well what to do with 12.4\2.1 ?
             Or can we assert that \ only works for integer realm,
             So would bitwise operators?

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Asko Kauppi
Sent: Tuesday, March 25, 2008 11:45 AM
To: Lua list
Subject: Re: At the edge of LNUM patch


Personally, I don't think it's any worse than the current (unpatched  
Lua, doubles):

assert(x==y)	--passes
assert(x==x+1)	--passes

Is it?  :)

This only happens when integer arithmetics exceeds its natural  
boundaries (instead of overflow to negative integers).

The need for the patch "everywhere" is mainly a simplicity issue. What  
I know Roberto would dislike is a lot of ifdef's, and having int32/64  
mode always there takes some of these away.  I do think the boundary  
issues will need a few lines somewhere in the manual. But that's all;  
to me the benefits do outweight those few lines.

<<
Numbers provided as integers are treated with signed integer accuracy.  
If mathematical results fall into floating point, the values will  
remain in 'floating point realm' unless they're explicitly taken back  
by 'tonumber(x)'.

Example:
	a= 12
	b= 12/5		-- drops to FP realm
	c= b*5		-- 12.0 (FP realm)
	d= tonumber(b*5)	-- 12 (integer realm)

One needs to care about number accuracy only at the edges of integer  
realm. Otherwise, numbers work just the same whether they are  
internally stored as integers (12) or floating point values (12.0).
<<

Something like that..

-asko


Alex Davies kirjoitti 25.3.2008 kello 11:39:
> I'm pretty sure Roberto understands -why- it's happening, it's just  
> a question of whether:
>
> assert(x == y) -- passes
> assert(x+1 == y+1) -- fails
>
> is acceptable. Because it is impossible to tell from within lua if x  
> and y are different types internally or not, and in the case they  
> are, they'll perform differently to if they're not. Could cause  
> problems with scientific calculations - remember that the pentiums  
> (in)famous FDIV bug would have never been a problem outside of these  
> kind of applications.
>
> Granted, it's a rare occurence. But it's a gotcha that would be, as  
> far as I can tell, unique to Lua. And lets not forget that 64 bit  
> arithmetic on x86 is hardly faster then floating point ops, meaning  
> that this extra precision (which is only sometimes available) is the  
> only gain from the patch.
>
> Personally though I think the patch is essential processors without  
> FPUs, or when using single precision floats (mantissa isn't wide  
> enough), but I don't understand the need for it elsewhere...  
> although that's probably just me.
>
> - Alex