Re: Decimal comparisons
On Fri, Sep 19, 2008 at 9:39 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Sep 19, 2008, at 10:27 AM, Sam Ruby wrote:
>
>> On Fri, Sep 19, 2008 at 9:21 AM, Brendan Eich <[EMAIL PROTECTED]>
>> wrote:
>>> On Sep 19, 2008, at 8:45 AM, Sam Ruby wrote:
>>>
> We've been around this block on the list. I'm with you: typeof 1.1m
> == "decimal" and we'll take chances with code that thinks it knows
> every result string that typeof might produce.
>
What is the best way to check if a value is numeric?
Existing code that uses:
if(typeof x == "number") { ... }
- could be changed to:-
if(typeof x == "number" || typeof x == "decimal") { ... }
- is this the proposed solution?
ES4 had something like:-
if(x is Number){...}
Thank you,
Garrett
> /be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Sep 19, 2008, at 10:27 AM, Sam Ruby wrote: > On Fri, Sep 19, 2008 at 9:21 AM, Brendan Eich <[EMAIL PROTECTED]> > wrote: >> On Sep 19, 2008, at 8:45 AM, Sam Ruby wrote: >> >>> Does the committee feel that it can ever add new values to typeof >>> under any circumstances? >> >> Certainly not if there is "opt-in version selection". > > The "opt-in" version selection techniques I recall being discussed > were scoped to compilation units. Are you suggesting that the > "typeof" a value could produce different results based on which > compilation unit evaluated the expression? No, I'm simply pointing out that there's no perfectly compatible way to add decimal to ES. > **shudder** We've been around this block on the list. I'm with you: typeof 1.1m == "decimal" and we'll take chances with code that thinks it knows every result string that typeof might produce. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Sep 19, 2008, at 10:25 AM, Kris Zyp wrote:
>>> Consider 1.1m instead of 1m.
>
> Would be:
> '{"foo":1.1}'
Ok, how about serializing the object you get by evaluating {"foo":0.1
+0.2}?
>> JSON does not provide for decimal, and receiver-makes-it-wrong is
>> a bug.
>> JSON would need to be extended to handle decimal reliably.
>
> No, JSON only provides for decimal, JSON uses radix 10 to encode
> numbers,
Of course it uses base 10 for encoding and parsing, but the RFC says
nothing about the required precise value of a number in any
representation -- including in base 10.
> it
> has no support for binary. JSON doesn't need to be extended (unless
> you want
> to see binary added, but I don't that would be popular).
All JSON codecs today (AFAIK -- all the ones written in JS) use 64-
bit double precision, not any kind of decimal, to represent numbers.
> JSON makes no
> assertions about what format a receiver must use to store the
> numbers it
> receives, it transfers numbers in decimal format, and
> implementations can
> and should be able to use any format they desire to internally
> represent it
> based on their needs and expectations.
Conversion plus rounding means that a JSON peer may not be able to
ignore storage format, which is double. It's possible that real JSON-
based apps depend on this de-facto standard. At any rate, under-
specification in the RFC allows it, and via Postel's Law it is likely
that apps *do* depend on double being the storage format.
> Today implementations do vary in
> which format they choose to use,
Do you know of any that use decimal or any format other than IEEE 754
double?
> but there is no restriction preventing
> implementations from using decimal formats for de-serialization of
> numbers,
> and it seems like it would make sense for JavaScript to do so when
> decimals
> become available.
Could be. Best case, there's no significantly-used web app or page
that depends on JSON peers storing using double. We just do not know.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Fri, Sep 19, 2008 at 9:21 AM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Sep 19, 2008, at 8:45 AM, Sam Ruby wrote: > >> Does the committee feel that it can ever add new values to typeof >> under any circumstances? > > Certainly not if there is "opt-in version selection". The "opt-in" version selection techniques I recall being discussed were scoped to compilation units. Are you suggesting that the "typeof" a value could produce different results based on which compilation unit evaluated the expression? **shudder** - Sam Ruby ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
>> +1 for typeof 1m === 'number'. As an example of breakage, I believe
>> Crockford's current version of his JSON library would not do as I would
>> desire with decimals:
>>
>> JSON.stringify({foo:1m}) -> "{\"foo\":undefined}"
>
> Why is that worse than producing '{"foo":1}'?
The fact that you know what I was expecting without me saying seems like
good evidence.
> Consider 1.1m instead of 1m.
Would be:
'{"foo":1.1}'
> JSON does not provide for decimal, and receiver-makes-it-wrong is a bug.
> JSON would need to be extended to handle decimal reliably.
No, JSON only provides for decimal, JSON uses radix 10 to encode numbers, it
has no support for binary. JSON doesn't need to be extended (unless you want
to see binary added, but I don't that would be popular). JSON makes no
assertions about what format a receiver must use to store the numbers it
receives, it transfers numbers in decimal format, and implementations can
and should be able to use any format they desire to internally represent it
based on their needs and expectations. Today implementations do vary in
which format they choose to use, but there is no restriction preventing
implementations from using decimal formats for de-serialization of numbers,
and it seems like it would make sense for JavaScript to do so when decimals
become available.
Kris
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Sep 19, 2008, at 8:45 AM, Sam Ruby wrote: > The motivation for the fourth choice on the first question is to > produce a value that is is valid JSON, is unlikely to be widely used > today (by virtue of the capital E), will fall back to binary 64 many > JSON implementations, and can be used as a signal to produce a decimal > value in ECMAScript. I'm merely putting this forward as brainstorming > at this point, I'm less than enthusiastic about it myself. http://www.ietf.org/rfc/rfc4627.txt underspecifies enough to allow this kind of trick, but it is possible that the de-facto JSON standard requires IEEE double at the limit. > Does the committee feel that it can ever add new values to typeof > under any circumstances? Certainly not if there is "opt-in version selection". Even with "the default version", people on this list have argued that adding a new typeof-type does the least harm and probably could be pulled off, because most typeof-using code does not test type-code values exhaustively. But it's an open question. > FWIW, my preference is (in order): decimal, object, then number. I'm with you there. The neo-Platonist camp (:-P) argues for "number" based on Real numbers, but machines and ES numbers do not behave like Reals. I don't believe "object" is thinkable without !0m => false, or widely distributed code will fail on decimal values. > I think it is preposterous to assume that ECMAScript can never add any > new data types. Agreed. > The version of JSON that is included in the language > will be aware of the data types supported in that edition of > ECMAScript. What json2.js does for decimal, it does for any object > data type that it doesn't understand. This is not so clear. JSON is a cross-language, inter-networked data standard. It won't be easy to grow in parallel to ES standards. It shouldn't grow without versioning, which I'm sure Doug agrees should be avoided at all costs. The risk for JSON is that because it underspecifies, real-world uses bind to specific implementations details such as "number" being double. > As far as what the builtin JSON functionality slated for ECMAScript > 3.1 does when parsing "[1.1]", a case could be made that producing > [1.1m] is the closest to the expressing what the data structure > actually conveys, is readily convertible to binary 64 floating point > when needed, and typical JSON isn't anywhere near as performance > critical as vector graphic intensive functions are. Yeah, you're right that this case could be made from the RFC, although the RFC talks only about range restrictions, not radix or rounding. But from an interoperating JSON peer today, you might find failures to round-trip. That seems bad. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Fri, Sep 19, 2008 at 2:29 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Sep 18, 2008, at 10:58 PM, Kris Zyp wrote:
>
* Like Crock, I prefer that typeof 1m === 'number'. However, unlike
Crock's
and Brendan's agreement, I think this should be unconditional. I
think it
would be horrible for 'typeof X' to depend not only on the value
of X but
also on the mode of the program unit in which the typeof appears.
Please
don't do that.
>>
>> +1 for typeof 1m === 'number'. As an example of breakage, I believe
>> Crockford's current version of his JSON library would not do as I
>> would
>> desire with decimals:
>>
>> JSON.stringify({foo:1m}) -> "{\"foo\":undefined}"
I'm not sure which library is Crockford's but trying the one on
json.org produces the following:
js> load('json2.js')
js> JSON.stringify({foo:1m})
{}
js> JSON.stringify([1,2m,3])
[1,null,3]
> Why is that worse than producing '{"foo":1}'? Consider 1.1m instead
> of 1m.
>
> JSON does not provide for decimal, and receiver-makes-it-wrong is a
> bug. JSON would need to be extended to handle decimal reliably.
Given that JSON is slated for 3.1, and Decimal is slated for no
earlier than 3.1; we need to turn that into questions...
1) What should JSON.stringify([1.1m]) produce?
* [1.1]
* ["1.1"]
* ["1.1m"]
* [1.1E0]
2) What should 1.2m-JSON.parse("[1.1]")[0] produce?
* 0.099911182158029987477
* 0.1
The motivation for the fourth choice on the first question is to
produce a value that is is valid JSON, is unlikely to be widely used
today (by virtue of the capital E), will fall back to binary 64 many
JSON implementations, and can be used as a signal to produce a decimal
value in ECMAScript. I'm merely putting this forward as brainstorming
at this point, I'm less than enthusiastic about it myself.
As a possibly related aside, I think we need to more precisely specify
how ECMAScript will handle dates in JSON.
>> I think there is a may be a lot of code that is dependent on typeof
>> returning a one of exactly six possible values.
>
> There may be "a lot". There's probably some. But there's also
> probably some code that breaks if decimals are added and they have
> "number" typeof-type. There is no non-breaking way to add decimal.
Brief summary, wildly overstating a number of points omitting a *lot*
of important details so that we can focus on the bigger issues:
number: "===" would no longer is a reasonable proxy for object identity
decimal: code that does not handle new types won't handle decimal
object: null is no longer the only object value that is false
Key questions:
Can we live with (typeof 1.5 == typeof 1.5m) && (1.5 !== 1.5m) being true?
Can we live with (1.5===1.5m) && (1.5/10 !== 1.5m/10) being true?
Can we live with !(0.0m) being false?
Can we live with? !(0.0m) && (0.0m !== null) being true?
Does the committee feel that it can ever add new values to typeof
under any circumstances?
If the answer is no to all of the above, then decimal (nor any other
similar data type) can never be added to the language.
FWIW, my preference is (in order): decimal, object, then number.
I think it is preposterous to assume that ECMAScript can never add any
new data types. The version of JSON that is included in the language
will be aware of the data types supported in that edition of
ECMAScript. What json2.js does for decimal, it does for any object
data type that it doesn't understand.
As far as what the builtin JSON functionality slated for ECMAScript
3.1 does when parsing "[1.1]", a case could be made that producing
[1.1m] is the closest to the expressing what the data structure
actually conveys, is readily convertible to binary 64 floating point
when needed, and typical JSON isn't anywhere near as performance
critical as vector graphic intensive functions are.
> /be
- Sam Ruby
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
On Sep 18, 2008, at 10:58 PM, Kris Zyp wrote:
>>> * Like Crock, I prefer that typeof 1m === 'number'. However, unlike
>>> Crock's
>>> and Brendan's agreement, I think this should be unconditional. I
>>> think it
>>> would be horrible for 'typeof X' to depend not only on the value
>>> of X but
>>> also on the mode of the program unit in which the typeof appears.
>>> Please
>>> don't do that.
>
> +1 for typeof 1m === 'number'. As an example of breakage, I believe
> Crockford's current version of his JSON library would not do as I
> would
> desire with decimals:
>
> JSON.stringify({foo:1m}) -> "{\"foo\":undefined}"
Why is that worse than producing '{"foo":1}'? Consider 1.1m instead
of 1m.
JSON does not provide for decimal, and receiver-makes-it-wrong is a
bug. JSON would need to be extended to handle decimal reliably.
> I think there is a may be a lot of code that is dependent on typeof
> returning a one of exactly six possible values.
There may be "a lot". There's probably some. But there's also
probably some code that breaks if decimals are added and they have
"number" typeof-type. There is no non-breaking way to add decimal.
/be
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Decimal comparisons
>> * Like Crock, I prefer that typeof 1m === 'number'. However, unlike
>> Crock's
>> and Brendan's agreement, I think this should be unconditional. I think it
>> would be horrible for 'typeof X' to depend not only on the value of X but
>> also on the mode of the program unit in which the typeof appears. Please
>> don't do that.
+1 for typeof 1m === 'number'. As an example of breakage, I believe
Crockford's current version of his JSON library would not do as I would
desire with decimals:
JSON.stringify({foo:1m}) -> "{\"foo\":undefined}"
I think there is a may be a lot of code that is dependent on typeof
returning a one of exactly six possible values.
Kris
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Decimal comparisons
Mark S. Miller wrote: > * Like Crock, I prefer that typeof 1m === 'number'. However, unlike Crock's > and Brendan's agreement, I think this should be unconditional. I think it > would be horrible for 'typeof X' to depend not only on the value of X but > also on the mode of the program unit in which the typeof appears. Please > don't do that. Strongly agreed. The existing context-dependent operations in the ES3 spec (such as the hint to [[DefaultValue]]) are bad enough; we don't want to add more of them. > On Wed, Sep 17, 2008 at 12:49 PM, Brendan Eich wrote: >> I do not believe anyone wants typeof 1.5m != typeof 1.1m. > > 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. I do > agree that 1.5m == 1.5, but only because they represent the same real > number, not because they look the same. Agreed. In that case, we would have: x relop y <=> toReal(x) relop_Real toReal(y) [where 'toReal' maps either a binary or decimal value to the corresponding real value]. Note that the implementation of this semantics requires a primitive operation that compares a binary value with a decimal value; it's not sufficient to just have primitive binary->decimal conversion and decimal comparison operations. > I agree with Sam and apparently Crock and everyone else that mixed mode > should coerce to decimal. Or, at least, I have no objection to that > position. Mixed-mode should coerce to decimal except for ==, !=, <=, >=, since in those cases the definition above (based on comparing real values) should take precedence. (For < and >, the definition based on comparing real values, and the one based on coercion to decimal, are equivalent.) > 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 floating > point, so you can say it explicitly. Nothing else about the numerics should > be conditioned by the pragma. I have no strong opinion on this. Note, however, that under this semantics the value of Math.PI, for example, would have to stay as binary; it wouldn't implicitly change to decimal in a "use decimal" program. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
