Re: Unexpected calculation result with Lua53

[Dirk Laurie <dirk.laurie@...>]

2015-05-04 2:20 GMT+02:00  <tonyp@acm.org>:

> The real problem then is not my assumed misconception about how
> integer math works but how Lua opts to use integers when float
> 'should obviously' be the better choice.

You presumably use "assumed misconception" in the sense of
"pretended misconception", since you quite clearly know how it works.

It is a bad idea to argue from a pretended position on Lua-L. We're
a bunch of Sheldons somewhere on the Asperger syndrome spectrum
and can't handle that sort of thing.

Anyway, "should obviously" is a vague term depending strongly
on prejudice.

> As to the response about needing "a correct result instead of a rough
> approximation" when using integers, from a purely theoretical point of view
> I might agree totally, but from a practical point of view, how in the world
> can a zero answer be considered more accurate than even a rough
> approximation that's a lot-lot-lot-lot closer to the real answer, is beyond
> me.

Lua 5.3, for better or words, has a syntactic convention that "1" is
an exact integer whereas "1." is a (by coincidence exact) approximation
to it. In  Lua 5.3, when approximations are preferred one should always
code "1.", and in a situation where exactness is needed, one should
always code "1". Even computer users who are not computer scientists
can surely be trained to do that. Heck, even some pure mathematicians
have been known to grasp this point.

> Anyway, a simple function that worked for Lua 5.2 and before now has to be
> augmented with code like:
> ...
> In my view, if there should be a needed change in existing code (in respect
> with this issue) it should be only in the opposite direction.

Every version of Lua has had breaking changes. There is no substitute
for reading the manual, and the matter is quite clearly explained there.

    "In case of overflows in integer arithmetic, all operations wrap
    around, according to the usual rules of two-complement arithmetic.
    (In other words, they return the unique representable integer that is
    equal modulo 2⁶⁴ to the mathematical result.)"

> Oh well, I guess it all comes down to personal design preferences, and since
> I'm on the user side, I can only get what I'm served! :)  And, I'm really
> grateful, of course (even if I complain).

Finally, something that we agree on.

> I suppose then, the only real solution that would possibly keep all of us
> pleased would be the introduction of infinite precision integer arithmetic,
> like in Python.

And another! While we're are it, what about infinite precision rational
arithmetic, like in Guile?