Re: Unexpected calculation result with Lua53

[<tonyp@...>]

(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

> print(fact(66),fact(66.))
>
> 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?