Re: [5.3] Converting a floating point number to integer.

[Tim Hill <drtimhill@...>]

> On Nov 17, 2014, at 1:42 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 
>> I kinda-sorta get that, but if you follow your logic then I don’t
>> really see them as “sub-types” but fully distinguished types.
> 
> I do not see why. What is the difference between these types? The value
> is what is important, not the type. If you have a number with a value
> of 1, it does not matter whether it is an integer or a float (in almost
> all contexts). If you have a number with a value of 1.4, it also does
> not matter whether it is an integer or a float :) We could have defined
> the "integer" operations (integer division and bitwise operations) using
> only old-style floats, with a specification that they would only work
> on integral values within a given range. (Javascript does something
> along these lines, but it truncate values [not types].)  In Lua 5.2,
> lua_tointeger could refuse to convert numbers that were not exact
> integers in C, again without having any new type in the language.
> 
> As Alexandre said, care must be taken to the operations to not get a
> unexpected error. The logic for the current behavior is that, more often
> than not, the alternative to an unexpected error would be an unexpected
> result. (What is the "expected result" of 4.5//1.5 or -5.2|-1.3?)
> 
> -- Roberto
> 


Mostly because of this:

i = 1<<62
a = 2^62
print(i, a)
i = i * 4
a = a * 4
print(i,a)

Now, I know what is going on, and you know what is going on. But does the average scripter know? I totally agree that string.sub(“foo”, 2) and string.sub(“foo”, 2.0) should return the same result, and that string.sub(“foo”, 2.5) should give an error. Then overflows come along and I would expect a user to go “er .. what???”. And of course the trouble with overflow type errors is they frequently slip through testing (how many times have you seen a dialog box with a negative “time remaining” value?).

—Tim