additional Math function
brendan at mozilla.org
Fri Nov 2 13:24:06 PDT 2012
David Herman wrote:
> On Nov 2, 2012, at 12:05 PM, Yehuda Katz<wycats at gmail.com> wrote:
>> Seems like a small surface-area with a large impact on compilers.
>> At first glance, looks good to me.
>> Curiosity: Does this overlap with Brendan's work on value objects (i.e. will it become moot in the face of them)
> It could become unnecessary if you're working with value objects. If you had ordinary numbers, you'd have to coerce them to u32 and then multiply:
> var a = 0x7fffffff, b = 0x7fefefef; // both doubles
> var result = int32(a) * int32(b); // int32
> But value objects are still uncertain
I'm focusing on int64 and uint64 but making the framework as general
under the hood as possible (e.g., the operators stuff, a multimethod
variation that's inline-cacheable, based on an idea from Christian
The need for 64-bit ints is pretty strong in Node.js and I think this
means value objects are a priority for ES7.
> and at the very least much farther off into the future -- post-ES6. Engines could implement and ship Math.imul in very short order.
Agreed, and this kind of micro-evolution is important to support even
while working on value objects for post-ES6. It may be we end up with
int32 and uint32, but we don't need to if there's no strong use-case not
satisfied by Math.imul.
Note that there's no micro-evolutionary step involving Math.imul64 that
satisfies the int64/uint64 use-cases Node faces (buffer and file
sizes/offsets). You need 64-bit addition, subtraction, and probably
other operators -- and you need the data type, not just operations that
could be Math methods.
More information about the es-discuss