[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**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
``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?