[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Mixed SmallInteger/Float comparison is inexact in Spur64 when jitted (#417)

Juan Vuletich JuanVuletich at zoho.com
Tue Aug 27 13:55:59 UTC 2019


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.
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190827/691d39ea/attachment.html>


More information about the Vm-dev mailing list