Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))

Oliver Hunt wrote: On Jul 15, 2013, at 8:15 AM, Mark S. Miller > wrote: No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. On tha

Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))

On Jul 15, 2013, at 8:15 AM, Mark S. Miller wrote: > > No wrapping object type -- those are legacy, to be avoided. See > http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing > is value not reference semantics. > > On that page: "It’s forwards-compatible with future me

Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))

Domenic Denicola wrote: From: Brendan Eich [bren...@mozilla.com] No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. Hmm, is `0UL.toString()` not possible then? What a

Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))

Mark S. Miller wrote: On Sun, Jul 14, 2013 at 10:39 PM, Brendan Eich > wrote: Mark S. Miller wrote: First, I wholeheartedly agree. JS is increasingly being used as a target of compilation. When I asking people doing so what they biggest pa

RE: Unlimited Integers (was: more numeric constants please (especially EPSILON))

From: Brendan Eich [bren...@mozilla.com] > No wrapping object type -- those are legacy, to be avoided. See > http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing > is value not reference semantics. Hmm, is `0UL.toString()` not possible then? What about `0UL + ""`? _

Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))

Mark S. Miller wrote: First, I wholeheartedly agree. JS is increasingly being used as a target of compilation. When I asking people doing so what they biggest pain point is, the lack of support for integers is often the first thing mentioned. int64/uint64 come up faster when compiling from C/

Re: more numeric constants please (especially EPSILON)

We should just add http://wiki.ecmascript.org/doku.php?id=strawman:bignums to ES7. /be Jeff Walden wrote: On 07/12/2013 04:53 PM, Mark S. Miller wrote: I would like a better API -- both less likely to be used unsafely and no harder (or not much harder) to use safely. Suggestions? In C++ y

Re: more numeric constants please (especially EPSILON)

On 07/12/2013 04:53 PM, Mark S. Miller wrote: > I would like a better API -- both less likely to be used unsafely and no > harder (or not much harder) to use safely. Suggestions? In C++ you'd want MS's SafeInt, or WTF's CheckedInt, with operator overloading and all that jazz. Without operator o

Re: more numeric constants please (especially EPSILON)

On 07/12/2013 04:09 PM, Tab Atkins Jr. wrote: > Mark's Nat() function *does* throw if the input isn't an > exactly-representable number. Yes. I'm arguing that's not helpful when you can compute an exactly-representable number, that is the result of an inexact calculation, like |Math.pow(2, 53)

Re: more numeric constants please (especially EPSILON)

On Fri, Jul 12, 2013 at 4:07 PM, Jeff Walden wrote: > On 07/09/2013 06:49 PM, Mark S. Miller wrote: >> Because Nat includes 2**53, this code actually fails to enforce conservation >> of currency!! > > The problem isn't that Nat includes 2**53. It's that you're performing an > operation that may

Re: more numeric constants please (especially EPSILON)

On 07/09/2013 06:49 PM, Mark S. Miller wrote: > Because Nat includes 2**53, this code actually fails to enforce conservation > of currency!! The problem isn't that Nat includes 2**53. It's that you're performing an operation that may compute an inexact value, then you're treating that inexact

Re: more numeric constants please (especially EPSILON)

On 10/07/2013, at 03:45, Brendan Eich wrote: > 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/s

Re: more numeric constants please (especially EPSILON)

On Jul 9, 2013, at 6:09 PM, 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 > What you want is: the continuous range of

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 > : > > var makeMint = () => { > var m = WeakMap(); >

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

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 exactl

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 repres

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

Re: more numeric constants please (especially EPSILON)

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^

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 represe

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

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:

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

more numeric constants please (especially EPSILON)

When getting rough with floating-point numbers, several constants come in handy, especially the "machine epsilon". (Note there is some confusion in definition of "machine epsilon" and "unit roundoff" - the definition below is the one we want and the one used in the C library.) Proposals: Num