On Tue, Jan 6, 2009 at 8:49 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> nicolas cellier wrote:
>
>> Yes, the correct version is the one corresponding to last Installer hook
>> in bugnotes.
>>
>
> Ah, yes, sorry I missed that. It's too sprinkled around in the notes ;-)
>
>  isFinite is a pre-requisite that can be found at
>> http://bugs.squeak.org/view.php?id=6983
>>
>> This is corresponding to Installer hook (Installer mantis ensureFix: 6983)
>>
>> Definition is very simple and answer false both for nans and infinities
>> isFinite
>>    ^self - self = 0.0
>>
>> Concerning equality of infinities, I think IEEE 754 say they are equal
>> Once, i did wonder why. My rationale is
>>    (Float infinity - Float infinity) isNan.
>> Since the difference of two infinities is not defined, how can we decide
>> they represent equal quantities ?
>>
>
> Interesting point. However, I do think that a = a should be true for all
> objects including  Infinity and NaN.


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


>
>  I really like the fix for Integer/Fraction/Float hash.
>>>
>>>
>> Then thank Andrew Tween for the base idea
>> http://bugs.squeak.org/view.php?id=6601
>>
>
> Ah, interesting. I had totally missed that.
>
>  http://bugs.squeak.org/view.php?id=6719
>>>>
>>>
>>> [NaN comparisons]
>>>
>> [... snip ...]
>
>> However there are other cases like these ones where it could serve:
>>
>> (1/2) < #(0 1 2). "#(false true true)"
>> (1/2) > #(0 1 2). "Array does not understand <"
>>
>> (1/2) < '1'. "true"
>> (1/2) > '1'. "Error: Instances of Fraction are not indexable"
>>
>> I agree, these are not beautiful examples, some functionalities that might
>> better take there way out of the image.
>>
>> Notice that:
>> 3 > '2' and: [3.0 > '2']. "true"
>>
>> Why not define in Fraction what already is in Integer and Float?
>>
>
> 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.
>
>  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
>>>
>>
>> Gasp, I thought I could retrieve an official reference...
>> successor ISO/IEC 10967-2 is not very verbose about that
>> http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps
>>
>> But you can read page 8 of Kahan's
>> http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>> (via http://en.wikipedia.org/wiki/IEEE_754-1985)
>>
>> Anyway, this is implemented by all libraries I know of:
>>
>
> 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.
>
> 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.
>
> 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.



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.



>
>  http://bugs.squeak.org/view.php?id=7259
>>>>
>>>
>>> [point-number comparisons]
>>>
>>> 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?
>>>
>>>
>> No, I have absolutely no guaranty.
>>
>
> Sure. I'm just asking for anecdotal evidence in your day-to-day images. Are
> you actively using these changes?
>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090106/db5a8e99/attachment.htm