<br><br><div class="gmail_quote">On Tue, Jan 6, 2009 at 8:49 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">nicolas cellier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, the correct version is the one corresponding to last Installer hook in bugnotes.<br>
</blockquote>
<br></div>
Ah, yes, sorry I missed that. It's too sprinkled around in the notes ;-)<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
isFinite is a pre-requisite that can be found at <a href="http://bugs.squeak.org/view.php?id=6983" target="_blank">http://bugs.squeak.org/view.php?id=6983</a><br>
<br>
This is corresponding to Installer hook (Installer mantis ensureFix: 6983)<br>
<br>
Definition is very simple and answer false both for nans and infinities<br>
isFinite<br>
^self - self = 0.0<br>
<br>
Concerning equality of infinities, I think IEEE 754 say they are equal<br>
Once, i did wonder why. My rationale is<br>
(Float infinity - Float infinity) isNan.<br>
Since the difference of two infinities is not defined, how can we decide they represent equal quantities ?<br>
</blockquote>
<br></div>
Interesting point. However, I do think that a = a should be true for all objects including Infinity and NaN.</blockquote><div><br></div><div>I used to think the same (at least for infinity & infinitessimal) but no longer.. 1 / 0 ~= (Float maxVal * 2). At first the IEEE rules may seem counter-intuitive but they have been well thoguht-out. They provide safety for computations that go out of range. Correctness (in this case lack of false positives) is much more important than "naturalness".</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I really like the fix for Integer/Fraction/Float hash.<br>
<br>
</blockquote>
<br>
Then thank Andrew Tween for the base idea <a href="http://bugs.squeak.org/view.php?id=6601" target="_blank">http://bugs.squeak.org/view.php?id=6601</a><br>
</blockquote>
<br></div>
Ah, interesting. I had totally missed that.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://bugs.squeak.org/view.php?id=6719" target="_blank">http://bugs.squeak.org/view.php?id=6719</a><br>
</blockquote>
<br>
[NaN comparisons]<br>
</blockquote></blockquote></div>
[... snip ...]<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However there are other cases like these ones where it could serve:<br>
<br>
(1/2) < #(0 1 2). "#(false true true)"<br>
(1/2) > #(0 1 2). "Array does not understand <"<br>
<br>
(1/2) < '1'. "true"<br>
(1/2) > '1'. "Error: Instances of Fraction are not indexable"<br>
<br>
I agree, these are not beautiful examples, some functionalities that might better take there way out of the image.<br>
<br>
Notice that:<br>
3 > '2' and: [3.0 > '2']. "true"<br>
<br>
Why not define in Fraction what already is in Integer and Float?<br>
</blockquote>
<br></div>
No reason. I wasn't aware that your changes addressed both situations. I was only concerned that addressing the NaN issues would lead to a proliferation of Magnitude subclasses having to implement all of the comparison operations instead of just a limited subset.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, out of curiosity, what's your take on the IEEE 754 requirement that NaN compares not equal to itself? This breaks fundamental relationships (for example you can't use NaN in Sets or Dicts) and my <br>
</blockquote>
<br>
Gasp, I thought I could retrieve an official reference...<br>
successor ISO/IEC 10967-2 is not very verbose about that <a href="http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps" target="_blank">http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps</a><br>
<br>
But you can read page 8 of Kahan's <a href="http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF" target="_blank">http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF</a><br>
(via <a href="http://en.wikipedia.org/wiki/IEEE_754-1985" target="_blank">http://en.wikipedia.org/wiki/IEEE_754-1985</a>)<br>
<br>
Anyway, this is implemented by all libraries I know of:<br>
</blockquote>
<br></div>
One idle thought I had today was whether one couldn't entirely get rid of float-valued NaNs and instead introduce a well-known NaN instance that *isn't* an instance of Float and consequently also isn't a Number, doesn't do any arithmetic etc. etc. etc.<br>
<br>
It would be fairly simple to change the VM to have a well-known NaN slot in the specialObjectsArray so that when a primitive attempts to return a float-valued NaN via pushFloat: the VM instead pushes that NaN object. This would fix 99% of all places that could ever return a float-valued NaN, including things like ByteArray>>doubleAt:, or the FFI etc.<br>
<br>
What I have personally no clue about is whether anyone ever uses float-valued NaNs for anything useful. I have never done that but there may be people who have and it would be interesting to see whether they have any insight into the use of a non-float NaN instance.</blockquote>
<div><br></div><div><br></div><div>The experience with VisualWorks where we changed over to IEEE (with Inf & NaN) was rthat those people who really cared avbout float arithmetic and knew what they were talking about really wanted IEEE behaviour and did not at all want abstract Infinity Infinitessimal or NaN. One thing they wanted was easy interoperability (e.g. with high-performance libraries), which means sticking to IEEE. Introducing abstract Infinity/Infinitessimal/NaN complicates the glue and slows it down.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://bugs.squeak.org/view.php?id=7259" target="_blank">http://bugs.squeak.org/view.php?id=7259</a><br>
</blockquote>
<br>
[point-number comparisons]<br>
<br>
This is an elegant solution (nice use of adaptTo:andCompare:) but I'm not sure how much code will break with it. Have you tried running this for a while in daily use?<br>
<br>
</blockquote>
<br>
No, I have absolutely no guaranty.<br>
</blockquote>
<br></div>
Sure. I'm just asking for anecdotal evidence in your day-to-day images. Are you actively using these changes?<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>