Re: At the edge of LNUM patch

[askok@...]

I am by no means advocating a special integer divide 
operator, not required.

Let me make this clear: with LNUM patch, 12 and 12.0 are 
the _same_ number. They may be stored internally 
differently, but they equal in value, and they are the 
same table index as well. So basically, for such small 
numbers, one would not really be able to tell the 
difference.

Before 2008, I used to have LNUM patch always return FP 
results to an integer, if possible. This, however, slowed 
down _all_ FP operations slightly, and was never feeling 
'right'. The current way does feel right for me, and I bet 
if someone just slid the feature into Lua, no one would 
even recognize it in the first year or two.. :)

-asko


On Tue, 25 Mar 2008 13:54:47 +0100
 "Grellier, Thierry" <t-grellier@ti.com> wrote:
> 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