# use decimal

Maciej Stachowiak mjs at apple.com
Wed Sep 17 22:53:46 PDT 2008

```On Sep 17, 2008, at 10:06 PM, Mark S. Miller wrote:

>
>
>> 0/-0 != 0/0. Does it thus seem wrong that -0 === 0?
>>
>> Well, yes, actually it does seem wrong to me, but we all accept
>> that particular wrongness. This is just more of the same.
>
> A lot more.
>
> Two wrongs don't make a right.
>
> One exception to the rule is better than two, or 2^53 or larger.
>
> "apart from somthing like significance" is a huge new set of
> exceptions. A large enough set that we can no longer understand ===
> as approximating operational equivalence. If instead we understand
> === to be asking whether two operands are cohorts, and we define
> cohorts to be those numeric values that exactly represent a given
> real number, then
> 1) -0 vs 0 is no longer irregular
> 2) We can explain why 1.5 === 1.5m === 1.5000m
> 3) We can explain why 1.1 !== 1.1m.

I think it is a tenable position that 1.5m === 1.5000m based on the
"cohort" concept, since performing the same operation on both will
give answers that are in the same "cohort" equivalence class. But
1.5 / 10.0 != 1.5m / 10.0, and indeed, the answers would not even be
in the same cohort. A notion of 'cohort' equivalence class based on
correspondence in the abstract to the same real number but divorced
from the actual semantics of the programming language strikes me as
incoherent. I think such a notion of equivalence class only makes
sense if performing identical operations on members of the same cohort
gives answers which are in the same cohort.

As a reductio ad absurdum, consider that we can place ECMAScript
strings in one-to-one correspondence with arbitrary precision integers
by considering them as base 2^16 numbers, but surely no one would
argument that this implies "00" === 3145776L. That's because in
defining a type, it is not just the set of represented values that
matters for type equivalence, but also behavior of operations on that
type.

Regards,
Maciej

```