use decimal

Brendan Eich brendan at mozilla.org
Thu Sep 18 16:52:21 PDT 2008


-0 and 0 are not the same "given floating point number". 1/-0 vs. 1/0  
and Math.atan2(-0,0) vs. 0,0 are but two examples.

/be

Sent from my iPhone

On Sep 18, 2008, at 7:08 PM, "Mark S. Miller" <erights at google.com>  
wrote:

>
>
> On Thu, Sep 18, 2008 at 8:00 AM, Mike Cowlishaw <MFC at uk.ibm.com>  
> wrote:
>
> >
> > Are -0 and 0 in the same cohort?
>
> In IEEE 754, no:
>
>   2.1.10 cohort: The set of all floating-point representations that  
> represent a given
>     floating-point number in a given floating-point format. In this  
> context −0 and +0
>     are considered distinct and are in different cohorts.
>
> (+0 and -0 are distinguishable in binary FP as well as in decimal  
> FP; in fact this is the only case in binary where two finite numbers  
> have the same value but different representations and encodings.)
>
>
> I don't understand this definition of cohort. It seems to contradict  
> itself. The first sentence implies that -0 and 0 are in the same  
> cohort -- since they are different representations of the same  
> number in the same given floating point format. Should I read the  
> second sentence as a clarification -- in which case it seems  
> inconsistent. Or should I read it as a qualification on the first  
> sentence, saying in effect "well, except for -0 and 0, which are  
> just weird".
>
> Given that -0 and 0 are in different cohorts, let me probe the  
> extent to which cohorts imply something like operational  
> equivalence. For any arithmetic operator OP and any decimal floating  
> point values X1,X2,Y1,Y2, is it the case that
>
>     cohort(X1,X2) & cohort(Y1,Y2) implies cohort(X1 OP Y1,X2 OP Y2)
>
> ? I say "arithmetic" above in order to include operations like "+"  
> but not ".toString()".
>
> Clearly, if -0 and 0 were cohorts, this would not hold. Since they  
> aren't, does the above property hold for all decimal floating point  
> values? If so, I withdraw the proposal to generalize cohort. In  
> which case I agree that Sam's current proposal + an agreement never  
> to supply compareTotal() (so that decimal can have a single NaNm) is  
> the best proposal on the table.
>
> -- 
> Cheers,
> --MarkM
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es3.x-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080918/d4339f48/attachment.html 


More information about the Es-discuss mailing list