LNUM patch gets slight behavioural change

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

LNUM patch gets slight behavioural change

Asko Kauppi

Based on request, I've changed the LNUM patch behaviour to be more in-
line with standard Lua.

<<
10-Oct-09 AK:  Made hex value handling same as with standard Lua with  
modes where this is
possible without sacrificing bitwise resolution (i.e. ldouble and  
double+int32 modes).

For double+int32 (new):
         0xffffffff = 2^32-1
         0xdeadbeef > 0

For i.e. float+int32 (like it was):
        0xffffffff = -1
         0xdeadbeef < 0

In other words, hex integers with topmost bit set are now stored  
(unsigned) as floating point
when doing so would not endanger losing their least significant bit  
accuracy.
<<

The changed patch is _not_ uploaded to LuaForge or anywhere. To get it  
you have to do a svn checkout:

        svn co svn://slugak.dyndns.org/public/2009/LNUM2

The LNUM patch, also known as "integer patch" allows Lua 5.1 to treat  
pure integer operations with full accuracy and more speed on non-FP  
platforms, without changing the external interfaces.

- asko


Reply | Threaded
Open this post in threaded view
|

Re: LNUM patch gets slight behavioural change

Francesco Abbate
Hi Asko,

just a small question, did you fix also the bug with arithmetic operator overload with complex number ? The problem arise, if you remember, in the case:

z * t

where z is a complex number and t is a table with a '__mul' metamethod. In GSL shell the problem arise when you write somethng like:

> print(4i * m)

where m is a GSL matrix.

Thanks in advance.

Francesco

2009/10/11 Asko Kauppi <[hidden email]>

Based on request, I've changed the LNUM patch behaviour to be more in-line with standard Lua.

<<
10-Oct-09 AK:  Made hex value handling same as with standard Lua with modes where this is
possible without sacrificing bitwise resolution (i.e. ldouble and double+int32 modes).

For double+int32 (new):
       0xffffffff = 2^32-1
       0xdeadbeef > 0

For i.e. float+int32 (like it was):
       0xffffffff = -1
       0xdeadbeef < 0

In other words, hex integers with topmost bit set are now stored (unsigned) as floating point
when doing so would not endanger losing their least significant bit accuracy.
<<

The changed patch is _not_ uploaded to LuaForge or anywhere. To get it you have to do a svn checkout:

       svn co svn://slugak.dyndns.org/public/2009/LNUM2

The LNUM patch, also known as "integer patch" allows Lua 5.1 to treat pure integer operations with full accuracy and more speed on non-FP platforms, without changing the external interfaces.

- asko



Reply | Threaded
Open this post in threaded view
|

Re: LNUM patch gets slight behavioural change

Asko Kauppi

No, I did not.

I now added the test case you sent earlier (Sep-13-2009) to svn, so  
anyone can have a look and suggest a fix.

-asko


Francesco Abbate kirjoitti 11.10.2009 kello 14:42:

> Hi Asko,
>
> just a small question, did you fix also the bug with arithmetic  
> operator overload with complex number ? The problem arise, if you  
> remember, in the case:
>
> z * t
>
> where z is a complex number and t is a table with a '__mul'  
> metamethod. In GSL shell the problem arise when you write somethng  
> like:
>
> > print(4i * m)
>
> where m is a GSL matrix.
>
> Thanks in advance.
>
> Francesco
>
> 2009/10/11 Asko Kauppi <[hidden email]>
>
> Based on request, I've changed the LNUM patch behaviour to be more  
> in-line with standard Lua.
>
> <<
> 10-Oct-09 AK:  Made hex value handling same as with standard Lua  
> with modes where this is
> possible without sacrificing bitwise resolution (i.e. ldouble and  
> double+int32 modes).
>
> For double+int32 (new):
>        0xffffffff = 2^32-1
>        0xdeadbeef > 0
>
> For i.e. float+int32 (like it was):
>        0xffffffff = -1
>        0xdeadbeef < 0
>
> In other words, hex integers with topmost bit set are now stored  
> (unsigned) as floating point
> when doing so would not endanger losing their least significant bit  
> accuracy.
> <<
>
> The changed patch is _not_ uploaded to LuaForge or anywhere. To get  
> it you have to do a svn checkout:
>
>        svn co svn://slugak.dyndns.org/public/2009/LNUM2
>
> The LNUM patch, also known as "integer patch" allows Lua 5.1 to  
> treat pure integer operations with full accuracy and more speed on  
> non-FP platforms, without changing the external interfaces.
>
> - asko
>
>
>