> I believe that we have a solution that everybody might not find ideal,
> but hopefully can live with, which I will outline below with examples:
>
> typeof(1m) === "decimal"
> 1.1m === 1.10m
> (1.10m).toString() === "1.10"
> (1e+3m).toString() === "1000"
>
> Additionally, there will be another met
On Thu, Sep 25, 2008 at 10:24 AM, Mike Cowlishaw <[EMAIL PROTECTED]> wrote:
>
> 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
[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 th
2008/9/24 Maciej Stachowiak <[EMAIL PROTECTED]>:
>
> On Sep 24, 2008, at 8:41 AM, Michael wrote:
>
> Maciej wrote:
>
> "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?"
>
: es-discuss@mozilla.org
Subject: Re: ES Decimal Status
On Sep 24, 2008, at 8:41 AM, Michael wrote:
Maciej wrote:
"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&#
> 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 *).
Mike;
The claim that using only integers and only multiplication will save array
indexing is false. Under your current proposal exa
Brendan Eich wrote:
>
> 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
>
On Sep 24, 2008, at 9:18 AM, Sam Ruby wrote:
[over-top-citing trimmed]
The concern remains, though. Not due to power-of-five problems that
would lead to 0.09987 or the like, but from cases where a
number was spelled with extra trailing zeros (in external data,
e.g. a
spreadsheet)
On Sep 24, 2008, at 9:17 AM, Brendan Eich wrote:
> On Sep 24, 2008, at 9:01 AM, Mike Cowlishaw wrote:
>> 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.
>
On Sep 24, 2008, at 9:01 AM, Mike Cowlishaw wrote:
>
>> 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
Brendan Eich wrote:
> On Sep 24, 2008, at 8:28 AM, Sam Ruby wrote:
>
My apologies. That wasn't the question I was intending.
Can you identify code that today depends on numeric binary 64 floating
point which makes use of operations such as unrounded division and
depends o
On Sep 24, 2008, at 9:01 AM, Mike Cowlishaw wrote:
>> 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) whic
> Maciej wrote:
> "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?"
I would say this is indeed a problem. I'm of the opinion that
decimal128 and binary64 should behave iden
> >> 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
On Sep 24, 2008, at 8:41 AM, Michael wrote:
Maciej wrote:
“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?”
This is not quite true as you can see here:
var a = [];
a[1]
On Sep 24, 2008, at 8:28 AM, Sam Ruby wrote:
>>>
>>> My apologies. That wasn't the question I was intending.
>>>
>>> Can you identify code that today depends on numeric binary 64
>>> floating
>>> point which makes use of operations such as unrounded division and
>>> depends on trailing zeros b
On Sep 24, 2008, at 8:28 AM, Sam Ruby wrote:
>>> My apologies. That wasn't the question I was intending.
>>>
>>> Can you identify code that today depends on numeric binary 64
>>> floating
>>> point which makes use of operations such as unrounded division and
>>> depends on trailing zeros being
On Sep 24, 2008, at 8:41 AM, Michael wrote:
Maciej wrote:
“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?”
This is not quite true as you can see here:
var a = [];
a[1] =
Maciej wrote:
"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?"
This is not quite true as you can see here:
var a = [];
a[1] = "foo";
a[1.00] = "bar";
WScri
Maciej Stachowiak wrote:
>
> You probably meant to send this to the list.
Oops. Resending. Thanks!
> - Maciej
>
> On Sep 24, 2008, at 8:17 AM, Sam Ruby wrote:
>
>> On Wed, Sep 24, 2008 at 10:45 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Sep 24, 2008, at 7:31 AM, Sam Rub
On Sep 24, 2008, at 7:31 AM, Sam Ruby wrote:
> Maciej Stachowiak wrote:
>> On Sep 24, 2008, at 3:33 AM, Mike Cowlishaw wrote:
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,
Maciej Stachowiak wrote:
> On Sep 24, 2008, at 3:33 AM, Mike Cowlishaw wrote:
>
>>> 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
On Sep 24, 2008, at 3:33 AM, Mike Cowlishaw wrote:
>> 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 as
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
> >>>
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 cle
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. Despite objections, I still get the following results:
>>>
>>> 1/3m -
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. Despite objections, I still get the following results:
>>
>> 1/3m - 1/3m produces 0e-34
>>
>> 1e12m
> 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
>
>
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
> 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
On Fri, Sep 12, 2008 at 7:01 PM, David-Sarah Hopwood
<[EMAIL PROTECTED]> wrote:
> Sam Ruby wrote:
>> On Fri, Sep 12, 2008 at 4:02 PM, David-Sarah Hopwood
>> <[EMAIL PROTECTED]> wrote:
>>> Sam Ruby wrote:
Description of ES 3.1m decimal support
number and decimal are distinct prim
Sam Ruby wrote:
> On Fri, Sep 12, 2008 at 4:02 PM, David-Sarah Hopwood
> <[EMAIL PROTECTED]> wrote:
>> Sam Ruby wrote:
>>> Description of ES 3.1m decimal support
>>>
>>> number and decimal are distinct primitive data types. The
>>> former is based on IEEE 754 binary 64 floating point, th
Sam Ruby wrote:
> Description of ES 3.1m decimal support
>
> number and decimal are distinct primitive data types. The
> former is based on IEEE 754 binary 64 floating point, the latter
> is based on IEEE 754r decimal 128 floating point.
[...]
> Conversion from number to decim
Preface:
Poor Pratap. He's folded in updates from me on the various
operators several times now. It has gone from Type(Result(n))
is Decimal, to Form(Result(n)) is Decimal, and now reads
Result(n) instanceof Decimal. I believe that the current
consensus is that the orig
34 matches
Mail list logo
