lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

(This is meant as a general reply to all responses so far, not only to yours.)

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 better choice.

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. ***"
(My emphasis)

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 me.

(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) results.

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) responses.

-----Original Message----- 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?