[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