Re: Decimal as quasi-parser (Was: [Caja] Fwd: ES3.1 Draft: 07 Nov 2008 "Kona" version available)
> On Thu, Nov 6, 2008 at 2:33 PM, Mark S. Miller <[EMAIL PROTECTED]> wrote: > > The EcmaScript 3.1 draft standard is rapidly congealing towards an official > > standard. The Kona version at > > < http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft> > > is the important one -- details aside, the only remaining significant > > unsettled controversy is whether Decimal remains or is pulled from ES3.1. This was settled in Redmond: if Sam Ruby could do the necessary work in time for Kona (and, yes, details/bugs are almost always present and fixable) decimal support is in 3.1. Sam has done that work, so there is no controversy at this point. ECMAScript 3.1 is looking good, and looks as though it will have industry-wide support. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: === again (sorry)
> >> The indexOf and lastIndexOf methods are new in ES3.1, and are the only > >> methods in the entire spec that depend on ===. > > > > Strictly speaking that's true, but only because the switch statement is not > > a method. switch statements depend on ===. > > There was a recently reported bug for SpiderMonkey where the > implementation treated -0 as not equal to 0 for some optimized switch > cases. Given that the bug was present in the code at least since 1998 > this gives indications that even for a switch a change to use > Object.identical, not ===, could be compatible with the web. Igor, that may (or may not) be helpful. 'equal to' has many interpretations. Do you mean "numerically equal to"? In which case the mathematical interpretation of the strings "-0", "0.00", "-0e16234" and "00" are all the same. But in the real world, "drive for 10.3 miles and then turn left", "drive for 10.0 miles and then turn left", "drive for 10 miles and then turn left" lead to quite different driver behaviors. mfc Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: === again (sorry)
> Re: === again (sorry) > > I see a small risk with changing this. Array.prototype.indexOf is > widely emulated in IE and is also used a lot in browser that support it. > > This change would cause issues with NaN and -0. However I don't think > that changing these 2 edge cases would lead to too many serious issues. Those two cases are not 'edge cases' to mathematicians and the IEEE 754 standards committee. I confess that I am no longer up-to-date on all the details of the particular ECMAScript methods, but -- please -- do not put in place changes that would make it difficult for ECMAScript to interact with languages that do support IEEE 754. For example, ES3 makes no distinction between quiet NaNs and signaling NaNs. Some future ECMScript will surely need to, in order to accept and return those values with other languages and systems that do support IEEE 754. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Decimal status
[Was on airplanes since my last post, arrived late in SeaTac ... will try
and consoliate replies on this thread to one e-mail :-)]
> >> 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.
>
> But they do not treat 1.000 as an index differently from 1. Explicit
> string indexes, whether literally expressed or computed, are not the
> issue here.
[and later:]
> I should have written "explicitly string-typed indexes", or perhaps
> "intentionally string-type indexes".
>
> So far, intentions aside, people writing JS can and arguably do count
> on any integer result of an index computation being equivalent to
> that index expressed literally as the === integer constant with no
> trailing zeroes after the decimal point.
>
> This a === b => o[a] is o[b] invariant (ignore the tiny number
> exceptions; I agree they're undesirable spec bugs) is what folks on
> the list are concerned about breaking, for integral values.
> Fractional index values and strings consisting of numeric literals
> with and without trailing zeroes are different use-cases, not of
> concern.
OK, and also liorean says:
> I'm of the opinion that decimal128 and binary64 should behave
identically in as many areas as possible.
That's a valid model. I suppose I see strings and decimals as being
'closer' in concept, and in both "what you see is what you get". But for
arrays, I see the problem. In that case 'reduce to shortest form, that is
strip trailing zeros, might be the right thing to do for decimals used as
array indices. That function is in Sam's implementation (it's called
'reduce').
> > 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,
>
> Maciej pointed out reciprocal multiplication as strength-reduced
> division; this is done often enough in graphics and other low-level
> code.
Hmm, his example was dividing an integer by 2. Why would one multiply by
0.5 for that when the compiler would convert to a shift?
> > it would be carefully chosen to produce an integer result;
>
> But what if scale is preserved?
My use of terminology without defining it was sloppy, sorry. In the
decimal context, I mean by 'integer' a decimal float whose exponent is 0.
(That is, the significand is the integer.) With the unnormalized decimal
float representation, that set of floats *is* the decimal integer 'type'
(a separate integer type, binary or decimal, is unnecessary). Hence the
scale being preserved is 0, which is what one wants.
> > 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.
>
> Sorry, I didn't follow this ("that" should be "than"?).
Yes, 'than'. Was trying to answer in a 20-minute slot at airport -- I
should have waited ...
- - - - -
> > 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.
>
> I'm not familiar with Rexx, but my cursory reading of the Wikipedia
> article on it seems to indicate Rexx does not have arrays, but rather
> "compound variables" which have a different behavior and syntax. It
> seems to say that stem.1.0 implies simulation of a multidimentional
> array, not an array index with more precision (and similarly stem.
> 1.0.0). It also seems that stem..1 would not refer to the same
> location as stem.0.1 (perhaps it is a syntax error?).
They are essentially string-indexed arrays/vectors. The syntax is a bit
odd (square brackets were not available on all keyboards at the time) but
stem.foo.bar is effectively stem[foo, bar] where foo and bar are any
strings (and that syntax is allowed/used in NetRexx).
> I'm sure you know way more about Rexx than I do, but from basic
> research it seems that its array-like feature does not look or act
> like ECMAScript arrays, so I am not sure the experience is relevant. I
> think most people would expect behavior more like C or Java or Perl or
> Python arrays than like Rexx compound variables.
I think the ES arrays are very similar -- but I agree, when only integer
values are used, the arrays look like C arrays to many people (more on
this below in response to another comment).
- - - - -
Waldemar wrote:
> > This is, no doubt, because if one is treating array indexes as a set
of
> > integers you use integer operations on those indexes (almost
exclus
Re: ES Decimal status
> >> 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. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Decimal status
David-Sarah Hopwood wrote: > Mike Cowlishaw wrote: > >> Waldemar Horwat wrote: > >>> Mike Cowlishaw wrote: > >>>>> There is still a blocking issue that's been discussed a lot but left > >>>>> off the issues here: > >>>>> > >>>>> - Treatment of cohorts in the default conversion of decimal to > >>>>> string. [...] > >>>> > >>>> I'm still not clear what your objections are -- we can discuss on > >>>> Thursday, but the intent here is that the toString conversion be > >>>> reversible [...] > >>> > >>> No; I'm complaining about the bizarre results that toString produces > >>> which are counter to its existing behavior. I don't care how many > >>> extra zeroes division sticks at the end of the number because I should > >>> never see them. This has been hashed out many times and also breaks > >>> things such as arrays if left uncorrected. > >> > >> Agreed. It's fine to have an operation that maps decimal128 values to > >> strings reversibly, but '.toString()' should not be that operation. > > > > I don't really have an opinion on how the operation should be spelled. > > That matters, because .toString() is used implicitly in primitive > operations, unlike other most other methods (.valueOf() aside). Understood. I meant that if the function had to be provided under another name that is OK, but not ideal. > > But it would seem nice, not bizarre, for the default conversion > > from a decimal > > number to a string in ES to work the same as in Java and in the equivalent > > functions and methods for C, C++, Python, many other languages, and in > > existing decimal packages. > > Java, C and C++ do not have implicit conversions that call .toString(), Java certainly does (the concatenate operator, and in many common methods (println for example)). And in the new C extensions, printf does the equivalent on decimal data and gives the same string results by default. > 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. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Decimal status
> There is still a blocking issue that's been discussed a lot but left > off the issues here: > > - Treatment of cohorts in the default conversion of decimal to > string. Despite objections, I still get the following results: > > 1/3m - 1/3m produces 0e-34 > > 1e12m - 1e12m produces 0e+12 > > 1/.1m produces 1e+1 I'm still not clear what your objections are -- we can discuss on Thursday, but the intent here is that the toString conversion be reversible (i.e., from the string representation one can recreate the decimal128 from which it was derived). So I think you are really complaining about the rule for division (which is 'the best yet' that anyone has come up with, as it matches the rule for multiplication) and the rule for subtraction (which preserves the smaller exponent). Hence 1.23-1.22 -> 0.01 and 1.23-1.23 -> 0.00. The exponent is not data-dependent unless there is rounding. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
> "Mark S. Miller" <[EMAIL PROTECTED]> wrote:
>
> On Thu, Sep 18, 2008 at 4:52 PM, Brendan Eich <[EMAIL PROTECTED]>
wrote:
> > -0 and 0 are not the same "given floating point number". 1/-0 vs. 1/
> > 0 and Math.atan2(-0,0) vs. 0,0 are but two examples.
>
> Yes, I understand their operational difference. Whether that
> difference means they are not the same number depends on how you
> define "number". I would have defined "representing the same number"
> by correspondence to the reals. YMMV.
I was quoting the IEEE 754 definition of cohort, and that uses
'floating-point number'. The IEEE 754 definition of 'floating-point
number' is:
2.1.25 floating-point number: A finite or infinite number that is
representable in a
floating-point format. A floating-point datum that is not a NaN. All
floating-point
numbers, including zeros and infinities, are signed.
There's a helpful diagram at the beginning of subclause 3.2 that shows the
four layers; considering just the finites for now, these are:
1. Real numbers -- the mathematical underpinning.
2. Floating-point numbers -- the set of discrete values that a format can
represent (-0 and +0 are distinct, because of their relationship to +/-
Infinity).
3. Floating-point representations -- the set of number representations in
a format: {sign, exponent, significand}. For binary, there is only one
representation for each number in a format, for decimal there may be many.
4. Encodings -- the specific bit-strings that encode a representation.
> In any case, my question is, does there exist any similar
> operational difference between decimal floating point values that
> are considered to be in the same cohort?
Numerically, no. (There are operations that can distinguish between
different members of the same cohort, such as sameQuantum, but all members
of the same cohort always represent the same floating-point number.)
(IEEE 754 avoids the word 'value', because -0 and +0 have the same value
(they are numerically equal) but they are different numbers, but 'value'
and 'number' are often used loosely to mean the same thing.)
> If not, then I back Sam's proposal without compareTotal().
OK. ES needs to have a discussion about sign of NaNs, signaling NaNs,
payloads, etc. -- for binary as well as decimal -- but perhaps that's
better left until the Harmony timeframe.
Mike
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Out-of-range decimal literals
> > Languages have "personalities", and people build up expectations based > > on these characteristics. As much as possible, I'd like to suggest > > that ECMAScript be internally consistent, and not have one independent > > choice (binary vs decimal) have unexpected implications over another > > (signaling vs quiet operations). > > The decimal literals introduces a new feature, a type suffix for a > number, to explicitly specify the type of the literal. It may well be > possible that this is not the last suffix to be added to ES. If, for > example, there would be a suffix to denote 32 bit int, it would be > very strange to allow to write 50i. Another possibility is > support for exact binary floating point literals. Here again rounding > out-of-range literals would look strange as the programmer would > bother to write the number on purpose to get exact presentation. For exact binary floating point literals there probably isn't a problem as one would presumably use the hexadecimal format in IEEE 754 (the same as in C) -- and it's fairly clearly an error if too may bits are specified for the significand. However, I suppose longer significands could be allowed and rounded -- although that is very much against the concept of exact literals. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
> On Wed, Sep 17, 2008 at 10:53 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > 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. > > Are -0 and 0 in the same cohort? In IEEE 754, no: 2.1.10 cohort: The set of all floating-point representations that represent a given floating-point number in a given floating-point format. In this context ?0 and +0 are considered distinct and are in different cohorts. (+0 and -0 are distinguishable in binary FP as well as in decimal FP; in fact this is the only case in binary where two finite numbers have the same value but different representations and encodings.) Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES Decimal status
> Conversion from number to decimal is precise and will round trip. > >>> Conversion of number to decimal is not precise. > >> I chose my words carefully :-) > >> http://en.wikipedia.org/wiki/Accuracy_and_precision > > > > I agree that decimal has a precision greater than number, but you said > > that "Conversion from number to decimal is precise" without qualification. > > In the case of a deterministic conversion rather than a measurement, I > > think it is quite unclear to use the term "precise" in this context > > (as opposed to "repeatable" or "reproducible"), and I don't think that > > the spec should express it in that way. > > This was just my summary. When people see Decimal(1.1) produces > 1.100088817841970012523m, they are likely to react "boy > that's... um... precise". :-). 'correctly rounded' would be a good way to describe it. > >>> I'm also not sure whether the round-trip property covers all NaNs > >>> (preserving payload), denormal, or unnormal values. > >> > >> NaN payloads should be preserved (decimal has quite a few more bits). > >> > >> The results, however, wouldn't preserve the "normalness" (or lack > >> there of) of the original input. > > > > Thanks for the clarification. Does IEEE 754r (or the ES3.1m interpretation/ > > profile of it) specify that NaN payloads shall be preserved in a way that > > round-trips? > > My understanding is that IEEE 754r merely encourages the payloads to > be preserved, but I haven't looked recently. Whether we decide to go > beyond the requirements of the specification is up to us. IEEE 754-2008 could only go as far as using Shoulds for propagation of payloads, because of the varied implementations of binary formats (different ways of distinguishing signaling NaNs, for example). The relevant subclause is: 6.2.3 NaN propagation 6.2.3.0 An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a NaN with the payload of the input NaN if representable in the destination format. If two or more inputs are NaN, then the payload of the resulting NaN should be identical to the payload of one of the input NaNs if representable in the destination format. This standard does not specify which of the input NaNs will provide the payload. Conversion of a quiet NaN from a narrower format to a wider format in the same radix, and then back to the same narrower format, should not change the quiet NaN payload in any way except to make it canonical. Conversion of a quiet NaN to a floating-point format of the same or a different radix that does not allow the payload to be preserved, shall return a quiet NaN that should provide some language-defined diagnostic information. There should be means to read and write payloads from and to external character sequences (see 5.12.1). Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Thoughts on IEEE P754
> Maciej Stachowiak <[EMAIL PROTECTED]> 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. > > I'm on the EcmaScript committee, but I'll answer anyway. My impression > is that decimal support is wildly out of line with the stated goals of > ES3.1 (cleanup and minimal critical enhancements), and was only > brought under consideration because of IBM's naked threat to vote > against any spec that did not include it. In the era of competing > specs, buying IBM's vote was worth a rush job. I am very sorry if you got that impression. Our (IBM) customers tell us that this *is* a minimum critical enhancement. IBM hardware and software products also didn't want to do this (there are always more 'interesting' or 'higher buzz' things to do than fix the basic technology). It's just something that needs to be done, and the less time one spends debating that, the less stressful and less expensive it will be. Decimal arithmetic is needed because almost all of humanity uses decimal arithmetic, and when the computing model matches the human model, fewer 'surprises' occur and the whole issue can then be ignored, because the devices 'just work right'. That's exactly in line with Apple's philosophy, I believe. Incidentally, the original 754-1985 committee wanted the standard then to use decimal (hence IEEE 854). It's an accident of history, mostly, that one of the drivers of that standard was a chip that was too far along to change from binary to decimal. We're using binary floating-point today largely because of the need to save a few transistors in 1981 -- that's no longer a good enough reason. > Furthermore, even though decimal doesn't seem like a completely > useless feature, I believe it has been given far disproportionate > weight relative to its actually value to the wide range of possible > Web applications, perhaps because it is of particular interest to Web > applications that directly handle money. However, that is either not > present or only a minor part of many of today's popular Web > applications on the public Web. I wish that were true. In practice, the applications that survive are those that ... make money. > To my view, Decimal is much less important overall than, say, > ByteArray or some other effective way to represent binary data, which > is not in ES3.1 and was even rejected from ES4 (at least as then > spec'd). There's a lot more popular Web applications that would be > interested in manipulating binary data efficiently than care about > calculating prices. [No particular comment on this, except to note that scripting languages such as Rexx can manipulate binary data directly, and this turns out to be a minefield. (Big-endian vs. little-endian, etc.) It's much better to go up a level and handle things in network byte order, represented in hex (etc.). This can then be made more performant at a lower level if necessary.] > Finally, while Decimal seems like it will be useful to knowledgeable > developers dealing with financial data, it seems likely to confuse the > average developer more than it will help. At least, a fair amount of > the discussion so far has made me feel confused, and I'd like to think > I have more than the average understanding of machine arithmetic for a > programmer. This isn't about machine arithmetic, that's exactly the point. It's about human arithmetic, and machines working in the same way. There are, of course, plenty of places (HPC for example) where performance is all that matters -- and for that, binary/machine arithmetic is fine. But it's alien to most of the inhabitants of this planet. :-) > Now that we are beyond the era of competing specs and in the era of > Harmony, perhaps we could reconsider the value of buying IBM's vote, > and incorporate enhancements to the ECMAScript number model in a > thoughtful, unrushed way, after appropriate consideration of the > merits and use cases. Adding decimal to ECMAScript was proposed -- and agreed -- for future addition in 1998/1999 (see the TC39 minutes from then). We have now appropriately considered that for about ten years, and the IEEE 754 committee (with over 150 contributors) has agreed, after 7+ years of discussion, a very stable decimal arithmetic model. This has been a thoughtful and unrushed process. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
Some comments in reply to several of the comments and questions from overnight, from various writers... > > At the present time, I am only suggesting that ECMAScript support > > Decimal128, and that there not by *any* implicit conversions to > > Decimal. > > > > Decimal.parse(n) would take n.ToString() and then parse that as a > > Decimal128 value. If (in the future) additional precisions were > > allowed by the standard, then there would be a second parameter on > > Decimal.parse that would allow the precision to be specified. > > Meanwhile: > > > > true: Decimal.parse(1.1) == 1.1m > > An interesting choice. This produces more sensible results but > directly violates IEEE P754 section 5.3.3. (It's 5.4.2.) That section, indeed, requires correctly-rounded conversions be available. There was much debate about that, because existing implementations of binary -> character sequences rarely produce correctly rounded results -- one of the reasons why users are so often confused by binary floating point (converting 0.1 to a double and then printing it commonly shows "0.1" -- it might have been better if it produced (say) "0.10" to indicate the inexactness, much as "3.0" notation is used to indicate float rather than integer). However, there's nothing in 754 that says *all* conversions must act that way, just that there be a conversion that is correctly rounded. That's a language designer's choice. (More on this below.) [Aside: IEEE now says, for binary -> string conversion, that the result should be exact unless rounding is necessary (due to specifying a smaller number of digits than would be needed for an exact conversion). So ES really should provide a binary -> string conversion that does this (and preserves the sign!).] > If we're using Decimal64, then there are no major issues. > Converting 1.1 do decimal would produce 1.1m, as both you and I desire. That conversion would be inexact, so I'd hope you'd get 1.100m not 1.1m. This is a case where the preserved exponent tells you something about the past history (another is that the exponent on a zero after an underflow is the most negative possible exponent, not 0). > If we're using Decimal128, then IEEE P754 mandates that binary > floats be convertible to decimal floats and that the result of the > conversion of 1.1 to decimal be 1.100088817841970012523m. > > Hence, a dilemma if we choose Decimal128. The binary64 value is not 1.1 -- and knowing that it is not is surely a good thing, rather than trying to 'cover it up' by rounding. [snip] > > If we're using Decimal128, then IEEE P754 mandates that binary > > floats be convertible to decimal floats and that the result of the > >conversion of 1.1 to decimal be 1.100088817841970012523m. > > > > Hence, a dilemma if we choose Decimal128. Do we obey the standard? > > Deviations from the standard merit bug reports. Agreed, if Decimal.parse were described as being the 754-conformant conversion operation. However,in this case, ES could define Decimal.parse as not being correctly rounded and provide another method which gives you the correctly rounded conversion (when and if ESn.n claims to be conformant to 754). But it might be better to have Decimal.parse correctly round in the first place. (The expert on binary FP <--> decimal FP conversions is Michel Hack, btw -- this committee might want to ask his opinion; he wrote much of 5.12.2 in 754.) > On Fri, Aug 22, 2008 at 11:39 AM, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > > Sam Ruby wrote: > >> When dealing with currency, having 0.05 + 0.05 produce 0.10 is a feature. > > > > Contrary to some beliefs, the different cohort members in IEEE > > P754 are *not* a valid indicator of precision. To prove this, > > assume that the different cohort members are an indicator of > > precision. Then evaluate: > > > > 3.00 + 1.0 > > > > IEEE P754 returns 4.0, while the result is actually precise to > > only two digits after the decimal point. Hence a contradiction. QED. I think this is looking at it backwards. Before the calculation, the different exponents might well be a valid indicator of quantum of a measurement (for example). After the calculation the result may continue to be a valid indication of quantum (e.g., when adding up currency values) and in certain special cases this is very useful. But the result most certainly does not attempt to maintain significance. For example, 6.13 * 2.34 gives 14.3442, a six-digit exact result, even though each of the inputs had only three significant digits. The arithmetic is not significance arithmetic, and nor is it claimed or intended to be. So there is no contradiction at all. Consider, too, the slightly different calculation: 3.01 + 1.1 The answer here is 4.01001. If this were some kind of 'significance' or 'decimal precision' arithmetic then one might argue that the last 3 digits should be removed -- but they are not. All numbers going into an ope
Re: Re precision, etc.
> You're still making the unjustified assumption that the choice of > cohort member is productive information. The examples here have > shown that it is not, and it leads to bad results. Things are much > simpler by not trying to make questionable distinctions between > 1 and 1e12. You are quite right to question that last case (I think there is plenty of evidence that the choice of exponent is important and productive 'in real life' -- for example, the most common reason for calculators being returned as 'broken' is when a calculation such as 1.23 + 1.27 does not give 2.50). In that last case, indeed, (and perhaps naively) when I designed the Rexx language I decided that any 'positive exponent' case should be treated as though it were an integer: 1E+9 in the underlying representation was (and is, in classic Rexx) displayed/printed as 10. I now think that was a mistake -- it's not simpler; it is a 'special rule' that often confuses. If one sees a number such as 1.23E+9 (as in 1.23 GHz for example), it's very misleading to convert that for display as 123000 (units Hz). It gets even worse in computing contexts, with all the usual arguments as to whether a GB is 1000 MB or 1024 MB (etc.). So the general idea is: the string representation should provide a reversible and exact mirror of the underlying decimal number. Your worry about the divide case is valid, but that is a concern about the division rules, not about the string representation (the division rules could have been written to always return an integer if the exponent would be positive and fits -- but that introduces a different set of problems). [Separately .. I am having problems with my subscription to this discussion; I am getting digests but cannot convert to individual e-mails as I don't have a password. So please keep cc: me on replies!] Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re precision, etc.
Re: > - Message from Waldemar Horwat <[EMAIL PROTECTED]> on Fri, 22 > Aug 2008 11:39:57 -0700 - > Contrary to some beliefs, the different cohort members in IEEE P754 > are *not* a valid indicator of precision. To prove this, assume > that the different cohort members are an indicator of precision. > Then evaluate: > > 3.00 + 1.0 > > IEEE P754 returns 4.0, while the result is actually precise to > only two digits after the decimal point. Hence a contradiction. QED. The preservation of exponents in IEEE 754 is indeed not an indication of 'precision' in the significance arithmetic sense, and it was never intended to be. See: http://speleotrove.com/decimal/decifaq2.html#precision for some of the uses of the word 'precision' -- it is best avoided -- and see: http://speleotrove.com/decimal/decifaq4.html#signif for why 'significance arithmetic' makes no sense at all, beyond single operations and rules-of-thumb. The rules in 754 codify current 'best' practice (the rule for division, for example, came from the .Net and C# division operator in its decimal class; it has the very desirable property that 2.40/2 gives 1.20, etc.). The result of 1/.1 is a necessary consequence of that .. and a lesser evil than not preserving the information that's available. There might well be a better rule for division, but that was the best proposal (and that has been in the public drafts since 2003, so there has been plenty of time to make alternative proposals). On the Array indexes, I have some homework to do, obviously. I had thought ES arrays were indexed by integers (0 though 2^n-1) rather than by strings (as in Rexx stems). If an index of "0.00" is indeed different from one of "0" than it would seem to be appropriate that the same distinction apply if the index is a decimal -- because the whole idea of decimal numbers is that they *are* the same as the string representation, from the user's point of view. Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Thoughts on IEEE P754
> Mike Cowlishaw wrote:
> > Seems to me the problem here is not decimal (or binary)
representations
> > but arrays (consider a(0.0) and a("0.0")).
> >
> > In effect the array definition in ES3 says -- in a rather roundabout
way
> > -- that all indexes must be an integer (which fits in 32 bits if
encoded
> > in binary). So, as long as there's a toInt32 in there, decimals with
> > trailing zeros after the point are just fine. In other words the
> > processing of array indexes could (conceptually) be
> > toString->toNumber->toInt32 (or something like that).
>
> That's incompatible with ES3. There is no toInt in there.
I confess it's eight years since I looked at that text, but I wasn't
saying there was a toInt32 in ES3. I'm just saying that that could/should
be added. Surely there was something about array indexes having to have
the same result as though it had a toInt32? Anything else that wouldn't
convert to an integer would be 'out of range'?
ES arrays are essentially just like Java arrays -- indexed by integers,
zero through length-1?
Mike
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Thoughts on IEEE P754
> >> var a = [];
> >> a[0] = "first";
> >> a[0.0m] = "second"; // a second property?
> >> a[0.000m] = "third"; // a third?
> >
> > [...]
> >
> > It seems to me that if trailing zeros are retained in a call to
> > ToString, then to be consistent with ES3, the three assignments above
> > would produce three properties. And if trailing zeros are lost, you
> > would expect to only have one. Both approaches are internally
> > consistent, and it surprises me to see either one characterized as
> > "breaking" array lookup.
>
> Well, the intuition is that two equal numbers should index the same
> property. This is an invariant in ES3 and it makes a lot of sense.
Seems to me the problem here is not decimal (or binary) representations
but arrays (consider a(0.0) and a("0.0")).
In effect the array definition in ES3 says -- in a rather roundabout way
-- that all indexes must be an integer (which fits in 32 bits if encoded
in binary). So, as long as there's a toInt32 in there, decimals with
trailing zeros after the point are just fine. In other words the
processing of array indexes could (conceptually) be
toString->toNumber->toInt32 (or something like that).
Mike
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Thoughts on IEEE P754
Waldemar wrote: > I just had some time to spend reading the proposed draft of the new > floating point spec. It quickly became apparent that ES3.1 is far > out of conformance with that draft and it would be a significant > undertaking to update it to conform to the new standard. In > addition, doing so would introduce breaking incompatibilities into > the language. Not necessarily -- see below. IEEE 754-2008 does not mandate how a language should conform, and in particular it does not, in general, mandate that the 754 behavior be the default. The discussion of whether ES should attempt to become a conforming implementation is a good one, however! > Here is a smattering of major issues. The chapter and section > numbers refer to the draft IEEE P754: > > - Many, if not most, of the mandatory functions in chapter 5 are not > implemented in ES3.1. There are a lot that we'd also need to > implement on binary floating-point numbers. This is true. > - IEEE P754 5.12.1 mandates that (decimal or binary) -0 print as > "-0". This is not going to happen. It only requires that there be a function which converts to and from a string which preserves (among other things) the sign of a zero. (For example, there could be a 'toIEEEstring' function, just as Java has an IEEEremainder static method in the Math class.) > - IEEE P754 5.12 mandates that binary floating-point numbers convert > exactly to a string format with a hexadecimal mantissa and back. An > implementation must provide these conversions. This is just one of the mandatory functions in Clause 5 already mentioned. This one is trivial because this is the hexadecimal string format in C99, so C compilers should already provide this. > A few other tidbits about IEEE P754: > > - There are many different ways of representing the same decimal > number, which the standard calls a cohort. Some numbers, such as > zeroes, have thousands of different variants within the cohort. > Fortunately, printing a decimal number is not required to indicate > which member of a cohort is chosen. This avoids problems for us > such as having the numbers x == y but a[x] and a[y] silently > referring to different array elements (which is what would happen if > we printed 5.00m differently from 5.m). As with -0, one is not required to preserve the zeros by default, but I would strongly recommend that it is the default behavior (it is required that there be some function that does preserve the zeros). IEEE 754-2008 requires that it be possible to convert a decimal number to a string and back again and end up with the same sign, significand, and exponent as the original number. For why this is important, see: http://speleotrove.com/decimal/decifaq1.html#tzeros (The default convert-decimal-to-string could/should preserve the sign of zeros, too, as this won't break anything.) > - The standard now supports signed NaN's which are distinguishable > from each other in various ways (total order predicate, isSignMinus, > etc.). There has been some talk about deferring to the IEEE spec > instead of listing the permissible binary floating-point values > explicitly as was done in ES3, but we must maintain something like > the existing language to avoid getting into this quagmire. This is an interesting one. IEEE 754-1985 really had its head in the sand on the sign of NaNs; anything that could look at the encoding of a binary floating-point number could detect the sign of a NaN (even though it had no meaning other than for diagnostics). However, the copy operations such as abs and negate (optional and ill-defined in 754-1985 but now required) define sign manipulations, and it was agreed that these manipulations should be predictable whether the value is a NaN or not. Hence 754-2008 had to tighten up the definition of the sign of a NaN in several ways (but it is still undefined after most operations -- for example, hardware might, and often does, XOR the signs during a multiply, regardless of the remaining bits of the encoding). > - Implementors of the standard could not agree on the binary > representation of decimal numbers. There are two mutually > incompatible ways of representing them -- the mantissa can be either > a binary integer or an array of 10-bit groups, each representing > three decimal digits. I can't tell whether they behave differently > in some scenarios -- if the format is wide enough, the integral > representation can represent more values, and their handling of > noncanonicals differs. They both describe an identical set of values, so an implementation could use either. We use the decimal encoding because it's faster in software (and almost certainly in hardware, too) because decimal rounding is so much simpler with a decimal encoding -- see http://speleotrove.com/decimal/decperf.html. All the hardware implementations use the decimal encoding. > - Some parts of IEEE P754 are ambiguous. Fo
Re: local
The 'spelling' of keywords has probably eaten more programming-language-committee bandwidth than any other topic. But it really is only worth discussing at the *start* of the design of a language, where one puts principles in place (such as 'abbreviations only shorten and never remove vowels' [so they can be looked up in dictionaries by non-native speakers] or 'there are no reserved keywords' [so the language can be extended easily], or 'we are following the Java-Algol-C-BASIC-PL/I precedent'). For ES, the choice of keywords should probably follow the 'gut-feeling' of the original designer ... that way, the design has the best chance of remaining coherent. ANSI REXX (X3.274-1996) managed to avoid this particular distraction. The only time that that committee came close to blows was over the discussion on how to indent the code in the standard. (There is a lot of code in the standard, because the language is defined as a non-circular implementation of itself, based on a very small set of primitives.) :-) bit.ly/mfc Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
