Re: use decimal
Mark S. Miller wrote: In both cases, it would seem that new numeric types must still be added by the language's providers rather than the language's users. This is the tragic constraint that none of the present proposals have been able to escape. I would much rather see us work on that problem, rather than trying to decide what is the next numeric type we language designers need to cook in. And this brings us full circle back to the early days of ES4, which had operator overloading facilities to do this kind of type definition within the language. Most folks didn't like the complexity. Waldemar ___ 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: use decimal
On Wed, Sep 17, 2008 at 10:52 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Sep 17, 2008, at 7:48 PM, Sam Ruby wrote: Anybody care to mark up what they would like to see the following look like? http://intertwingly.net/stories/2008/09/12/estest.html Shipt it! :-) (Not in ES3.1, certainly in Firefox 3.1 if we can... :-) We need to discuss the former further next week. *Some* support for decimal was always in the plan for 3.1 (ever since I have been involved at least) and I've been working tirelessly to refine what that support is. In Redmond, we should be in a position to determine what the remaining work items are for any of the features that anybody has ever proposed for ES3.1. /be - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
2008/9/17 Mark S. Miller [EMAIL PROTECTED]: If that is the case then 1.5m / 10.0 != 1.5 / 10.0, and thus it seems wrong for 1.5m and 1.5 to be '==='. 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Just so that I'm clear what you point is, It is worth noting that 42/0 != 42/0, yet hopefully we all agree that 42 === 42. Perhaps the example that you were looking for 1/0 != 1/-0 ? Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. just is a powerful word. Use sparingly. - Sam Ruby ___ 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? -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Thu, Sep 18, 2008 at 7:54 AM, Sam Ruby [EMAIL PROTECTED] wrote: 2008/9/17 Mark S. Miller [EMAIL PROTECTED]: If that is the case then 1.5m / 10.0 != 1.5 / 10.0, and thus it seems wrong for 1.5m and 1.5 to be '==='. 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Just so that I'm clear what you point is, It is worth noting that 42/0 != 42/0, yet hopefully we all agree that 42 === 42. Perhaps the example that you were looking for 1/0 != 1/-0 ? Yes, thanks. Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. just is a powerful word. Use sparingly. - Sam Ruby -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Thu, Sep 18, 2008 at 8:00 AM, Mike Cowlishaw [EMAIL PROTECTED] wrote: 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.) I don't understand this definition of cohort. It seems to contradict itself. The first sentence implies that -0 and 0 are in the same cohort -- since they are different representations of the same number in the same given floating point format. Should I read the second sentence as a clarification -- in which case it seems inconsistent. Or should I read it as a qualification on the first sentence, saying in effect well, except for -0 and 0, which are just weird. Given that -0 and 0 are in different cohorts, let me probe the extent to which cohorts imply something like operational equivalence. For any arithmetic operator OP and any decimal floating point values X1,X2,Y1,Y2, is it the case that cohort(X1,X2) cohort(Y1,Y2) implies cohort(X1 OP Y1,X2 OP Y2) ? I say arithmetic above in order to include operations like + but not .toString(). Clearly, if -0 and 0 were cohorts, this would not hold. Since they aren't, does the above property hold for all decimal floating point values? If so, I withdraw the proposal to generalize cohort. In which case I agree that Sam's current proposal + an agreement never to supply compareTotal() (so that decimal can have a single NaNm) is the best proposal on the table. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
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. 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? If not, then I back Sam's proposal without compareTotal(). -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 18, 2008, at 5:13 PM, Mark S. Miller 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. But the mathematical behavior of floating point numbers is not the same as that of the reals. Not just because of -0. See http://docs.sun.com/source/806-3568/ncg_goldberg.html Floating point numbers are a useful rough approximation of the reals for many practical calculations, but treating them as if they were in fact a subset of the reals is not mathematically sound. 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? If not, then I back Sam's proposal without compareTotal(). I assumed not, but it would be nice to hear from an expert. If there is an operational difference (in the sense you helpfully expressed in more precise form) then I tend to think it undermines the notion of cohort. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
Mark S. Miller wrote: Long long ago I actually had read that document carefully, and I had also looked at I think the [Brown 1981] which it cites. (But the doc has no bibliography. Anyone have a pointer?) My memory of the theory of floating point is that the numbers are exact but the operations are approximate. More precisely, the basic operations are correctly rounded. That is, they calculate the nearest representable value to the real result using a specified rounding rule. Nothing in the basic operations of floating point arithmetic is approximate -- they are just not the same operations as the similarly named ones on real numbers. (Some of the more complicated operations are specified nondeterministically.) You can, of course, use this exact arithmetic to *represent* values that are only know approximately. That is where I think that the confusion creeps into some people's mental model of floating point; they are not distinguishing the map (floating point values) from the territory (the application-domain values being represented). * A given finite floating point value exactly represents a given real number. * The subset of real numbers which are exactly representable in a given format are its representable numbers. * The standards require various well behaved properties like: Let Tr = B2R(Xb) +r B2R(Yb) // Tr stands for True sum as a real number If representable(Tr) then Tr ===r B2R(Xb +b Yb) Else (greatest representable number r Tr) r B2R(Xb +b Yb) r (smallest representable number r Tr) You mean Else (greatest representable number r Tr) =r B2R(Xb +b Yb) =r (smallest representable number r Tr) -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 18, 2008, at 6:03 PM, Mark S. Miller wrote: On Thu, Sep 18, 2008 at 5:22 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Sep 18, 2008, at 5:13 PM, Mark S. Miller 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. But the mathematical behavior of floating point numbers is not the same as that of the reals. Not just because of -0. See http://docs.sun.com/source/806-3568/ncg_goldberg.html Floating point numbers are a useful rough approximation of the reals for many practical calculations, but treating them as if they were in fact a subset of the reals is not mathematically sound. Long long ago I actually had read that document carefully, and I had also looked at I think the [Brown 1981] which it cites. (But the doc has no bibliography. Anyone have a pointer?) My memory of the theory of floating point is that the numbers are exact but the operations are approximate. I'm not sure what it means for values to be exact representations of real numbers when operations on them break even the most fundamental identities of real arithmetic. For many values of A, B and C, (A + B) + C != A + (B + C). And with the right values, it's not just a tiny difference of units in the last place, these expressions can be wildly different in value. The bottom line to me is, if you are very very careful, then floating point numbers might be a useful approximate model of the real numbers for a given problem, but fundamentally their behavior is very different from the reals and they should not be considered to truly map to any subset of R. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 10:13 PM, Mark S. Miller wrote: On Wed, Sep 17, 2008 at 6:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I agree that typeof 1.5m == typeof 1.1m. However, I do not agree that 1.1m == 1.1. These should be !=, since they represent distinct real numbers. It seems to me that Brendan said 1.1m != 1.1 and did not question this. Brendan, please correct me if I misrepresent your argument. I took Brendan to be saying that 1) If typeof 1.1m were 'number' then we'd be obligated to have 1.1m == 1.1. 2) We want 1.1m != 1.1. 3) Therefore, typeof 1.1m must not be 'number'. I disagree with #1 and thus #3. Here is what I wrote: Without use decimal, typeof 1.1m must not be number to preserve this same invariant [that a === b = typeof a == typeof b a == b]. Otherwise (without use decimal) 1.5m == 1.5 but 1.1m != 1.1, so without making typeof 1.5m != typeof 1.1m, we cannot have typeof 1.5m == number. Please expand your syllogistic reasoning: Major premise #1: a == b Minor premise #1: typeof a == typeof b Conclusion #1: a === b (you can switch == and === above -- the implication goes both ways and choice of == or === for typeof a OP typeof b does not matter since typeof's result is of string type.) Major premise #2: 1.5m == 1.5 Minor premise #2: typeof 1.5m == number (your position, IIUC) Conclusion #2: 1.5m === 1.5 (by Conclusion #1 and ES1-3 (which define typeof 1.5 == number)) Counter-example: 1.1m != 1.1 but typeof 1.1m == typeof 1.1 in your proposal (again IIUC) This is a for-all problem. If there exists some double value x such that, for the decimal form y spelled literally using the same digits but with an 'm' suffix, x != y, yet typeof x == typeof y, then typeof must depend on whether its operand value converts losslessly to decimal from double and double from decimal. This is broken -- typeof should depend on type, not value. Hence my position (Waldemar's too) that typeof 1.1m == typeof 1.5m typeof 1.1m == decimal. However, with the introduction of decimal, we've got cohorts galore. 1.1m has a different operational behavior than 1.1000m, but we've agree they should be ===. With the introduction of decimal, === no longer approximates a test of operational equivalence, and we still need such a test. === does approximate operational equivalence apart from significance. Right? (I'm asking because I could be wrong, not rhetorically!) 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. A lot more. Two wrongs don't make a right. One exception to the rule is better than two, or 2^53 or larger. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 7:48 PM, Sam Ruby wrote: Anybody care to mark up what they would like to see the following look like? http://intertwingly.net/stories/2008/09/12/estest.html Shipt it! (Not in ES3.1, certainly in Firefox 3.1 if we can... :-) /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use decimal
On Sep 17, 2008, at 10:06 PM, Mark S. Miller wrote: 0/-0 != 0/0. Does it thus seem wrong that -0 === 0? Well, yes, actually it does seem wrong to me, but we all accept that particular wrongness. This is just more of the same. A lot more. Two wrongs don't make a right. One exception to the rule is better than two, or 2^53 or larger. apart from somthing like significance is a huge new set of exceptions. A large enough set that we can no longer understand === as approximating operational equivalence. If instead we understand === to be asking whether two operands are cohorts, and we define cohorts to be those numeric values that exactly represent a given real number, then 1) -0 vs 0 is no longer irregular 2) We can explain why 1.5 === 1.5m === 1.5000m 3) We can explain why 1.1 !== 1.1m. 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. As a reductio ad absurdum, consider that we can place ECMAScript strings in one-to-one correspondence with arbitrary precision integers by considering them as base 2^16 numbers, but surely no one would argument that this implies 00 === 3145776L. That's because in defining a type, it is not just the set of represented values that matters for type equivalence, but also behavior of operations on that type. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
