<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Folks,<br>
<br>
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.<br>
<br>
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.<br>
<br>
According to Recent draft of the ISO C18 standard:
<a class="moz-txt-link-freetext" href="https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf">https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf</a><br>
6.3.1.8 Conversions -Usual arithmetic conversions<br>
6.5.8 Relational operators<br>
6.5.9 Equality operators<br>
"...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."<br>
(without any regard to the actual values being compared!)<br>
<br>
I'm not saying that Squeak / Pharo / Cuis should change current
behavior.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Another reasonable alternative is to provide a new set of comparison
primitives, and let the image choose which one to call.<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
<br>
On 8/21/2019 4:03 AM, Nicolas Cellier wrote:
<blockquote
cite="mid:OpenSmalltalk%2Fopensmalltalk-vm%2Fissues%2F417%2F523326042@github.com"
type="cite">
<p>Hi David,<br>
sort of...</p>
<p>We know that <code>smallInt asFloat</code> may be inexact.<br>
We could test whether it is exact or not with <code>smallInt
asFloat asInteger = smallInt</code> like what is done in
Squeak <code>SmallInteger>>#isAnExactFloat</code> check,
but that's not what we do here.<br>
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.</p>
<p>So more exactly, the algorithm is:</p>
<ul>
<li>check if there is a possible ambiguity</li>
<li>if yes, use exact comparison (the usual image side <code>smallInt
= smallFloat asTrueFraction</code>)</li>
<li>if no, use inexact but innocuous comparison (the simple <code>smallInt
asFloat = smallFloat</code>)<br>
(strictly speaking, the comparison is exact, only the operands
may not)</li>
</ul>
<p>If <code>smallInt asFloat > smallFloat</code> we know for
sure that <code>smallInt > smallFloat</code>.<br>
If <code>smallInt asFloat < smallFloat</code> we know for
sure that <code>smallInt < smallFloat</code>.<br>
The only case where we could have ambiguity is when <code>smallInt
asFloat = smallFloat</code>.</p>
<p>But in this case, we know that smallFloat value is integer.
Indeed, either asFloat is exact, and <code>smallInt =
smallFloat</code>, or inexact, but that means that <code>smallInt
> (2 raisedTo: Float precision)</code> and then Float has
not enough precision to have a fraction part. Thus <code>smallFloat
asTrueFraction = smallFloat asInteger</code> in this ambiguous
case, a nice thing for the VM to not deal with Fraction!</p>
<p>A potential remaining problem could be that smallFloat
asInteger may be a LargeInteger, for example <code>SmallInteger
maxVal asInteger > SmallInteger maxVal</code> in 64 bits
image.<br>
But we know that:<br>
<code>SmallInteger minVal <= smallFloat and: [smallFloat
<= SmallInteger maxVal nextPowerOfTwo]</code><br>
Thus in the VM, we are safe, SmallInteger span only 61 bits and
we have 64 bits registers.</p>
<p style="font-size: small; color: rgb(102, 102, 102);">—<br>
You are receiving this because you commented.</p>
<script type="application/ld+json">[
{
"@context": <a class="moz-txt-link-rfc2396E" href="http://schema.org">"http://schema.org"</a>,
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": <a class="moz-txt-link-rfc2396E" href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/417?email_source=notifications\u0026email_token=AIJPEW4JXZBE5VRRFDN42FDQFTSE5A5CNFSM4IN66INKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YVEWQ#issuecomment-523326042">"https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/417?email_source=notifications\u0026email_token=AIJPEW4JXZBE5VRRFDN42FDQFTSE5A5CNFSM4IN66INKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YVEWQ#issuecomment-523326042"</a>,
"url": <a class="moz-txt-link-rfc2396E" href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/417?email_source=notifications\u0026email_token=AIJPEW4JXZBE5VRRFDN42FDQFTSE5A5CNFSM4IN66INKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YVEWQ#issuecomment-523326042">"https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/417?email_source=notifications\u0026email_token=AIJPEW4JXZBE5VRRFDN42FDQFTSE5A5CNFSM4IN66INKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YVEWQ#issuecomment-523326042"</a>,
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": <a class="moz-txt-link-rfc2396E" href="https://github.com">"https://github.com"</a>
}
}
]</script>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>