Re: float to int conversion

[Geoff Worboys <geoff at telesiscomputing dot com dot au>]

Warlich, Christof wrote:
[...]
> To me (and the colleagues I've talked to), the "most expected"
> behaviour would be:

> any flaot equal to or bigger than the biggest integer -> biggest integer
> any flaot equal to or smaller than the smallest integer -> smallest integer

I can see why this might be considered expected, and even agree
that it could be useful.  But if achieving this was to incur
additional overhead on each such calculation then that is much
less desirable - since most code concerned about overflow is
already incurring overheads to avoid it in the first place.

Ultimately, it's not practical to speak of expected results
once you pass into undefined behaviour.  For example it might
argued that the most expected behaviour would be some sort
of modulo result.  But the point really is that you have gone
into a situation where the result, whatever it is, is useless.

[...]
> But imho, anything, even "undefined (but fixed)", would be
> better than "varying depending on the level of optimization".

Knowing as little as I do about how this is actually implemented
I do find the variation surprising.  It is not obvious to me why
this particular calculation should be done differently at
different optimisation levels ... but that doesn't mean much, a
lot of the compiler optimisation stuff goes way over my head.

As long as valid responses remain valid the actual value of
invalid responses is irrelevant and need not be fixed or easily
predictable.

-- 
Geoff Worboys
Telesis Computing Pty Ltd