Re: LNUM patch gets slight behavioural change

[Francesco Abbate <francesco.bbt@...>]

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 <askok@dnainternet.net>

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