Es-discuss - several decimal discussions

Sam Ruby rubys at intertwingly.net
Sat Aug 23 10:04:39 PDT 2008


On Sat, Aug 23, 2008 at 11:44 AM,  <ihab.awad at gmail.com> wrote:
> On Sat, Aug 23, 2008 at 1:49 AM, Mike Cowlishaw <MFC at uk.ibm.com> wrote:
>>> Finally, I'd like to take a poll: Other than people working on decimal
>>> at IBM and people on the EcmaScript committee, is there anyone on this
>>> list who thinks that decimal adds significant value to EcmaScript? If
>>> so, please speak up. Thanks.
>>
>> Decimal arithmetic is sufficiently important that it is already
>> available in all the 'Really Important' languages except ES
>> (including C, Java, Python, C#, COBOL, and many more).  EcmaScript is
>> the 'odd one out' here, and not having decimal support makes it
>> terribly difficult to move commercial calculations to the browser for
>> 'cloud computing' and the like.
>
> Decimals in Java are implemented at the library level, as
> java.math.BigDecimal. There is no expectation that intrinsic math
> operators work on them. Is this approach valid for ES; if not, then
> why not?

Decimal implemented as a library would be sufficient for a 3.1
release.  The problem is an interoperable definition for what infix
operators is required for completeness.  Taking no other action, the
default behavior for the result of a "+" operator given a Number and a
library provided Decimal would be to convert both to string
representations and concatenate the results.

This was discussed at the last ECMA TC39 meeting in Oslo, and was
found to be unusable and would create a backwards compatibility issue
for Harmony.  An assertion was made (reportedly by Waldemar and
Brendan -- I wasn't present) that spec'ing the operators would not be
all that difficult.

To be sure, I then proceeded to implement such functionality using the
then current SpiderMonkey (i.e. pre TraceMonkey, meaning I'm facing a
significant merge -- the joys of DVCS), and found that it wasn't all
that difficult.  Based on the results, I've updated the 3.1 spec, and
again found it wasn't all that difficult -- precisely as Waldemar and
Brendan thought.

At this point, I don't think the issue is infix operators.  A few
don't seem to like the IEEE standard (Waldemar in particular tends to
use rather "colorful" language when referring to that spec), some have
expressed vague "size" concerns when at this point it seems to me that
we should be able to express such in measurable terms, and finally
there are some usability concerns relating to mixed mode operations
that we need to work through.  More about this in a separate email.

> Implementing decimals at the library level has the advantage that they
> can be deployed today, as functional (if slower) ES code, and
> optimized later on by a native implementation with no loss of
> compatibility. After all, it will be several years before the next ES
> version becomes reliably available on consumers' browsers. Does this
> manner of easing migration inform the approach being taken?
>
> Conversely, if one is to add support for the intrinsic math operators
> on decimals, does the required work generalize easily to arithmetic on
> complex numbers and matrices? Will the addition of complex numbers and
> matrices require more difficult work about how they interoperate with
> existing number representations (including, at that point, decimal
> numbers)? How, if at all, does this inform the present discussion?

Judging by other programming languages, the next form for Number that
is likely to be required is arbitrary precision integers.  While we
can never be sure until we do the work, I do believe that Decimal will
pave a path for such additions, if there is a desire by the committee
to address such requirements.

> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA

- Sam Ruby


More information about the Es-discuss mailing list