Re: [Proposal] -DLUA_NOCONVF2I and -DLUA_NOCONVI2F

[Coda Highland <chighland@...>]

On Wed, Jul 20, 2016 at 4:12 AM, Egor Skriptunoff
<egor.skriptunoff@gmail.com> wrote:
> On Wed, Jul 20, 2016 at 2:07 AM, Michael Nelson <mikestar1313@gmail.com>
> wrote:
>>
>> The decisions made in introducing integers into Lua in version 5.3 need to
>> be reconsidered.
>
>
> +1
> But I have another suggestion how this may be done.
>
>
>> Integers should be a fully distinct type
>
>
> On the opposite, I suggest that there should be only one numeric type.
> The values "x=42" and "y=42.0" should be indistinguishable
> by any means provided by the language.
> Lua interpreter may choose any internal representations of a numeric value
> at any given time.
> For example, number 42 may be stored as 64-bit integer, as float,
> as decimal string "42", as hex string "2A" or as arbitrary precision integer
> (I hope arbitrary long integers will be added to Lua someday).
>
> Probably, it would be a good idea to be able to store
> more than one representation of the same value simultaneously.
>
> Of course, some values do not have some representations:
> 1/0 and 0.5 are not representable as int64,
> ((1<<63)-1) is not representable as float.
>
>
>>
>> Integers ... should not interoperate with floats.
>
>
> IMO, it is more naturally to make any number interoperable with any other
> number.
> But how should current integer-float interoperability problems then be
> solved in Lua?
>
> The key idea of my suggestion is to make distinction between numeric
> operations.
>
> So, for example, addition "+" should be replaced by two different
> operations:
> 1) normal addition (true mathematical addition on real numbers);
> 2) cyclic addition (addition modulo 2^64).
>
> These operations should have different operation symbols,
> for example, "+" for normal and "[+]" for cyclic.
> Or new syntax like "with cyclic arithmetic do ... end" should be used
> to explicitly choose the semantics of all numeric operations inside the
> block.
>
> Normal addition should guarantee that internal representation is safe
> (integer overflow must not happen if int64 is internally used).
> Cyclic addition should convert both its arguments to int64
> (or raise an error if you prefer strict policy).
>
> Lua should decide in runtime which internal representation to give to the
> result.
>
> The benefits of this approach:
> 1) Lua will be more user-friendly, we will return to old good days
> when Lua was simpler as it has only one numeric type;
> 2) The operation semantics will become clear from source code,
> troubles like "can this expression silently produce undesired integer
> overflow?" will be gone away from Lua.
>
> Please note that choosing the type of operation "c=a+b" vs "c=a[+]b"
> should have nothing to do with performance.
> It is Lua interpreter's task to choose internal representation for faster
> execution.
> Lua user should think only about operation's semantics (according to the
> task user is working at).

Nitpick: The correct term is "modular arithmetic" (as operations are
done modulo 2^64), not "cyclic arithmetic".

While I agree with the general notion that numbers ought to be numbers
and the VM ought to be able to choose the right operations, I disagree
that this would actually be more performant. Every operation would
have to figure out what representation to use inside the VM instead of
knowing in advance what it's going to be based on the types of its
operands (which is the current status quo). And knowing when something
is supposed to be an integer-valued float before you do the operation
is... well, it's a mess. The classic example is (0.2 + 0.2 + 0.2 + 0.2
+ 0.2), which is only equal to 1.0 because of the behavior of IEEE
rounding.

/s/ Adam