4 ms·

This is a welcome feature. I think this for the most part is useful for WASM, but also storing/reading/writing to binary buffers as in handling file formats th

This is a welcome feature. I think this for the most part is useful for WASM, but also storing/reading/writing to binary buffers as in handling file formats that stores (u)int64s (such as f.ex. CAF on the Mac) and with binary protocol responses from environments such as Java/.Net that already supports bigints (and of course, eventually Node), finance calculations.. nice. Just curious, how will you deal with things like triple-comparing (`0x1n === 0x1` ?) internally (from the perspective of performance)? > BigInts [..] are always signed (in ref. to the >>> operator) Disclaimer: I haven't taken a deep-dive into the BigInt spec yet, but things like this comes to mind (say you want to shift and mask using unsigned 64-bit values): 0xffffffffffffffffn >> 24 => 0xffffffffffffffffn (hmm) 0xffffffffffffffffn >>> 24 => 0x000000ffffffffffn (but won't be supported) Will this be solvable with methods or will I need to instead manually mask off the signed remainder?

kllrnohj 8y ago
This looks to have nothing whatsoever to do with WASM. It is very much not just (u)int64 support, which is all WASM needs/wants. This is proper BigNumber. Which you could use for (u)int64 support, sure, but it'd be incredibly slow at it vs. the much simpler to do "just use an actual hardware 64-bit number"
apaprocki 8y ago
There is no implicit conversion. 0x1n === 0x1 returns false. See here: https://github.com/tc39/proposal-bigint#no-implicit-conversions-or-mixed-operands https://github.com/tc39/proposal-bigint#no-implicit-conversi... Shifting is specified here: https://tc39.github.io/proposal-bigint/#sec-numeric-types-bigint-leftShift https://tc39.github.io/proposal-bigint/#sec-numeric-types-bi...
venning 8y ago
There's a related article linked in OP that answers your questions: https://developers.google.com/web/updates/2018/05/bigint https://developers.google.com/web/updates/2018/05/bigint When mixing Number and BigInt, abstract equality (==) works fine, but strict equality (===) is always false, since they are two different primitive types. Most bitwise operators are allowed, so long as all operands are the same type (Number or BigInt). The only exception is zero-fill right shift (>>>) since that doesn't make any sense with respect to BigInts. From my console: (node 10 with --harmony-bigint) > 1n == 1 true > 1n === 1 false > 12345n >> 1 TypeError: Cannot mix BigInt and other types, use explicit conversions > 12345n >> 1n 6172n > 12345n >>> 1n TypeError: BigInts have no unsigned right shift, use >> instead
- epistemex 8y ago
  > since they are two different primitive types. Yes, I'm aware of this, but I was more asking in the realm of internal performance/optimization (as I sort of point out - and not necessarily because of the comparer). F.ex. they are in all practicality the same integer and in other cases, IIRC (please correct me if I'm wrong), V8 optimizes the native Number that could easily be stored internally as IEEE-754, to actual internal integers when using bit-ops on them (to indicate to the optimizer you handle integers) and so forth. In this case I was curious if this would be optimized internally so these comparisons could be moved directly to CPU registers as integers (assuming being on a 64-bit arc) and compared there, for example. But, future will tell - I'm equally aware of that optimizations is not first priority at this stage (it's just me excited to see this manifest). It's in any case a welcome and useful feature optimized or not. apaprocki linked (thanks!) to a method that can do unsigned right-shift via a method (1.1.11 BigInt::unsignedRightShift).
dragonwriter 8y ago
> I think this for the most part is useful for WASM Also, for compile-to-JS versions of languages where the hosted language has BigInts, which now [0] can be more fully equivalent to the non-JS implementations of the same language. I think it's a while before GC-dependent languages will be WASM hosted, but there are a lot that compile to JS. [0] where “now” is “sometime in the future where this has broad support among browsers”

kllrnohj 8y ago

This looks to have nothing whatsoever to do with WASM. It is very much not just (u)int64 support, which is all WASM needs/wants. This is proper BigNumber. Which you could use for (u)int64 support, sure, but it'd be incredibly slow at it vs. the much simpler to do "just use an actual hardware 64-bit number"

apaprocki 8y ago

There is no implicit conversion. 0x1n === 0x1 returns false. See here: https://github.com/tc39/proposal-bigint#no-implicit-conversions-or-mixed-operands https://github.com/tc39/proposal-bigint#no-implicit-conversi... Shifting is specified here: https://tc39.github.io/proposal-bigint/#sec-numeric-types-bigint-leftShift https://tc39.github.io/proposal-bigint/#sec-numeric-types-bi...

venning 8y ago

There's a related article linked in OP that answers your questions: https://developers.google.com/web/updates/2018/05/bigint https://developers.google.com/web/updates/2018/05/bigint When mixing Number and BigInt, abstract equality (==) works fine, but strict equality (===) is always false, since they are two different primitive types. Most bitwise operators are allowed, so long as all operands are the same type (Number or BigInt). The only exception is zero-fill right shift (>>>) since that doesn't make any sense with respect to BigInts. From my console: (node 10 with --harmony-bigint) > 1n == 1 true > 1n === 1 false > 12345n >> 1 TypeError: Cannot mix BigInt and other types, use explicit conversions > 12345n >> 1n 6172n > 12345n >>> 1n TypeError: BigInts have no unsigned right shift, use >> instead

epistemex 8y ago
> since they are two different primitive types. Yes, I'm aware of this, but I was more asking in the realm of internal performance/optimization (as I sort of point out - and not necessarily because of the comparer). F.ex. they are in all practicality the same integer and in other cases, IIRC (please correct me if I'm wrong), V8 optimizes the native Number that could easily be stored internally as IEEE-754, to actual internal integers when using bit-ops on them (to indicate to the optimizer you handle integers) and so forth. In this case I was curious if this would be optimized internally so these comparisons could be moved directly to CPU registers as integers (assuming being on a 64-bit arc) and compared there, for example. But, future will tell - I'm equally aware of that optimizations is not first priority at this stage (it's just me excited to see this manifest). It's in any case a welcome and useful feature optimized or not. apaprocki linked (thanks!) to a method that can do unsigned right-shift via a method (1.1.11 BigInt::unsignedRightShift).

dragonwriter 8y ago

> I think this for the most part is useful for WASM Also, for compile-to-JS versions of languages where the hosted language has BigInts, which now [0] can be more fully equivalent to the non-JS implementations of the same language. I think it's a while before GC-dependent languages will be WASM hosted, but there are a lot that compile to JS. [0] where “now” is “sometime in the future where this has broad support among browsers”