Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BigInteger(byte[], int, int) constructor is missing #9901

Open
niloc132 opened this issue Jan 17, 2024 · 4 comments · May be fixed by #9953
Open

BigInteger(byte[], int, int) constructor is missing #9901

niloc132 opened this issue Jan 17, 2024 · 4 comments · May be fixed by #9953

Comments

@niloc132
Copy link
Contributor

In Java 9, a new constructor was added to BigInteger:

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigInteger.html#%3Cinit%3E(byte%5B%5D,int,int)

@tbroyer
Copy link
Member

tbroyer commented Jan 17, 2024

Speaking of BigInteger, all browsers except IE support BigInt (just sayin')

@niloc132
Copy link
Contributor Author

If you're interested, it's all yours, file a ticket on what we can do to make that make more sense?

Jsinterop-base already has a JsBigInt type - just an interface, no members, but elemental2-core fills in the rest. If you're just looking at using it in specific "treat it like any other Object" cases that might be enough, but making GWT emit bigint literals might be tricky - gwt's js ast is basically es3, so adding a new JsLiteralValue might not be entirely seamless (esp when following the rules about not mixing numbers and bigints). Using bigint for long values that don't fit in an int32 could make sense though, at least at a glance, but mixing operation might be gross (in Java, long * int is a long, in js you can't mix of course).

With regards to performance, is bigint comprehensively better than regular numeric math? Gwt's BigInteger is already just plain integers (so no dealing with long math). At a glance, the emulation might end up producing smaller output, and some operations like remainder()...

With no numbers to back me up, I'd guess there would be bigger wins replacing the int[] digits with a Int32Array than bigint for bit/byte-wise operations (de/serializing values, checking if bits are set), but likely better performance for BigInteger-BigInteger operators for bigint, plus smaller generated code.

@lgemeinhardt
Copy link

Why not simple use the code of BigInteger(byte[]) and extend this to take length and offset (missing constructor) and copy the array in the beginning (or change the code to handle length and offset – whatever is easier) and let the (now missing) BigInteger(byte[]) constructor use the newly created one (with zero as offset and array length)?

@niloc132
Copy link
Contributor Author

@lgemeinhardt exactly, plus add tests, that's what this ticket is for. It should be just as easy as you suggested. I'd avoid the copy if we can help it, and have BigInteger(byte[]) call the new one with 0, arr.length - it shouldn't make a difference in the compiled output if you don't use the new ctor, since the old one will get inlined and putBytesNegativeToIntegers/putBytesPositiveToIntegers already read the length of the array anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants