[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Unexpected calculation result with Lua53
- From: <tonyp@...>
- Date: Mon, 4 May 2015 03:20:19 +0300
(This is meant as a general reply to all responses so far, not only to
Yes, and it will happen in many other languages, also. What's your point?
In C, Pascal, and most traditional non-interpreted languages, you decide
what types the parameters will be, and if you pass the wrong thing, the
compiler will complain.
(BTW, it won't happen in previous Lua versions. So, since you asked, that's
enough of a reason for it to be surprising.)
Unfortunately several responses are saying pretty much this: "that's how
integer math works, deal with it". Well, anybody who's been in computing
long enough is aware of all that trivia.
Let me ask you this: Is Lua's audience computer scientists? If yes, then we
can stop the discussion here.
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
And it also seems to somehow contradict this statement (3.4.3 – Coercions
and Conversions) although I know it does not refer to this issue -- but it
is related conceptually:
"Lua provides some automatic conversions between some types and
representations at run time. Bitwise operators always convert float operands
to integers. Exponentiation and float division always convert integer
operands to floats. *** All other arithmetic operations applied to mixed
numbers (integers and floats) convert the integer operand to a float; this
is called the usual rule. ***"
So, float is the 'usual rule' but apparently not when passing numbers to
functions, which I would consider similar to mixing integers and floats
since the caller does not necessarily know what the called function expects
(integer or float), and the reverse, the function *cannot* possibly predict
what the user will pass in (an integer or a float).
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
(One 'cute' response claimed that zero is not "completely wrong" but
partially wrong -- and, therefore, partially correct -- because the true
result has all zeros is the least significant portion of the result that can
fit in the available size integer. Well, yes, if you go that route, we
could also accept a 0 or 1 as partially correct if we lower our tolerance to
one bit, as all numbers in binary will end with either zero or one! There
you have it: correctness ... to one bit.)
Anyway, a simple function that worked for Lua 5.2 and before now has to be
augmented with code like:
n = n + 0.0
on entry to convert the n parameter to float, just in case the caller didn't
think about passing a float when switching from Lua52 to Lua53, for example.
Or, simply, because the users are not so computer savvy to even know the
exact implications of their choice, or even that adding a single dot to a
constant or + 0.0 to a variable is actually meant to make a difference on
the calculations, and so on.
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. That is, if I
want to enforce an integer (a new thing in Lua53), use something like: n = n
// 1 on entry to the function. That would keep it compatible with previous
versions, and also prevent 'surprises' that code that worked suddenly
stopped working, without any errors, but incredibly, with very 'wrong' (OK,
OK, ... 'unexpected' yet not 'surprising' from a computer science viewpoint)
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).
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.
Thanks to all for your interesting (and to some, for their amusing)
From: Luiz Henrique de Figueiredo
Sent: Sunday, May 03, 2015 10:55 PM
To: Lua mailing list
Subject: Re: Unexpected calculation result with Lua53
Using fp parameter, return correct (?) result
Using integer parameter, return 0 (zero) result!!!!
This will happen in C as well. So, why it is surprising?