[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LNUM patch gets slight behavioural change
- From: Asko Kauppi <askok@...>
- Date: Sun, 11 Oct 2009 18:46:01 +0300
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.
Francesco Abbate kirjoitti 11.10.2009 kello 14:42:
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
> print(4i * m)
where m is a GSL matrix.
Thanks in advance.
2009/10/11 Asko Kauppi <email@example.com>
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
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
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.