Re: On IE __proto__ test cases
on 3.1.1-10 AFAIK `Object.preventExtension({})` makes __proto__ immutable.
Since `Object.freeze({})` includes that `preventExtension` call, immutable
should be so no `y` inherited there.
On Thu, Jul 4, 2013 at 3:10 PM, David Bruant bruan...@gmail.com wrote:
Hi,
So, there are standard tests now for ES6!
http://samples.msdn.microsoft.**com/ietestcenter/#javascripthttp://samples.msdn.microsoft.com/ietestcenter/#javascript
I'd like to discuss some of the __proto__ tests at
http://samples.msdn.microsoft.**com/ietestcenter/Javascript/**
testcases__proto_.htmlhttp://samples.msdn.microsoft.com/ietestcenter/Javascript/testcases__proto_.html
# 3.1.1-10 Object.freeze(Object.**prototype) disables __proto__
function testcase() {
Object.freeze(Object.**prototype);
var a = new Object();
a.__proto__ = { y: 2 };
return a.y === undefined;
}
I'm not sure I see why this test should succeed. Freezing a should
prevent its [[Prototype]] from being changed, but I don't see why it would
be the case for Object.prototype.
(same for 3.1.1-9 for Object.seal)
# 3.1.1-11[[DefineOwnProperty]] UnderScoreProtoEnabled is set to true
when Object.prototype is set with default values
function testcase() {
Object.defineProperty(Object.**prototype, __proto__, { writable:
true, enumerable: false, configurable: true });
var obj = {};
obj.__proto__ = { x: 10 };
return obj.x === 10;
}
I don't fully understand this test case. I think that overriding
Object.prototype.__proto__ with a data attribute should remove its magic.
(same for 3.1.1-7, 3.1.2-4-1+bcd )
# 3.1.1-4Object.prototype.__proto__ is data property with
{writable:true, enumerable:false, configurable:true, value:null} attributes
function testcase() {
var desc = Object.**getOwnPropertyDescriptor(**Object.prototype,
__proto__);
return desc.writable === true
desc.enumerable === false
desc.configurable === true
desc.value === null;
}
... hmm... I admire the sense of humor of whoever wrote that test.
TC39 Meeting notes from May 2013:
https://github.com/rwldrn/**tc39-notes/blob/master/es6/**
2013-05/may-21.md#**consensusresolution-5https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-05/may-21.md#consensusresolution-5:
__proto__ is an accessor on Object.prototype.
# 3.1.1-6 Modification of Object.prototype.__proto__ causes
UnderScoreEnabled to be set to false. Setting it to {}
function testcase() {
Object.defineProperty(Object.**prototype, __proto__, {});
var obj = new Object();
obj.__proto__ = { y: 2 };
return obj.y === undefined;
}
I believe the Object.defineProperty line is a no-op, so the test should
fail.
# 3.1.2-2-14b [[Put]] __proto__ with value {y:2} on window object
function testcase() {
window.__proto__ = { y: 2 };
return window.y === undefined;
}
window is not part of ECMAScript. This test might as well throw a
ReferenceError.
As far as the global object, I don't think it's status on [[Prototype]] is
very clear from a standard standpoint, so I would recommend not having
tests for that.
I only looked at the tests failing in Firefox, there are probably other
errors.
It would be good if the tests were reviewed carefully *before* becoming
part of any sort of conformance test suite.
David
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
I'm only commenting on the proposals that seem to be in the current draft, because I'm reviewing a patch that adds only those particular constants. :-) Just to be clear why I'm saying nothing about the other constants, neither to praise nor to disparage. On 03/09/2012 08:00 PM, Roger Andrews wrote: Number.EPSILON == 2^-52 The difference between 1 and the smallest value 1 that is representable as a floating-point number. Why pick this particular epsilon? Why not, say, 2**-1074 instead, as the difference between 0 and the next largest number? Seeing only the name I'd have guessed 2**-1074. Number.MAX_INTEGER == 2^53 - 1 The maximum integer value that can be stored in a number without losing precision. (OK, so technically 2^53 can be stored, but that's an anomaly.) Why discount the anomaly? Looking at SpiderMonkey's source code, we have http://mxr.mozilla.org/mozilla-central/search?string=%3C%3C%2053 as vaguely representative of most of the places using a number like this, I think -- could be others not using the 53 string, but that's probably a fair sample. Ignore the RNG_DSCALE one, that's a red herring. But all the others use 2**53 as the pertinent value. (The dom/bindings/PrimitiveConversions.h hits using 2**53 -1 is a bug, I'm told, due to recent spec changes.) So if this constant is to exist, and I think it's a fair constant to add, why would it not be 2**53? Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 4 ES6 draft is available
On 05/07/2012 01:31 PM, Allen Wirfs-Brock wrote: added Number.EPSILON,MAX_INTEGER,parseInt, parseFloat,isNaN,isFinite, isInteger, toInt Modulo the semantic quirks in my last response, talking about the values and intended meanings of EPSILON and MAX_INTEGER, I think it would be better to write out these values not in decimal form in the spec: that is, as 2**53 or 2**-52 or 2**53 - 1 or similar. Just a stylistic nit. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
Jeff Walden wrote: I'm only commenting on the proposals that seem to be in the current draft, because I'm reviewing a patch that adds only those particular constants. :-) Just to be clear why I'm saying nothing about the other constants, neither to praise nor to disparage. On 03/09/2012 08:00 PM, Roger Andrews wrote: Number.EPSILON == 2^-52 The difference between 1 and the smallest value1 that is representable as a floating-point number. Why pick this particular epsilon? Why not, say, 2**-1074 instead, as the difference between 0 and the next largest number? Seeing only the name I'd have guessed 2**-1074. See http://en.wikipedia.org/wiki/Machine_epsilon. Number.MAX_INTEGER == 2^53 - 1 The maximum integer value that can be stored in a number without losing precision. (OK, so technically 2^53 can be stored, but that's an anomaly.) Why discount the anomaly? Looking at SpiderMonkey's source code, we havehttp://mxr.mozilla.org/mozilla-central/search?string=%3C%3C%2053 as vaguely representative of most of the places using a number like this, I think -- could be others not using the 53 string, but that's probably a fair sample. Ignore the RNG_DSCALE one, that's a red herring. But all the others use 2**53 as the pertinent value. (The dom/bindings/PrimitiveConversions.h hits using 2**53 -1 is a bug, I'm told, due to recent spec changes.) So if this constant is to exist, and I think it's a fair constant to add, why would it not be 2**53? I think you have a point! From http://en.wikipedia.org/wiki/Double-precision_floating-point_format, Between 2^52 =4,503,599,627,370,496 and 2^53 =9,007,199,254,740,992 the representable numbers are exactly the integers. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On Jul 9, 2013, at 4:14 PM, Brendan Eich wrote: Jeff Walden wrote: ... Number.MAX_INTEGER == 2^53 - 1 The maximum integer value that can be stored in a number without losing precision. (OK, so technically 2^53 can be stored, but that's an anomaly.) Why discount the anomaly? Looking at SpiderMonkey's source code, we havehttp://mxr.mozilla.org/mozilla-central/search?string=%3C%3C%2053 as vaguely representative of most of the places using a number like this, I think -- could be others not using the 53 string, but that's probably a fair sample. Ignore the RNG_DSCALE one, that's a red herring. But all the others use 2**53 as the pertinent value. (The dom/bindings/PrimitiveConversions.h hits using 2**53 -1 is a bug, I'm told, due to recent spec changes.) So if this constant is to exist, and I think it's a fair constant to add, why would it not be 2**53? I think you have a point! From http://en.wikipedia.org/wiki/Double-precision_floating-point_format, Between 2^52 =4,503,599,627,370,496 and 2^53 =9,007,199,254,740,992 the representable numbers are exactly the integers. Isn't the anomaly (and the issue) that 2^53 (9,007,199,254,740,992) is both the upper-end of the range of integers that can be exactly represented in IEEE float64, it is is also the representation of the smallest positive integer (2^53+1) that cannot be exactly represented. In other words, if you see the IEEE float 64 encoding of 9,007,199,254,740,992 you don't know if it is an exact representation of 2^53 or an approximate representation of 2^53+1. 2^53-1 is the max integer value whose encoding is not also an approximation of some other integer value. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
Allen Wirfs-Brock wrote: Isn't the anomaly (and the issue) that 2^53 (9,007,199,254,740,992) is both the upper-end of the range of integers that can be exactly represented in IEEE float64, it is is also the representation of the smallest positive integer (2^53+1) that cannot be exactly represented. In other words, if you see the IEEE float 64 encoding of 9,007,199,254,740,992 you don't know if it is an exact representation of 2^53 or an approximate representation of 2^53+1. 2^53-1 is the max integer value whose encoding is not also an approximation of some other integer value. You're right, that's the reason. It helps make sense of some of the code Jeff's mxr.mozilla.org link shows. We really do have a fencepost at 2^53, not a maximum precise integer value. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
Mark S. Miller wrote: FWIW, we include 2**53 as in the contiguous range of exactly representable natural numbers. https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492 It's exactly representable, but its representation is not exact. If that makes sense! /be On Tue, Jul 9, 2013 at 5:50 PM, Jorge Chamorro jo...@jorgechamorro.com mailto:jo...@jorgechamorro.com wrote: On 10/07/2013, at 02:34, Allen Wirfs-Brock wrote: On Jul 9, 2013, at 4:14 PM, Brendan Eich wrote: Jeff Walden wrote: ... Number.MAX_INTEGER == 2^53 - 1 The maximum integer value that can be stored in a number without losing precision. (OK, so technically 2^53 can be stored, but that's an anomaly.) Why discount the anomaly? Looking at SpiderMonkey's source code, we havehttp://mxr.mozilla.org/mozilla-central/search?string=%3C%3C%2053 as vaguely representative of most of the places using a number like this, I think -- could be others not using the 53 string, but that's probably a fair sample. Ignore the RNG_DSCALE one, that's a red herring. But all the others use 2**53 as the pertinent value. (The dom/bindings/PrimitiveConversions.h hits using 2**53 -1 is a bug, I'm told, due to recent spec changes.) So if this constant is to exist, and I think it's a fair constant to add, why would it not be 2**53? I think you have a point! From http://en.wikipedia.org/wiki/Double-precision_floating-point_format, Between 2^52 =4,503,599,627,370,496 and 2^53 =9,007,199,254,740,992 the representable numbers are exactly the integers. Isn't the anomaly (and the issue) that 2^53 (9,007,199,254,740,992) is both the upper-end of the range of integers that can be exactly represented in IEEE float64, it is is also the representation of the smallest positive integer (2^53+1) that cannot be exactly represented. In other words, if you see the IEEE float 64 encoding of 9,007,199,254,740,992 you don't know if it is an exact representation of 2^53 or an approximate representation of 2^53+1. 2^53-1 is the max integer value whose encoding is not also an approximation of some other integer value. Or, in other words, the IEEE-754 doubles 9,007,199,254,740,992 and 9,007,199,254,740,993 are equal: 9007199254740992 === 9007199254740993 true -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 10/07/2013, at 03:23, Brendan Eich wrote: Mark S. Miller wrote: FWIW, we include 2**53 as in the contiguous range of exactly representable natural numbers. https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492 It's exactly representable, but its representation is not exact. If that makes sense! 2**53 is exactly representable, but it gets the exact same representation as 2**53 + 1 -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
Jorge Chamorro wrote: On 10/07/2013, at 03:23, Brendan Eich wrote: Mark S. Miller wrote: FWIW, we include 2**53 as in the contiguous range of exactly representable natural numbers. https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#492 It's exactly representable, but its representation is not exact. If that makes sense! 2**53 is exactly representable, but it gets the exact same representation as 2**53 + 1 Yes, you said that last time, and Allen said it before in the message to which you replied :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 07/09/2013 04:14 PM, Brendan Eich wrote: Why pick this particular epsilon? Why not, say, 2**-1074 instead, as the difference between 0 and the next largest number? Seeing only the name I'd have guessed 2**-1074. See http://en.wikipedia.org/wiki/Machine_epsilon. Hmm, my memory of the meaning of epsilon was obviously horribly wrong. :-) This is obviously sane then. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: more numeric constants please (especially EPSILON)
On 10/07/2013, at 03:49, Mark S. Miller wrote:
I initially didn't think this mattered, but it is an excellent and important
point. Look at the use I make of Nat in Dr.SES in Figure 1 of
http://research.google.com/pubs/pub40673.html:
var makeMint = () = {
var m = WeakMap();
var makePurse = () = mint(0);
var mint = balance = {
var purse = def({
getBalance: () = balance,
makePurse: makePurse,
deposit: (amount, srcP) =
Q(srcP).then(src = {
Nat(balance + amount);
m.get(src)(Nat(amount));
balance += amount;
})
});
var decr = amount = { balance = Nat(balance - amount); };
m.set(purse, decr);
return purse;
};
return mint;
};
Because Nat includes 2**53, this code actually fails to enforce conservation
of currency!! I've repeatedly claimed this conservation property about this
code and code like it for a long time now, to many audiences and in several
papers. There have been several exercises proving some properties of this
code correct and laying the groundwork for proving conservation of currency.
However, none have previously spotted this hole.
Right, if balance+amount ever result in 2**53+1, the code would rather see it
(and save it!) as 2**53.
Sort of a new kind of off by one error... for the wikipedia?
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
