Re: [ANN] Lua 5.2.0 (work1) now available

[Mike Pall <mikelu-1001@...>]

Rene Rebe wrote:
> On 09.01.2010, at 14:07, Mike Pall wrote:
> > Passing fractional numbers to a bit function is UNDEFINED. Look up
> > the meaning of UNDEFINED in the computer literature, if necessary.
> 
> Well, with doubles being the default in Lua you get fractional
> numbers pretty easy. E.g. when you code up packing some numbers
> in some string for a network packet, file format, etc . by just
> dividing by the 2^8 etc. amount.  Coding everything as bit.* is
> neither more readable nor faster. I would expect a reasonable
> bitlib library to not leave this as undefined.

Dividing by 2^8 is a workaround if you don't have bit operations.
This is precisely one of the main use cases for the right-shift
operation of a bit library.

> > And funny enough, Lua 5.2 on x86 has the exact same behavior you
> > complain about! :-)
> 
> ??? Where are you looking at? Have you actually gave it a try?

Of course I did (you don't read my postings very often, do you?):

$ lua-5.2.0-work1 -e 'print(bit.bor(1.4, 0))'
1
$ lua-5.2.0-work1 -e 'print(bit.bor(1.6, 0))'
2

Exactly what you complained about. Still funny. :-)

> I see it truncating by casting. It uses lua_tonumber, so it
> truncates I tested before my mail on x86-64, and now double
> checked with i386.

Oh, my. READ THE SOURCE and CHECK YOUR FACTS before you go on a
pointless rant. See luaconf.h:

#if defined(LUA_NUMBER_DOUBLE) && ... defined(__i386__) ...
...
union luai_Cast { double l_d; long l_l; };
#define lua_number2int(i,d) \
  { volatile union luai_Cast u; u.l_d = (d) + 6755399441055744.0; (i) = u.l_l; }
...
#define lua_number2uint(i,n)            lua_number2int(i, n)
...

Oops, Lua 5.2 does that "strange game that is the fiddling with
the union" to use your words. Oh my god -- even Lua 5.1 uses it!
Damn, checking your facts might have made SOME sense, no?

> No. But given that Lua (reasonably) defaults to double I expect
> to be able to use them reasonably. And not to trap into a
> surprising result in every line:
> 
> -- your bitlib
> =  bit.band(0xffff / 256, 0xff)
> 0
> 
> -- lua-5.2(work1)
> = bit.band(0xffff / 256, 0xff)
> 255

I get this:

$ lua-5.2.0-work1 -e 'print(bit.band(0xffff / 256, 0xff))'
0

Congratulations! You've just proved how platform-dependent the bit
library in Lua 5.2 really is. And how 'unreasonable' your imagined
use case really is. UNDEFINED means UNDEFINED in Lua 5.2, too!

If you object to lengthy function names, use shortcuts. Actually
band(shr(0xffff, 8), 0xff) is two characters less to type. And in
this case even shr(0xffff, 8) would suffice.

> Oh, I care about even more, I forgot ARM. Anyway, this was just
> a hint that I test and work with more than the usual i386. I
> could also care less about the semantics you artificially
> define. I care about readable code and stuff working in ways of
> the least surprise.

Well, why doesn't that much self-display of ignorance surprise me?

You're arguing for the sake of arguing. You have ZERO arguments,
absolutely NO CLUE and still keep on going. I appoint you the
honorable title "total moron of the month".

--Mike