Open ePaul opened 8 years ago
@ePaul I'm assigning this to 1.3 because it's not blocking the 1.2 release. However, if you submit a patch I'll be happy to review/merge it. OK?
Thus I propose to extend the definition of
Integer.float
to only throw an exception in those cases where the Integer value is not representable exactly as a Float value.
But is this really useful. That's not clear to me. I don't see why you would happen to have a very large integer that just happens to be exactly representable as a float. That's especially true as they get larger, since the representable integers get further and further apart.
I propose to make this more explicit by adding a
nearestFloat
attribute to theInteger
class, returning the nearest float to the integer value, and never throwing an OverflowException.
I agree we need this.
Thus I propose to extend the definition of
Integer.float
to only throw an exception in those cases where the Integer value is not representable exactly as a Float value.But is this really useful. That's not clear to me. I don't see why you would happen to have a very large integer that just happens to be exactly representable as a float. That's especially true as they get larger, since the representable integers get further and further apart.
I agree, this doesn’t sound very useful, and potentially harmful because something might randomly work where it’s expected to fail.
Okay, I'll submit a pull request for nearestFloat
... and scrap the "extending float
idea.
(I hate that "Comment and Close Issue" button.)
This currently can be emulated using the fact that the arithmetic operators do an automatic promotion from Integer to Float: int + 0.0 (or int * 1.0) gives the nearest Float value to int.
Haha, nice. Much better than some code I wrote for this, which even involved promotion!
shared Float impreciseFloat(Integer|Float i)
=> if (is Float i) then
i
else if (realInts
&& (i >= 9007199254740992 ||
i <= -9007199254740992)) then
(i / 9007199254740992).float
* 9007199254740992
+ i % 9007199254740992
else
i.float;
Should we discuss if we still want the OverflowException
prior to adding the new property? I initially liked the idea, but, my comment from the other thread:
I'm also starting to wonder about the value of the OverflowException as I change a bunch of code to use a new
Float impreciseFloat(Integer)
function. The thing is, the correctness is fleeting since the expectation is that you'll lose precision anyway once you start using the float.
Are there cases where we really benefit by having the exception? If so, should the exception be the default, or should there be something like preciseFloat
or exactFloat
?
Summary
Integer.float
more liberal, allowing conversions whenever they are exact.Integer.nearestFloat
to allow lossy conversions to Float.Details During the review of #756, we noted that Integer's
float
attribute throws an exception whenever the value is ±2^53 or beyond. The reason for this is that Float (and Java'sdouble
) have only 53 bits of mantissa, so larger Integer values can not always be represented exactly as a Float.But some of those values actually can be represented exactly, namely those which are a multiple of a suitable power of two so the other factor fits into 53 bits. These are exactly those values which also can result from
Float.integer
(for Floats in the range[-2^(-63)..(2^63-2^10)]
or something similar).Those Integers can be checked in Java by
value == (long)(double)value
, or in Ceylon byint.nearestFloat.integer == int
with thenearestFloat
attribute discussed below. (I didn't useint.float.integer == int
, because we are just talking about the implementation offloat
.)Thus I propose to extend the definition of
Integer.float
to only throw an exception in those cases where the Integer value is not representable exactly as a Float value.In other cases we might not need an exact conversion to Float, but just some Float nearby (ideally the nearest one). An example is Ceylon-SDK issue #296.
This currently can be emulated using the fact that the arithmetic operators do an automatic promotion from Integer to Float:
int + 0.0
(orint * 1.0
) gives the nearest Float value toint
.I propose to make this more explicit by adding a
nearestFloat
attribute to theInteger
class, returning the nearest float to the integer value, and never throwing an OverflowException. That might be implemented in Ceylon as above (arithmetically), or in Java as a simple cast to double:(double)value
.