BigInt Math
Seeking Stage 1
Why add BigInts to Math ƒs
Several built-in Math functions would make sense with BigInts yet still do not support them.
arrOfBigInts.map(abs)
max(...arrOfBigInts)
sign(bigInt0) * bigInt1
BigInts are important for a myriad of mathematical, financial, and scientific applications (such as in the Web Performance API).
Description
Included ✔️
abs sign ceil floor round trunc
sqrt cbrt pow exp expm1�log log1p log10 log2
sinh cosh acosh asinh
max* min*�hypot*
Excluded ❌
sin cos asin acos atan atan2�tanh atanh
clz32? imul?
fround
random
Design choices
We are excluding tan because of its asymptotes between integers.
Other irrational-returning functions are okay (sqrt, cbrt, exp, log, sinh, …). Irrationals are implementation-approximated to BigInts. (Formal guarantees in spec?)
(We have not yet decided whether to extend clz32 and imul, but this should not need to block Stage 1.)
We continue to avoid any implicit/unexpected type conversion between regular Numbers and BigInts.�For example, cos(5n) must not return a regular Number.
We are excluding sin, cos, asin, acos, tan, atan, atan2, atanh because of small integer domains or ranges (e.g., it is useless to accept or return only three values -1n, 0n, and +1n).
Variadic functions
��
Separate BigInt functions for min, max, and hypot are necessary to prevent type mixing with zero arguments.
��
Otherwise, max(...arrOfBigInts) might usually return a BigInt.�But it would unexpectedly return a Number value (i.e., +Infinity) whenever arrOfBigInts�is ever empty!
Variadic functions
hypot() returns 0.0.�min() returns -Infinity.�max() returns +Infinity.
Otherwise, max(...arrOfBigInts) might usually return a BigInt.�But it would unexpectedly return a Number value (i.e., +Infinity) whenever arrOfBigInts�is ever empty!
bigHypot() returns 0n.�bigMin() throws RangeError.�bigMax() throws RangeError.
Separate BigInt functions for min, max, and hypot are necessary to prevent type mixing with zero arguments.
Alternative design:�BigInt.hypot, BigInt.min, and BigInt.max and also�Number.hypot, Number.min, and Number.max.�Might also be better with Decimals.
Cross-cutting concerns
Potential interference with asm.js (e.g., with imul)?�Other potential problems with engine optimizability?�Efficiency of math operations on arbitrary-sized integers today?�Future support for Decimals?
Whether to formally constrain engine-“approximated” numbers (e.g., “for all BigInts n0 and n1, if n0 < n1 then sqrt(n0) < sqrt(n1)” or “for all BigInts n, if n is 2 ** m then log(m) must be n”)?
Would any mathematician/scientist/engineer developers have unforeseen special requirements for these operations?