Math.pow should accept Bigints, modulo and pow=-1 about proposal-math-extensions HOT 12 CLOSED

For what it’s worth, there is now a Stage-1 BigInt Math proposal that would extend several Math functions to accept BigInts in addition to Numbers.

Although BigInt Math proposal proposal itself does not address modPow or gcd, the vision is that it would set a precedent for new polymorphic Math methods, like modPow or gcd, that would accept both Numbers and BigInts.

from proposal-math-extensions.

1. The most expensive & the most secure cryptographic system in the world uses it. The second most secure cryptographic system also uses it.
2. Every browser supports TLS (https), which most likely uses elliptic curve operations (ECDH* key share, ECC encryption/signatures).
3. invert() is usually the most expensive operation in elliptic curves (points 1 and 2). Invert depends on gcd. Even if we discard point 1, all future work related to cryptography is going to be much slower than it could have possibly been.
4. There are no alternatives. Pure-js code would always be slower. Wasm code does not really have internal context of numbers.
5. There is no backwards-incompatibility. It's just a new third argument for bigint-only math.pow.

from proposal-math-extensions.

None of these seem like use cases in javascript itself tho (TLS is not typically implemented in JS). What do you need this for in javascript?

from proposal-math-extensions.

See my point number 1. The most secure cryptographic system uses it. I'm talking about BTC. I'm thinking that it's more important than some exotic math functions for game developers, apps (etc) of which are 1/100 of BTC capitalization.

Do you know how many js apps use cryptocurrencies? Lots, and there will be more. https://github.com/ChainSafe/lodestar recently launched a full node implementation in JS. Unfortunately, they opted for wasm, since there are quite a few slow things in pure JS.

from proposal-math-extensions.

Math.pow accepting BigInts isn't particularly useful, since the exponentiation operator already does.
If Math.pow were to accept BigInts, the same could be said for the rest of the Math namespace.
Also, exponentiation by negatives is already allowed, what were you referring to specifically?

from proposal-math-extensions.

It’s quite useful, and yes, the entire Math namespace should accept BigInts.

from proposal-math-extensions.

i'm talking about modular exponentiation

https://docs.python.org/3/library/functions.html#pow

>>> pow(38, -1, mod=97)
23
>>> 23 * 38 % 97 == 1
True

from proposal-math-extensions.

Since you can do that now with %, why would you need the ability smooshed into pow? The “more efficiently” claim in python’s docs would require lots of benchmarks in JS as well as compelling use cases where that’s not fast enough already.

from proposal-math-extensions.

Euclidian GCD is very hard to make fast. If it was implemented in a low-level language, or in an environment that can reason about number size (e.g. 256 bits max), it can be much more efficient. Personally i'm re-implementing this method over and over in cryptographic libraries and it's just unnecessary & can be one of the slowest parts.

from proposal-math-extensions.

Right, but "compelling use cases" - why does it need to be fast?

from proposal-math-extensions.

Since you can do that now with %, why would you need the ability smooshed into pow? The “more efficiently” claim in python’s docs would require lots of benchmarks in JS as well as compelling use cases where that’s not fast enough already.

I know this is an old comment, and the following text will probably be old soon, but I must say it just for the record:

If anyone tries to do 3n ** (1n << 32n) % 5n the engine is very likely to throw an error because there's not enough memory. However modPow(3n, 1n << 32n, 5n) will never throw, no matter how big the exponent is. This happens because some engines take the "as if" principle a little way too literally, so they throw errors and try to do hard calculations instead of internally optimizing time and memory usage. That's one of the reasons why modPow is useful.

However, using bogus exponents is probably not a good "real-life" example, so this is not enough justification to add modPow

from proposal-math-extensions.

the entire Math namespace should accept BigInts

At first, I thought that was too extreme, but after a second thought (and a third) it actually makes sense and seems like a good idea. What if transcendental fns didn't return full precision BigInts? but instead returned a number approximation? That would solve the problem of many methods being "infeasible" for BigInts, and would make the Math namespace more consistent and easier to work with.

Of course, my proposed solution of returning approximations is very likely a bad idea, but I have a feeling that there may be a better solution to make all Math methods BigInt-compatible

from proposal-math-extensions.