change int(::Float64) to error on non-integral values

[StefanKarpinski]

We've discussed this before and I think it's a good change. This forces people to be explicit about whether they want rounding, truncation, or whatever. The current behavior is a gotcha for people coming from C. Related to which, do we have a document somewhere for people coming from C where we can mention that int/int = float, since that is a surprise when coming from a static language?

[jiahao]

Perhaps the Noteworthy Differences from Other Languages section of the manual?

[StefanKarpinski]

Ah, yes. I was wondering where that section had gone. We should probably have a C section in there.

[JeffBezanson]

See also #5413.
To me the value of int(x) is that it's short and convenient. It's not so bad just to say that it does rounding.

[ivarne]

I also think int(x) is an obvious sign that I really want to get a integer back. We have isinteger(x) if you think a non exact conversion deserves an error.

Wouldn't throwing an exception be a major speed bump for such a simple function?

[StefanKarpinski]

I've encountered numerous people coming from static languages who were very surprised that we (a) don't do integer division and (b) do rounding instead of truncation. My justifications are weak. People do, however, seem to agree that requiring the programmer to be explicit about how they want to convert to integers is ok.

[JeffBezanson]

Making things unsurprising to people used to static languages doesn't seem like the right standard at this point.
Rounding is a better default choice. It hasn't been the default in the past because it's slightly more expensive.

[ivarne]

Integer division is just so annoying in python. I regularly waste 30 minutes before realising that both my variables happened to be integers. I don't have a strong opinion on the rounding vs truncation, but rounding is definitely less surprising.

[lindahua]

We have ifloor, iceil, iround, and itrunc. All of these produce an integer given a floating-point value. I don't think they are more difficult to use than int. We should also encourage people to use these functions instead of int to explicitly express their intentions.

[lindahua]

My feeling is that whenever you have more than one ways to define something and none is "obviously more correct" than others, then we should just don't allow that and tell people to articulate what they want explicitly.

[JeffBezanson]

I think the real goal is to get rid of the int function (and its cohorts). That's something I can support. Then we'd just have Int(x) (which is convert), and iround etc.

[lindahua]

@JeffBezanson I agree with this plan.

[StefanKarpinski]

Excellent, we all agree.

[JeffBezanson]

I realized there is an important connection between convert and how integer arithmetic works. We have Int32+Int32=Int64, but if you want to work entirely within 32-bit ints and do everything mod 2^32 you can get that by declaring variables:

local a::Int32, b::Int32
...
a = b+1

This works because convert silently truncates. If convert errored on overflow, then instead of 32-bit arithmetic you would have 32-bit-or-error arithmetic. It would become really hard to get standard 32-bit overflow arithmetic. You'd have to put itrunc everywhere, which is not workable.

So I would say if convert is changed to error on integer overflow (which would be reasonable), then arithmetic should be changed so Int32+Int32=Int32. (Of course this also has benefits for reductions, and consistency with code that writes to arrays.)

[StefanKarpinski]

I've come to be in favor of both changes. The connection is interesting. It means that we can't make one change without the other.

[JeffBezanson]

@jakebolewski points out that now we can do Array{Int}(x) where x is some other type of array. Since it uses convert this actually works already.