You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actually, I forgot that I hadn't actually fixed isequal yet. Currently it uses the hack of comparing hashes. This is wrong. Need to just fix == and then get rid of the hash comparison. The solution is that for floats that are smaller than typemax(Int64) we convert the float to integer and then compare rather than converting both to floats. For floats that are too big to be stored as integers, we can just return false immediately.
If f is out of int range, the first one will fail. If it's in range but you have a non-integer, the second one will fail. The corner case is when f==2^63 and i==typemax(Int64). Then the first check actually passes, but I think we can rely on (int64_t)f giving 0 or typemin(Int64), thereby failing.
This is what I have for less than:
int lt_f64_i64(double f, int64_t i)
{
if (i <= DBL_MAXINT && i >= -DBL_MAXINT)
return (f < (double)i);
return (f <= (double)S64_MIN) || (f < (double)S64_MAX && (int64_t)f < i);
}
int lt_i64_f64(int64_t i, double f)
{
if (i <= DBL_MAXINT && i >= -DBL_MAXINT)
return ((double)i < f);
return (f >= (double)S64_MAX) || (f > (double)S64_MIN && i < (int64_t)f);
}
The operators are carefully picked to take the float representations of the extreme int values into account.
If we have this as an intrinsic, the code generator can reduce this to just the first case when we have a small integer literal.
I was going to say that we didn't need these anymore since we seem to have decided to implement isequal that differentiated types, but I guess we still need it for ==, etc.
That's how we convert 2.0^63 to an Int64. As far as I can tell, it's the conversion that's problematic, not the comparison. Unless I'm missing something here.
Activity
StefanKarpinski commentedon Nov 12, 2011
Actually, I forgot that I hadn't actually fixed
isequal
yet. Currently it uses the hack of comparing hashes. This is wrong. Need to just fix==
and then get rid of the hash comparison. The solution is that for floats that are smaller than typemax(Int64) we convert the float to integer and then compare rather than converting both to floats. For floats that are too big to be stored as integers, we can just return false immediately.JeffBezanson commentedon Nov 12, 2011
I worked on this a bit and prototyped by writing C functions.
For equality, I believe it works just to cast both ways:
If f is out of int range, the first one will fail. If it's in range but you have a non-integer, the second one will fail. The corner case is when f==2^63 and i==typemax(Int64). Then the first check actually passes, but I think we can rely on (int64_t)f giving 0 or typemin(Int64), thereby failing.
This is what I have for less than:
The operators are carefully picked to take the float representations of the extreme int values into account.
If we have this as an intrinsic, the code generator can reduce this to just the first case when we have a small integer literal.
StefanKarpinski commentedon Nov 13, 2011
These look good. We should also add unit tests for the corner cases.
JeffBezanson commentedon Nov 16, 2011
For completeness, here are the ones for uint64:
StefanKarpinski commentedon Nov 16, 2011
Don't we also need
eq_f64_u64
, which I presume can be written in C as this:StefanKarpinski commentedon Nov 16, 2011
I was going to say that we didn't need these anymore since we seem to have decided to implement
isequal
that differentiated types, but I guess we still need it for==
, etc.JeffBezanson commentedon Nov 16, 2011
Yes.
StefanKarpinski commentedon Nov 16, 2011
Ok, I'm working on implementing these intrinsics right now.
StefanKarpinski commentedon Nov 16, 2011
Doesn't this work:
?
JeffBezanson commentedon Nov 16, 2011
Very close, but it gets this case wrong:
StefanKarpinski commentedon Nov 16, 2011
Seems right to me:
JeffBezanson commentedon Nov 16, 2011
huh?
StefanKarpinski commentedon Nov 16, 2011
That's how we convert 2.0^63 to an Int64. As far as I can tell, it's the conversion that's problematic, not the comparison. Unless I'm missing something here.
14 remaining items