Re: Infinity (to the nearest integer)

On Thu, Oct 14, 2010 at 3:12 PM, Jonathan S. Shapiro <[email protected]>wrote:

> On Thu, Oct 14, 2010 at 2:26 PM, Kevin Reid <kpreid-M/[email protected]> wrote:
>
>> On Oct 14, 2010, at 16:00, Karp, Alan H wrote:
>>
>
>
>> I didn't ask "can we have an integer NaN". I asked "given that an
>> integer operation is going to return NaN, should it be distinct from
>> the float NaN?"
>>
>
> Since there is no "the float NaN" (singular), the answer is clearly no.
> Each floating point format has it's own NaN representation.
>

In Java, JavaScript, and E, there is only one double precision floating
point NaN. In JavaScript and E, the only floating point numbers are double
precision, so they have only one NaN value.

Java, JavaScript, and E also only support one rounding mode: round to even.
And the one NaN is non-signaling. IEEE as used in these languages does not
have all the flexibility of IEEE as specified. (And a good thing too, IMO)
The subsets of IEEE they do provide are the same, and so forms a de-facto
std subset. (Or de-jure, as part of their respective language stds.)



>
> On Oct 14, 2010, at 15:19, Jonathan S. Shapiro wrote:
>>
>> > Personally, I don't think integer BigNums make a lot of sense.
>> > Distinguished infinities only make sense when the representation has
>> > bounded magnitude
>>
>> I don't understand what these two sentences have to do with each
>> other. Could you explain further?
>>
>
> Apologies. The first sentence should have read "I don't think +/- infinity
> makes a lot of sense with integer BigNums".
>
> But in my opinion, having floating x/0 return infinitiy was a bad call.
> Given that that seems to be the preferred (or at least accustomed) behaviour
> in the numerics community, I withdraw my concern.
>
> Aside on Alan's Itanium comment: for floating point computation the case
> for distinguishing infinity's representation is pretty clear. For integer
> computation I'm less convinced that the performance impact of having the
> hardware deal with integer infinities is motivated. And of course integers
> have no need to distinguish +/- zero, which IIRC was controversial even in
> floating point.
>
> On Oct 14, 2010, at 15:20, Jonathan S. Shapiro wrote:
>>
>> > If infinity or NaN values of any sort are introduced, it is
>> > important that they have the same representation on all platforms.
>>
>> What do you mean by "representation"? The representation of values in
>> memory? On disk? Semantically visible distinctions?
>>
>
> On reflection, I meant two things:
>
> 1. The same computation should produce the same result when executed in the
> same precision w.r.t. all methods of observing the result.
>
> 2. There needs to be a consistent way of [de]serializing NaN/infinity.
>
> Unfortunately, [1] means in practice that a specific bit pattern must be
> selected. This is true because untagged unions of non-pointer scalars are
> generally treated as "safe" by current runtimes. Consider explicit structure
> layout in .Net.
>

This isn't true for Java. I know nothing about .Net. Could you explain?
Thanks.



>
>
>
> shap
>
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>
>


-- 
    Cheers,
    --MarkM

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang