Hi Folks,

In the case where the integer -> float conversion is inexact, I think we need to make the choice in the image and not in the VM.

For example, it is a valid use case to be able to mimic C. This is useful, for example, for code having various versions, in Smalltalk / C / OpenCL, etc. It is also useful for porting C libraries to Smalltalk and having the same behavior as with a standards compliant C compiler.

According to Recent draft of the ISO C18 standard: https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
6.3.1.8 Conversions -Usual arithmetic conversions
6.5.8 Relational operators
6.5.9 Equality operators
"...if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double."
(without any regard to the actual values being compared!)

I'm not saying that Squeak / Pharo / Cuis should change current behavior.

But I think that a Smalltalk developer should be able to tweak Smalltalk code to their requirements. The best way to do this is to make the primitive fail if one of the arguments is Float, the other is SmallInteger, and the two alteratives (float comparison and int comparison) would yield different results.

Making the primitive fail in those cases means the performance cost is only paid for very large values (hopefully rather infrequent as instances of SmallInteger). The alternative is that people wanting to mimic the C behavior adds a class check for every comparison (regardless of the values), at a much higher performance penalty.

Another reasonable alternative is to provide a new set of comparison primitives, and let the image choose which one to call.

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

On 8/21/2019 4:03 AM, Nicolas Cellier wrote:

Hi David,
sort of...

We know that smallInt asFloat may be inexact.
We could test whether it is exact or not with smallInt asFloat asInteger = smallInt like what is done in Squeak SmallInteger>>#isAnExactFloat check, but that's not what we do here.
What we do is to check if ever that rounding error could change the result of comparison. If it could not, then the rounding error is innocuous and we can proceed with float comparison.

So more exactly, the algorithm is:

check if there is a possible ambiguity

if yes, use exact comparison (the usual image side smallInt = smallFloat asTrueFraction)

if no, use inexact but innocuous comparison (the simple smallInt asFloat = smallFloat)
(strictly speaking, the comparison is exact, only the operands may not)

If smallInt asFloat > smallFloat we know for sure that smallInt > smallFloat.
If smallInt asFloat < smallFloat we know for sure that smallInt < smallFloat.
The only case where we could have ambiguity is when smallInt asFloat = smallFloat.

But in this case, we know that smallFloat value is integer. Indeed, either asFloat is exact, and smallInt = smallFloat, or inexact, but that means that smallInt > (2 raisedTo: Float precision) and then Float has not enough precision to have a fraction part. Thus smallFloat asTrueFraction = smallFloat asInteger in this ambiguous case, a nice thing for the VM to not deal with Fraction!

A potential remaining problem could be that smallFloat asInteger may be a LargeInteger, for example SmallInteger maxVal asInteger > SmallInteger maxVal in 64 bits image.
But we know that:
SmallInteger minVal <= smallFloat and: [smallFloat <= SmallInteger maxVal nextPowerOfTwo]
Thus in the VM, we are safe, SmallInteger span only 61 bits and we have 64 bits registers.

—
You are receiving this because you commented.