Re: Fast metamethods for Userdata types

[Stephan Hennig <sh-list@...>]

Am 07.04.2015 um 07:14 schrieb Sean Conner:

> [1]	A table I constructed for my own use, and may be useful here:
> 
>                5.1     5.2     5.3     function
> __add           *       *       *       a + b
> __sub           *       *       *       a - b
> __mul           *       *       *       a * b
> __div           *       *       *       a / b
> __mod           *       *       *       a % b
> __pow           *       *       *       a ^ b
> __umn           *       *       *       -a
> __idiv                          *       a // b
> __band                          *       a & b
> __bor                           *       a | b
> __bxor                          *       a ~ b
> __bnot                          *       ~a
> __shl                           *       a << b
> __shr                           *       a >> b
> __concat        *       *       *       a .. b
> __len           *       *       *       #a
> __eq            *       *       *       a == b
> __lt            *       *       *       a < b
> __le            *       *       *       a > b

Nice table!  Two remarks:

If writing 'a > b' here instead of 'a <= b' is meant as a translation
to a one character operator, a negation is missing: not (a > b).

But then again, __le is needed in the first place just because '<='
cannot be expressed by '<' in the general case.  To quote from PiL,
<URL:http://www.lua.org/pil/13.2.html>:

> (Big parentheses: Until Lua 4.0, all order operators were translated
> to a single one, by translating a <= b to not (b < a). However, this
> translation is incorrect when we have a partial order, that is, when
> not all elements in our type are properly ordered. For instance,
> floating-point numbers are not totally ordered in most machines,
> because of the value Not a Number (NaN). According to the IEEE 754
> standard, currently adopted by virtually every hardware, NaN
> represents undefined values, such as the result of 0/0. The standard
> specifies that any comparison that involves NaN should result in
> false. That means that NaN <= x is always false, but x < NaN is also
> false. That implies that the translation from a <= b to not (b < a)
> is not valid in this case.)

So, better write it out in full length:

  __le            *       *       *       a <= b

Best regards,
Stephan Hennig