ES Decimal status

Mike Cowlishaw MFC at
Wed Sep 24 09:01:51 PDT 2008

> >> and in particular they don't call it on the index in an array 
> >> indexing
> >> operation.
> >
> > This is true.  But that in itself is not the problem.  Currently, 
> > should a
> > programmer write:
> >
> >  a[1]="first"
> >  a[1.000]="second"
> >
> > it's assumed that the second case was an accidental typo and they 
> > really
> > did not mean to type the extra '.000'.  The problem occurs at that 
> > point,
> > on the conversion from a decimal (ASCII/Unicode/whatever) string in 
> > the
> > program to an internal representation.  When the internal 
> > representation
> > cannot preserve the distinction (as with binary doubles) there's not 
> > much
> > that can be done about it.  But a decimal internal representation can
> > preserve the distinction, and so it should - 1m and 1.000m differ in 
> > the
> > same was a "1" and "1.000".  They are distinguishable, but when
> > interpreted as a number, they are considered equal.
> I'm not sure what you are getting at. a[1] and a[1.000] refer to the 
> same property in ECMAScript, but a[1m] and a[1.000m] would not. Are 
> you saying this isn't a problem?

Absolutely not a problem ... many languages (and ES itself) which index 
'arrays' by strings treat the index "1.000" as different from "1", and 
this is not considered a problem.   It's desirable, in fact, when the 
index is (for example) sections in a document:  "3.20" and "3.2" are not 
the same section. 

If the programmer's model is an array indexed by integers, they will use 
1, 2, etc. and will never use 1.000.  It all works.

> I would agree with Waldermar that it is a serious problem. Not so much 
> for literals as for values that end up with varying numbers of 
> trailing zeroes depending on how they were computed, even though they 
> are numerically the same. Certainly it seems it would make arrays 
> unusable for someone trying to use decimal numbers only.

All I can say is that is has never been a problem in languages such as 
Rexx and EXEC 2 which have had exactly that behaviour for almost 30 years. 
 I do not recall a single problem report about that behavior. 

This is, no doubt, because if one is treating array indexes as a set of 
integers you use integer operations on those indexes (almost exclusively 
+, -, and *).  If one does use a divide, it would be carefully chosen to 
produce an integer result; anything which produced a result without an 
exponent of 0 would always be more likely to give a non-zero fraction that 
.0, .00, .000, etc. -- and those non-zero ones would fail rapidly.


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

More information about the Es-discuss mailing list