Es-discuss - several decimal discussions
brendan at mozilla.org
Sat Aug 23 23:28:51 PDT 2008
On Aug 23, 2008, at 8:23 PM, Sam Ruby wrote:
> The remainder of the quote that was relayed to me was that spec'ing
> the operators would not be hard. I took it upon myself to
> refamilarize myself with spider monkey and implement these operators,
> and despite it being a decade or so since I've done any serious C/C++
> coding was able to complete that task in a long weekend.
You know that I'm glad you're doing this. Doesn't mean it's going to
make 3.1, or that it must.
> I've since started updating the spec, and the changes are very
> straightforward and contained. You can see for yourself, most of the
> changes are already in there.
I will look when time permits, before the next TC39 meeting.
>>> Given this, the way I would like to proceed is towards a full and
>>> complete proposal to be ready in time for people to review for the
>>> Redmond meeting. It may very well need to be scaled back, but I
>>> much rather be in a position where the edit requests that came
>>> out of
>>> that meeting were in the form of "prune this" rather than once again
>>> be presented with "investigate that and report back".
>> How would a response of "take the time you need, and we'll track it
>> for Harmony; 3.1 is otherwise all but done" strike you?
> Frankly, it sounds like moving the goal posts.
You think so? I respectfully disagree, and I've been in all the face-
to-face meetings. ES3.1 started in earnest this past January, with a
limit scope. Decimal (already in ES4 as proposed, with operators as
well as literal syntax) was not being pushed into ES3.1 until spring-
time, at which time 3.1 was supposed to be technically "done" in
July, finalized including editorial fussing and typography in
September, etc., for standardization at the December GA meeting.
Seems to me the push for Decimal moved some posts. Why is Decimal-or-
a-No-vote being hung like a sword over the committee's head? What
goes wrong if Decimal is not in 3.1, but is (especially with user-
feedback-based improvements) in the successor Harmony edition within
> When is spec freeze? When do we need to have implementations
> complete? Are we planning to have these implementations usability and
> field tested? Will adequate time be allowed to factor in feedback
> that is received from these tests?
Let's get the implementations done and we'll see. There's no
deterministic top-down command -and-control schedule here. For the
open source implementations, the main thing is to get into nightly
builds, get docs and blogs educating users, gather bug reports.
> I'm writing the spec. I've written one implementation -- or more
> precisely a binding to an implementation that has been well tested and
> made available under a very liberal license. I've run the performance
> tests you asked me to run. I'm ready and willing to convert the
> existing decNumber test suite over to whatever format is desired; I'm
> also ready and willing to write additional tests to cover the ES
> specific binding to these functions.
We should talk about landing your patch on Mozilla elsewhere. IIRC
Rob Sayre asked for a few things in the bug and I haven't seen your
response (I may have missed it; been busy lately).
> The meanings of operators when all of the operands are decimal are
> well specified by IEEE 754R. The meaning of equality in ES3 is a bit
> arcane, and we've worked through that. My SpiderMonkey implementation
> provides access to decNumber's compareTotal method, and Object.eq
> (something Doug and Mark feel is necessary for other reasons) can be
> defined in such a way as to make use of that function.
What's the Object.eq issue? I must have missed an 8am 3.1 call. :-/
> What's left is figuring out is the syntax for constructing decimals
> from strings (Decimal.parse sounds fine to me, how about you?), and
> from binary64 floating point numbers (Number.toDecimal sounds fine to
> me, how about you?).
I like those names, FWIW.
> And to decide whether binary64 numbers get
> converted to decimal128 when they are mixed, or if it is the other way
That is important to get right. Igor Bukanov and I both sounded off
on this list as against any mixing of decimal128 and binary64 that
degraded toward binary64. So I'm pleased as punch with your new
> I was originally pursing the latter, but based on feedback,
> I'm seriously considering the former -- with the proviso that the
> conversions be exact and correct rounded, to the limits of the
> precision supported by decimal128. This approach not only has the
> advantage of being exact and correct, it also obviate the need for
> "use decimal".
Maybe, except writing 123m all over is enough of a drag that most
people won't. There still could be a case for 'use decimal'.
How's the new approach (contagious decimal128) working out in the code?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss