Re: use decimal

Mark S. Miller wrote: > 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(). Depends on which proposal you're referrin

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 pr

Re: use decimal

Maciej Stachowiak wrote: > On Sep 18, 2008, at 6:03 PM, Mark S. Miller wrote: >> [re: ] >> >> 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

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 dif

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 flo

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 operat

Re: use decimal

2008/9/18 Mark S. Miller <[EMAIL PROTECTED]> > > * 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 (smallest r

Re: use decimal

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.a

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 differenc

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 sa

Re: use decimal

-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. /be Sent from my iPhone On Sep 18, 2008, at 7:08 PM, "Mark S. Miller" <[EMAIL PROTECTED]> wrote: On Thu, Sep 18, 2008 at 8:00 AM, Mike Cowlishaw <[EMAIL PROTECTED]>

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

Re: use decimal

On Sep 18, 2008, at 7:35 AM, Mark S. Miller wrote: 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

Re: use decimal

On Sep 18, 2008, at 1:06 AM, Mark S. Miller wrote: > "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

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?

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 /

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 !

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, y

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

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. >

Re: use decimal

> > 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. &g

Re: use decimal

2008/9/17 Mark S. Miller <[EMAIL PROTECTED]>: > On Wed, Sep 17, 2008 at 6:54 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >> >> I particularly would prefer that any dialect pragmas ("use strict" as >> much as "use decimal") should have effe

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 _

Re: use decimal

ore, 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 (with

Re: use decimal

else that mixed mode > should coerce to decimal. Or, at least, I have no objection to that > position. > > > 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 ===

Re: use decimal

2008/9/17 Maciej Stachowiak <[EMAIL PROTECTED]>: > > Were we to adopt this, then I think "use decimal" should condition only > whether an unqualified numeric literal be interpreted as binary or decimal > floating point. We should then have a suffix which means binary

Re: use decimal

On Wed, Sep 17, 2008 at 6:54 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > I particularly would prefer that any dialect pragmas ("use strict" as > much as "use decimal") should have effects that can all be explained > as occuring at parse/compile t

Re: use decimal

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. > > Doug's previous proposal where "use decimal" merely determined whether > a co

Re: use decimal

;> Is that the consensus of the group? >> >> I certainly do not agree with his proposal. Other embers of the group >> may speak for themselves, but it was not my understanding previously >> that anyone wanted to go down such a road. > > Doug's previous proposal whe

Re: use decimal

the same result as > > typeof a == typeof b && a == b. Agreed. > Without "use decimal", typeof 1.1m must not be "number" to preserve > this same invariant. Otherwise (without "use decimal") 1.5m == 1.5 > but 1.1m != 1.1, so without making typeof

Re: use decimal

>>> applications - the performance would not be acceptable. So we >>> should not go down a path based on the assumption that binary >>> floating point can be removed. >> >> If we agree that binary64 isn't a "bug" that needs to be removed, >>

Re: use decimal

that > removed another feature that Doug dislikes, such as "with". Am I > missing something? > Without advocating either Crock's or Sam's positions on "use decimal", I will take issue with the above. Proposed ES3.1 "use strict" is an opt-in tha

Re: use decimal

an be removed. > > If we agree that binary64 isn't a "bug" that needs to be removed, > wouldn't the simplest solution that could possibly work be separate > number and decimal data types that can be freely convertible between > each other, and the absolutely

Re: use decimal

plications - the performance would not be acceptable. So we should not > go down a path based on the assumption that binary floating point can be > removed. If we agree that binary64 isn't a "bug" that needs to be removed, wouldn't the simplest solution that could pos

Re: use decimal

On Sep 17, 2008, at 2:34 PM, Douglas Crockford wrote: > Sam Ruby wrote: > >> To the extent that I understand Doug's proposal, it essentially is an >> opt-in that would remove a feature (binary64 floating points); and >> therefore would likely be about as successful as an opt-in that >> removed an

Re: use decimal

Sam Ruby wrote: > To the extent that I understand Doug's proposal, it essentially is an > opt-in that would remove a feature (binary64 floating points); and > therefore would likely be about as successful as an opt-in that > removed another feature that Doug dislikes, such as "with". Am I > missi

Re: use decimal

On Wed, Sep 17, 2008 at 4:55 PM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Sep 17, 2008, at 4:01 PM, Douglas Crockford wrote: > >> It may be best to defer decimal to Harmony so we can try some >> experiments and have more confidence. > > Absolutely agree (someone added es-discuss to the cc: list

Re: use decimal

On Sep 17, 2008, at 4:01 PM, Douglas Crockford wrote: > It may be best to defer decimal to Harmony so we can try some > experiments and have more confidence. Absolutely agree (someone added es-discuss to the cc: list already). See https://mail.mozilla.org/pipermail/es-discuss/2008-August/007136.

Re: use decimal

otherwise behave as before. >> >> An implementation of decimal that does not meet these goals must be >> rejected. >> >> I think these goals require that typeof decimal_number produce >> 'number'. > > Only under the "use decimal" pragma, r

Re: use decimal

decimal that does not meet these goals must be > rejected. > > I think these goals require that typeof decimal_number produce > 'number'. Only under the "use decimal" pragma, right? > It requires that a === b produce the same result as typeof a == >