[Another recent discussion on e-TC39 -at- ecma-international.org. This one
started as an administrative discussion. I have removed the administrative
bits and left those of potential general interest. Since the thread is here
all gathered together, I have also removed the parts where one message
quotes a previous. I don't believe any meaning has been lost.]
Forwarded conversation
Subject: ES3.1 WG Phone Conference
From: Mike Cowlishaw
Date: Feb 19, 2008 11:25 AM
[...] perhaps you can include in that discussion a rough outline for the
decimal support?
Mike
From: Mark S. Miller
Date: Feb 19, 2008 2:26 PM
Hi Mike,
I am new to the EcmaScript standards group so my apologies if I'm
confused about some distinctions. But as I understand it from looking
at ES3.1 documents and talking to others interested in ES3.1 (all of
whom are included in the addressee list), decimal is not part of
ES3.1. Frankly, if it were, I would argue that it should be removed.
From: Mike Cowlishaw
Date: Feb 20, 2008 12:28 AM
Hi Mark, thanks for the note.
It does seem to be missing from the documentation. However, I was under
the impression that this was discussed by the ES3.1 informal group last
year and they intended to include it.
Perhaps you could explain why? It is especially necessary in languages
designed for human interaction. See the FAQ at:
www2.hursley.ibm.com/decimal for some of the reasons.
It sounds as though, at some point in the future, I should attend a
meeting of the group and go through the background of this, and also the
state of decimal support in other standards and languages (IEEE 754r, ISO
C, C#, Python, etc.).
From: Douglas Crockford
Date: Feb 20, 2008 8:28 AM
I have no memory of any intention to include the decimal format in ES3.1.
From: Mike Cowlishaw
Date: Feb 20, 2008 8:51 AM
Hi Doug,
I'm somewhat confused, then -- the notes I have (from at least two
sources) of the ES 3.1 breakout meeting last April (written by Pratap, I
think) with "Douglas Crockford, Allen Wirfs-Brock, Adam Peller, Pratap
Lakshman participating" has an extensive discussion on how to include
decimal, in the list of "the following general points of consensus among
the participants".
I have no memory of the discussion, because I was not there, but I
certainly read it as an intent to include decimal -- or I would have
raised the topic earlier. [And it would be odd, indeed, for a scripting
language to not have support for the primitive types in C and C#,
especially when the type is specifically designed for human-oriented and
scripting applications :-).]
Mike
From: Mark S. Miller
Date: Feb 20, 2008 8:52 AM
C#, Python, All Lisps, Smalltalk, Java, and almost every other dynamic
symbolic language that people use have unlimited precision integers.
If I decided to agitate to add a numeric type to ES3.1, that would be
my first choice. Btw, Java's BigDecimal, if I understand it, is
unlimited precision, and so includes all the integers as well as all
the numbers represented by your proposal. If you did manage to
convince me of the need for decimal floating point, that might be my
second choice, but I doubt it.
However, I have held back from even advocating my first choice because
the whole reason for the existence of ES3.1 is to hold the fort
against featuritis. The ES3.1 WG has adopted a particular design rule
to help enforce some design discipline: no syntactic changes. As some
members of this working group knows, I have been a fan of adding
"const" to ES3.1, since it is a big help to readability and
reliability, and is already recognized in many widely deployed old
JavaScript systems. I hereby withdraw that suggestion, in order to
avoid setting a bad precedent.
Given only the current syntax and compatibility needs, "3" is
necessarily a double precision floating point literal. Since the
language has already committed to a path making it impossible to write
an integer literal simply, I think it is best to leave
not-quite-well-enough alone and not introduce integers to the
language. I am willing to sacrifice integers for the sake of
simplicity+compatibility. Please consider sacrificing decimal for the
same reason.
From: Allen Wirfs-Brock
Date: Feb 20, 2008 8:59 AM
Decimal arithmetic has always been "on the table" as something that could be
considered for ES3.1. We actually talked about it a bit with Adam Peller at
the April 2007 meeting in Newton.
We've never had what I would consider to be a "final" list of features for
ES3.1 inclusions. We've only had various strawman lists, primarily put
together my Douglas, Pratap, and myself. I've always assumed that it was up
to IBM/Mike's to advocate for inclusion of decimal arithmetic and to show
that it could be supported in a manner that is practical and consistent with
the overall ES3.1 design goals.
From: Mark S. Miller
Date: Feb 20, 2008 9:06 AM
I should explain my mysterious "I doubt it". I have always admired
exact rationals (unlimited precision integers for both numerator and
denominator). However, in years of programming in Smalltalk where
integers, floats, and rationals were all available, I only ever used
integers and floats. My own language, E, has integers and floats, and
I've never found myself needing anything else. Still, if I were going
to add something instead of integers, I might choose exact rationals,
especially since they do include all the integers as representable
values.
But to be clear, my position is: don't add any new numeric types to ES3.1.
From: Mike Cowlishaw
Date: Feb 20, 2008 9:24 AM
Mark, many thanks for the detailed reply.
BigInteger and BigDecimal arbitrary-precision types are in a somewhat
different category because they are not primitive types (in the Java
sense) and have not been implemented in hardware for 40 years at least.
The decimal128 type -- probably the right match for ECMAScript as key
users such as SAP have standardized on that -- is a primitive type in the
same sense as double and float; it is in hardware and is being included in
IEEE 754 (currently close to final ballot) and other standards, and is
already in C compilers such as GCC.
I quite agree about not adding integers; if in range, they can be
represented exactly by the ECMAScript floating-point type and so are not
necessary. They also (in their typical implementation) have several
undesirable characteristics for an apllications language, such as quite
overflow from a positive to a negative value.
But, again, decimals are in a different category: the decimal fraction
0.10 (ten cents, for example) cannot be represented exactly in ECMAScript
(except as a string), and cannot be used for arithmetic directly. Here,
for example, is a 'classic' excerpt from a web page in which ECMAScript
was used to calculate a car parking charge (at Manchester airport):
Car Park Arrival ................: 8/11/2001 at 09.00.00
Car Park Departure ..............: 18/11/2001 at 09.00.00
No of days ......................: 11
Daily Tariff ....................: 4.2 GBP
Total Price .....................: 46.19 GBP
There are two problems here: first, the inability to preserve a trailing
zero (on the fourth line), and second, the rounding error after what
should have been an exact multiplication (on the fifth). These problems
occur over and over again in real applications, and will continue to
plague us until the language supports decimal arithmetic. TC39 would have
added it in ES 3.0, I am sure, if only the standards had been more
advanced then. It's not a 'feature' -- it's a necessity.
Mike
From: Mark S. Miller
Date: Feb 20, 2008 9:58 AM
Yes, I am quite aware that IEEE double precision floating point
numbers can exactly represent 2**52 or so integers. And yes, the
numeric type known as "int" in C..Java quietly wraps on overflow, and
so are not integers. I agree that limited precision floating point or
decimal thus approximates integers better than C's "int" does.
Precision loss is less pathological than wrapping.
By "integers" I mean specifically unlimited precision integers. Try
explaining anything else to Peano or Pythagoras. With integers,
several important crypto algorithms (e.g., Diffee-Hellman) can be
coded simply. But I'm willing to give up integers because I have no
idea how to add them to ES3.1 well under the "no new syntax" design
constraint. Do you have a syntax-free proposal for decimal?
Regarding your car park example, or any monetary example, the answer
is simple even if unpleasant: any currency has a minimum unit. In the
US it's the penny. Just calculate in terms of this minimal unit using
integers. Then do format conversion on entry and rendering.
Hmm. I just noticed that this thread isn't on es4-discuss. Shouldn't it be?
[Another recent discussion on e-TC39 -at- ecma-international.org. This one
started as an administrative discussion. I have removed the administrative
bits and left those of potential general interest. Since the thread is here
all gathered together, I have also removed the parts where one message
quotes a previous. I don't believe any meaning has been lost.]
Forwarded conversation
Subject: ES3.1 WG Phone Conference
------------------------
From: *Mike Cowlishaw*
Date: Feb 19, 2008 11:25 AM
[...] perhaps you can include in that discussion a rough outline for the
decimal support?
Mike
----------
From: *Mark S. Miller*
Date: Feb 19, 2008 2:26 PM
Hi Mike,
I am new to the EcmaScript standards group so my apologies if I'm
confused about some distinctions. But as I understand it from looking
at ES3.1 documents and talking to others interested in ES3.1 (all of
whom are included in the addressee list), decimal is not part of
ES3.1. Frankly, if it were, I would argue that it should be removed.
-----
From: *Mike Cowlishaw*
Date: Feb 20, 2008 12:28 AM
Hi Mark, thanks for the note.
It does seem to be missing from the documentation. However, I was under
the impression that this was discussed by the ES3.1 informal group last
year and they intended to include it.
Perhaps you could explain why? It is especially necessary in languages
designed for human interaction. See the FAQ at:
http://www2.hursley.ibm.com/decimal/ for some of the reasons.
It sounds as though, at some point in the future, I should attend a
meeting of the group and go through the background of this, and also the
state of decimal support in other standards and languages (IEEE 754r, ISO
C, C#, Python, etc.).
----------
From: *Douglas Crockford*
Date: Feb 20, 2008 8:28 AM
I have no memory of any intention to include the decimal format in ES3.1.
----------
From: *Mike Cowlishaw*
Date: Feb 20, 2008 8:51 AM
Hi Doug,
I'm somewhat confused, then -- the notes I have (from at least two
sources) of the ES 3.1 breakout meeting last April (written by Pratap, I
think) with "Douglas Crockford, Allen Wirfs-Brock, Adam Peller, Pratap
Lakshman participating" has an extensive discussion on how to include
decimal, in the list of "the following general points of consensus among
the participants".
I have no memory of the discussion, because I was not there, but I
certainly read it as an intent to include decimal -- or I would have
raised the topic earlier. [And it would be odd, indeed, for a scripting
language to not have support for the primitive types in C and C#,
especially when the type is specifically designed for human-oriented and
scripting applications :-).]
Mike
----------
From: *Mark S. Miller*
Date: Feb 20, 2008 8:52 AM
C#, Python, All Lisps, Smalltalk, Java, and almost every other dynamic
symbolic language that people use have unlimited precision integers.
If I decided to agitate to add a numeric type to ES3.1, that would be
my first choice. Btw, Java's BigDecimal, if I understand it, is
unlimited precision, and so includes all the integers as well as all
the numbers represented by your proposal. If you did manage to
convince me of the need for decimal floating point, that might be my
second choice, but I doubt it.
However, I have held back from even advocating my first choice because
the whole reason for the existence of ES3.1 is to hold the fort
against featuritis. The ES3.1 WG has adopted a particular design rule
to help enforce some design discipline: no syntactic changes. As some
members of this working group knows, I have been a fan of adding
"const" to ES3.1, since it is a big help to readability and
reliability, and is already recognized in many widely deployed old
JavaScript systems. I hereby withdraw that suggestion, in order to
avoid setting a bad precedent.
Given only the current syntax and compatibility needs, "3" is
necessarily a double precision floating point literal. Since the
language has already committed to a path making it impossible to write
an integer literal simply, I think it is best to leave
not-quite-well-enough alone and not introduce integers to the
language. I am willing to sacrifice integers for the sake of
simplicity+compatibility. Please consider sacrificing decimal for the
same reason.
----------
From: *Allen Wirfs-Brock*
Date: Feb 20, 2008 8:59 AM
Decimal arithmetic has always been "on the table" as something that could be
considered for ES3.1. We actually talked about it a bit with Adam Peller at
the April 2007 meeting in Newton.
We've never had what I would consider to be a "final" list of features for
ES3.1 inclusions. We've only had various strawman lists, primarily put
together my Douglas, Pratap, and myself. I've always assumed that it was up
to IBM/Mike's to advocate for inclusion of decimal arithmetic and to show
that it could be supported in a manner that is practical and consistent with
the overall ES3.1 design goals.
----------
From: *Mark S. Miller*
Date: Feb 20, 2008 9:06 AM
I should explain my mysterious "I doubt it". I have always admired
exact rationals (unlimited precision integers for both numerator and
denominator). However, in years of programming in Smalltalk where
integers, floats, and rationals were all available, I only ever used
integers and floats. My own language, E, has integers and floats, and
I've never found myself needing anything else. Still, if I were going
to add something instead of integers, I might choose exact rationals,
especially since they do include all the integers as representable
values.
But to be clear, my position is: don't add any new numeric types to ES3.1.
----------
From: *Mike Cowlishaw*
Date: Feb 20, 2008 9:24 AM
Mark, many thanks for the detailed reply.
BigInteger and BigDecimal arbitrary-precision types are in a somewhat
different category because they are not primitive types (in the Java
sense) and have not been implemented in hardware for 40 years at least.
The decimal128 type -- probably the right match for ECMAScript as key
users such as SAP have standardized on that -- is a primitive type in the
same sense as double and float; it is in hardware and is being included in
IEEE 754 (currently close to final ballot) and other standards, and is
already in C compilers such as GCC.
I quite agree about not adding integers; if in range, they can be
represented exactly by the ECMAScript floating-point type and so are not
necessary. They also (in their typical implementation) have several
undesirable characteristics for an apllications language, such as quite
overflow from a positive to a negative value.
But, again, decimals are in a different category: the decimal fraction
0.10 (ten cents, for example) cannot be represented exactly in ECMAScript
(except as a string), and cannot be used for arithmetic directly. Here,
for example, is a 'classic' excerpt from a web page in which ECMAScript
was used to calculate a car parking charge (at Manchester airport):
Car Park Arrival ................: 8/11/2001 at 09.00.00
Car Park Departure ..............: 18/11/2001 at 09.00.00
No of days ......................: 11
Daily Tariff ....................: 4.2 GBP
Total Price .....................: 46.19 GBP
There are two problems here: first, the inability to preserve a trailing
zero (on the fourth line), and second, the rounding error after what
should have been an exact multiplication (on the fifth). These problems
occur over and over again in real applications, and will continue to
plague us until the language supports decimal arithmetic. TC39 would have
added it in ES 3.0, I am sure, if only the standards had been more
advanced then. It's not a 'feature' -- it's a necessity.
Mike
----------
From: *Mark S. Miller*
Date: Feb 20, 2008 9:58 AM
Yes, I am quite aware that IEEE double precision floating point
numbers can exactly represent 2**52 or so integers. And yes, the
numeric type known as "int" in C..Java quietly wraps on overflow, and
so are not integers. I agree that limited precision floating point or
decimal thus approximates integers better than C's "int" does.
Precision loss is less pathological than wrapping.
By "integers" I mean specifically unlimited precision integers. Try
explaining anything else to Peano or Pythagoras. With integers,
several important crypto algorithms (e.g., Diffee-Hellman) can be
coded simply. But I'm willing to give up integers because I have no
idea how to add them to ES3.1 well under the "no new syntax" design
constraint. Do you have a syntax-free proposal for decimal?
Regarding your car park example, or any monetary example, the answer
is simple even if unpleasant: any currency has a minimum unit. In the
US it's the penny. Just calculate in terms of this minimal unit using
integers. Then do format conversion on entry and rendering.
Hmm. I just noticed that this thread isn't on es4-discuss. Shouldn't it be?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080220/75e7ad76/attachment-0002.html
[Another recent discussion on e-TC39 -at- ecma-international.org. This one started as an administrative discussion. I have removed the administrative bits and left those of potential general interest. Since the thread is here all gathered together, I have also removed the parts where one message quotes a previous. I don't believe any meaning has been lost.]
Forwarded conversation Subject: ES3.1 WG Phone Conference
From: Mike Cowlishaw Date: Feb 19, 2008 11:25 AM
[...] perhaps you can include in that discussion a rough outline for the decimal support?
Mike
From: Mark S. Miller Date: Feb 19, 2008 2:26 PM
Hi Mike,
I am new to the EcmaScript standards group so my apologies if I'm confused about some distinctions. But as I understand it from looking at ES3.1 documents and talking to others interested in ES3.1 (all of whom are included in the addressee list), decimal is not part of ES3.1. Frankly, if it were, I would argue that it should be removed.
From: Mike Cowlishaw Date: Feb 20, 2008 12:28 AM
Hi Mark, thanks for the note.
It does seem to be missing from the documentation. However, I was under the impression that this was discussed by the ES3.1 informal group last year and they intended to include it. Perhaps you could explain why? It is especially necessary in languages designed for human interaction. See the FAQ at: www2.hursley.ibm.com/decimal for some of the reasons.
It sounds as though, at some point in the future, I should attend a meeting of the group and go through the background of this, and also the state of decimal support in other standards and languages (IEEE 754r, ISO C, C#, Python, etc.).
From: Douglas Crockford Date: Feb 20, 2008 8:28 AM
I have no memory of any intention to include the decimal format in ES3.1.
From: Mike Cowlishaw Date: Feb 20, 2008 8:51 AM
Hi Doug, I'm somewhat confused, then -- the notes I have (from at least two sources) of the ES 3.1 breakout meeting last April (written by Pratap, I think) with "Douglas Crockford, Allen Wirfs-Brock, Adam Peller, Pratap Lakshman participating" has an extensive discussion on how to include decimal, in the list of "the following general points of consensus among the participants".
I have no memory of the discussion, because I was not there, but I certainly read it as an intent to include decimal -- or I would have raised the topic earlier. [And it would be odd, indeed, for a scripting language to not have support for the primitive types in C and C#, especially when the type is specifically designed for human-oriented and scripting applications :-).]
Mike
From: Mark S. Miller Date: Feb 20, 2008 8:52 AM
C#, Python, All Lisps, Smalltalk, Java, and almost every other dynamic symbolic language that people use have unlimited precision integers. If I decided to agitate to add a numeric type to ES3.1, that would be my first choice. Btw, Java's BigDecimal, if I understand it, is unlimited precision, and so includes all the integers as well as all the numbers represented by your proposal. If you did manage to convince me of the need for decimal floating point, that might be my second choice, but I doubt it.
However, I have held back from even advocating my first choice because the whole reason for the existence of ES3.1 is to hold the fort against featuritis. The ES3.1 WG has adopted a particular design rule to help enforce some design discipline: no syntactic changes. As some members of this working group knows, I have been a fan of adding "const" to ES3.1, since it is a big help to readability and reliability, and is already recognized in many widely deployed old JavaScript systems. I hereby withdraw that suggestion, in order to avoid setting a bad precedent.
Given only the current syntax and compatibility needs, "3" is necessarily a double precision floating point literal. Since the language has already committed to a path making it impossible to write an integer literal simply, I think it is best to leave not-quite-well-enough alone and not introduce integers to the language. I am willing to sacrifice integers for the sake of simplicity+compatibility. Please consider sacrificing decimal for the same reason.
From: Allen Wirfs-Brock Date: Feb 20, 2008 8:59 AM
Decimal arithmetic has always been "on the table" as something that could be considered for ES3.1. We actually talked about it a bit with Adam Peller at the April 2007 meeting in Newton.
We've never had what I would consider to be a "final" list of features for ES3.1 inclusions. We've only had various strawman lists, primarily put together my Douglas, Pratap, and myself. I've always assumed that it was up to IBM/Mike's to advocate for inclusion of decimal arithmetic and to show that it could be supported in a manner that is practical and consistent with the overall ES3.1 design goals.
From: Mark S. Miller Date: Feb 20, 2008 9:06 AM
I should explain my mysterious "I doubt it". I have always admired exact rationals (unlimited precision integers for both numerator and denominator). However, in years of programming in Smalltalk where integers, floats, and rationals were all available, I only ever used integers and floats. My own language, E, has integers and floats, and I've never found myself needing anything else. Still, if I were going to add something instead of integers, I might choose exact rationals, especially since they do include all the integers as representable values.
But to be clear, my position is: don't add any new numeric types to ES3.1.
From: Mike Cowlishaw Date: Feb 20, 2008 9:24 AM
Mark, many thanks for the detailed reply.
BigInteger and BigDecimal arbitrary-precision types are in a somewhat different category because they are not primitive types (in the Java sense) and have not been implemented in hardware for 40 years at least. The decimal128 type -- probably the right match for ECMAScript as key users such as SAP have standardized on that -- is a primitive type in the same sense as double and float; it is in hardware and is being included in IEEE 754 (currently close to final ballot) and other standards, and is already in C compilers such as GCC. I quite agree about not adding integers; if in range, they can be represented exactly by the ECMAScript floating-point type and so are not necessary. They also (in their typical implementation) have several undesirable characteristics for an apllications language, such as quite overflow from a positive to a negative value.
But, again, decimals are in a different category: the decimal fraction 0.10 (ten cents, for example) cannot be represented exactly in ECMAScript (except as a string), and cannot be used for arithmetic directly. Here, for example, is a 'classic' excerpt from a web page in which ECMAScript was used to calculate a car parking charge (at Manchester airport):
Car Park Arrival ................: 8/11/2001 at 09.00.00 Car Park Departure ..............: 18/11/2001 at 09.00.00 No of days ......................: 11 Daily Tariff ....................: 4.2 GBP Total Price .....................: 46.19 GBP
There are two problems here: first, the inability to preserve a trailing zero (on the fourth line), and second, the rounding error after what should have been an exact multiplication (on the fifth). These problems occur over and over again in real applications, and will continue to plague us until the language supports decimal arithmetic. TC39 would have added it in ES 3.0, I am sure, if only the standards had been more advanced then. It's not a 'feature' -- it's a necessity.
Mike
From: Mark S. Miller Date: Feb 20, 2008 9:58 AM
Yes, I am quite aware that IEEE double precision floating point numbers can exactly represent 2**52 or so integers. And yes, the numeric type known as "int" in C..Java quietly wraps on overflow, and so are not integers. I agree that limited precision floating point or decimal thus approximates integers better than C's "int" does. Precision loss is less pathological than wrapping.
By "integers" I mean specifically unlimited precision integers. Try explaining anything else to Peano or Pythagoras. With integers, several important crypto algorithms (e.g., Diffee-Hellman) can be coded simply. But I'm willing to give up integers because I have no idea how to add them to ES3.1 well under the "no new syntax" design constraint. Do you have a syntax-free proposal for decimal?
Regarding your car park example, or any monetary example, the answer is simple even if unpleasant: any currency has a minimum unit. In the US it's the penny. Just calculate in terms of this minimal unit using integers. Then do format conversion on entry and rendering.
Hmm. I just noticed that this thread isn't on es4-discuss. Shouldn't it be?