[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LNUM patch gets slight behavioural change
- From: Francesco Abbate <francesco.bbt@...>
- Date: Sun, 11 Oct 2009 13:42:11 +0200
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.
2009/10/11 Asko Kauppi <firstname.lastname@example.org>
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.