> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update "since" version
-
Changes:
- all: https://git.openjdk.org/jdk/pul
On Sat, 10 May 2025 16:41:17 GMT, fabioromano1 wrote:
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
This pull request has now been integrated.
Changeset: c9e6c4d0
Author:Fabio Romano
Committer
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Restored trustedStripLeadingZ
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Restore calls to trustedStripLeadingZ
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed needless condition
Co-authored-by
On Tue, 27 May 2025 17:25:25 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Because the method assumes that `a` represents a two's
>> complement negative integer, so there is at least a sign bit?
>
> There's only one usage of `makePositive(int[])`, and only when `a[0] < 0`.
> And then there's t
On Tue, 27 May 2025 15:26:42 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct typo in comment
>
> src/java.base/share/classes/java/math/BigInte
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct typo in comment
-
Chang
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use one less counter in makeP
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct typo in comment
-
Chang
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplify two's complement in
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
A minor change
-
Changes:
-
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use bitwise or instead of + i
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Some code simplifications for
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplify two's complement in
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Avoid redundance of stripLead
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Small code simplifications
---
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Revert "Removed redundant code for cho
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed redundant code for choosing division&
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Small code simplifications
---
On Mon, 19 May 2025 17:34:16 GMT, Raffaello Giulietti
wrote:
>> Yes, but perhaps in the current version it's more clear what is the returned
>> value according to the condition.
>
> One could see the suggested variant as "return magBitLength(), except for a
> corrective term in case blah blah.
On Mon, 19 May 2025 15:50:10 GMT, Raffaello Giulietti
wrote:
>> What is the usefulness of doing `int[] mag = this.mag;` at line 3856, since
>> `bitLength()` does not access to `static` fields and `BigInteger` is not
>> threadsafe, and therefore no race conditions occur?
>
> I think the suggest
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed numberOfTrailingZeros() as a dupli
On Mon, 19 May 2025 15:03:51 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 5034:
>>
>>> 5032: */
>>> 5033: private byte[] magSerializedForm() {
>>> 5034: byte[] result = new byte[(magBitLength() + 7) >>> 3];
>>
>> I think there's
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/files
-
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Do first refinement loop only if shift == 0
-
Changes:
- all: https://git.openjdk.org/
On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert "Use type long for bitLength instead of int&qu
On Thu, 15 May 2025 22:43:54 GMT, Shaojin Wen wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make magBitLength() an instance method
>
> src/java.base/share/classes/java/math/BigInte
On Thu, 15 May 2025 15:37:39 GMT, fabioromano1 wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> fabioromano1 has updated the pull request incrementally with one additional
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes:
-
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct bug in shiftRight
---
On Thu, 15 May 2025 22:03:40 GMT, Raffaello Giulietti
wrote:
> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
> please crosscheck?
@rgiulietti It seems there is a slowdown in the creation of large
pseudoprimes, maybe due to `BitSieve` methods.
-
PR C
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
make magBitLength() an inst
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Make javaIncrement(int[]) static
---
On Thu, 15 May 2025 13:51:29 GMT, Raffaello Giulietti
wrote:
> It cannot be made an instance method, though. There's one usage which needs a
> static invocation.
@rgiulietti If you are referring to [this
invocation](https://github.com/fabioroman
On Thu, 15 May 2025 13:35:29 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update names
>
> Since you are at it, I'd suggest changing `javaIncre
On Wed, 14 May 2025 18:48:50 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert "Use type long for bitLength instead of int&qu
On Wed, 14 May 2025 18:27:28 GMT, Raffaello Giulietti
wrote:
> I doubt that the AKS primality test is of any practical relevance, although
> it's a _great_ theoretical achievement.
Yes, indeed it was just an example, but the exact power detection can be used
also as a test apart from the enti
On Wed, 14 May 2025 17:59:59 GMT, Raffaello Giulietti
wrote:
> I guess this work will be the basis for a future work on `BigDecimal` _n_-th
> root?
@rgiulietti Yes, it is. Some use cases could be primality testing, like AKS,
where part of the algorithm detect composite numbers by checking whe
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Revert "Use type long for bitLength instead of int"
This r
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use type long for bitLength instead of int
-
Changes:
- all: https://git.openjdk.org/
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update names
-
Changes:
-
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Same optimization of prev
> Some changes in `Biginteger`s' bit operations that increase the code
> readability and slightly optimize the execution time.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes:
-
On Sun, 11 May 2025 16:08:25 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2828:
>>
>>> 2826: * assuming there are no leading zero ints.
>>> 2827: */
>>> 2828: private static int bitLength(int[] val,
On Sun, 11 May 2025 16:12:38 GMT, fabioromano1 wrote:
>>> This should really be refactored to an instance method `bitLengthUnsigned`
>>> or `magBitCount`
>>
>> I would prefer `magBitLength` as a name, since `bitCount` is usually
>> referred to one's bi
On Sun, 11 May 2025 16:00:55 GMT, Chen Liang wrote:
> This should really be refactored to an instance method `bitLengthUnsigned` or
> `magBitCount`
I would prefer `magBitLength` as a name, since `bitCount` is usually referred
to one's bit count. But before do this, I'd hear the opinion of @rgi
On Mon, 12 May 2025 01:52:51 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2642:
>>
>>> 2640: }
>>> 2641: // (this.abs().bitLength() - 1L) * exponent + 1L >
>>> Integer.MAX_VALUE
>>> 2642: if (scaleFactor + bitsToShift - exponent >=
On Mon, 12 May 2025 13:13:36 GMT, Raffaello Giulietti
wrote:
>> Some changes in `Biginteger`s' bit operations that increase the code
>> readability and slightly optimize the execution time.
>
> @fabioromano1 While reviewers can of course file JBS issues on behalf
Some changes in `Biginteger`s' bit operations that increase the code
readability and slightly optimize the execution time.
-
Commit messages:
- More clear comment
- An optimization
- Code simplification
- Code simplification
- Avoiding redundant code
- Code simplification
- Co
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/files
-
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into
nth-root-bran
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Avoid needless box/unbox conversion
-
Changes:
- all: https://git.openjdk.org/jdk/p
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into
nth-root-bran
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed useless code
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/fi
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
correct typos
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24898/files
-
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Factor out newton's recurrence in a separate method
-
Changes:
- al
On Mon, 12 May 2025 17:37:54 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk
>
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'nth-root-branch' of https://github.com/fabioromano1/jdk into
nth-root-bran
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 44 commits:
- Merge branch 'openjdk:master' into nth-root-branch
- Upda
On Wed, 16 Apr 2025 13:45:55 GMT, fabioromano1 wrote:
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponen
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti
wrote:
> Otherwise looks good. As soon as you feel comfortable with your changes, let
> me know so that I can approve.
@rgiulietti For me, now the code is ready.
-
PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
Changes:
- all: https://git.o
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Suggested changes
>
> Please update the 2nd copyright year in `BigInteger`.
&
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Suggested changes
-
Changes:
- all: https://git.o
On Wed, 7 May 2025 18:10:36 GMT, Raffaello Giulietti
wrote:
> I mean, if B strictly implies A, then B is more restrictive (stronger). Since
> B is equivalent to your original formulation, to me it means that it was more
> restrictive.
Exactly.
-
PR Review Comment: https://git.op
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Suggested changes
-
Changes:
- all: https://git.o
On Wed, 7 May 2025 17:58:11 GMT, Raffaello Giulietti
wrote:
> OK.
>
> But then your original expression
>
> ```
> (((bitLength() - 1L) * exponent) >>> 5) + 1L > MAX_MAG_LENGTH
> ```
>
> was a bit too restrictive as well, right?
On the contrary, it was too loose, as it admitted a bit length
On Wed, 7 May 2025 17:43:30 GMT, Raffaello Giulietti
wrote:
>>> Ah right, but you probably want
>>
>> No, the sufficient condition to get the overflow is `(bitLength() - 1L) *
>> exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote
>> above.
>
> At some point you propos
On Wed, 7 May 2025 17:32:06 GMT, Raffaello Giulietti
wrote:
> Ah right, but you probably want
No, the sufficient condition to get the overflow is `(bitLength() - 1L) *
exponent + 1L > Integer.MAX_VALUE`, which is equivalent to that one I wrote
above.
-
PR Review Comment: https:/
On Wed, 7 May 2025 15:38:41 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed needless brackets
>
> src/java.base/share/classes/java/math/BigInte
On Wed, 7 May 2025 15:46:16 GMT, Raffaello Giulietti
wrote:
> Did you make sure that the existing tests also cover the `unsignedLongPow()`
> sufficiently well?
@rgiulietti There are already the tests for `BigInteger`'s
[pow](https://github.com/fabioromano1/jdk/blob/BigInteger-nt
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
Changes:
- all: https://git.o
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed needless brackets
-
Changes:
- all: https:/
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Suggested changes
-
Changes:
- all: https://git.o
ything.
>>
>> It serves to skip the checks in the loop if in the common cases the length
>> of the results are way more little with respect to `Long.SIZE` and to fail
>> fast if in the common cases the length of the results are way bigger than
>> `Long.SIZE`.
>&g
On Fri, 2 May 2025 16:57:43 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/Math.java line 3500:
>>
>>> 3498: return (n & 0b1) == 0 ? 1 : -1;
>>> 3499: }
>>> 3500:
>>
>> Suggestion:
>>
>>
>> if (x == 2) {
>> if (n >= Integer.SIZE - 1)
On Fri, 2 May 2025 16:53:39 GMT, Raffaello Giulietti
wrote:
> As for the `bitLength` check, the product might overflow. Further,
> `bitLength` might not be that cheap.
The current implementations of `bitLength()` calls `numberOfLeadingZeros`,
which are:
public static int numberOfLeadingZeros
the checks in the loop if in the common cases the length of
the results are way more little with respect to `Long.SIZE` and to fail fast if
in the common cases the length of the results are way more bigger than
`Long.SIZE`.
> @fabioromano1 Well, there are two checks. In one the product can o
On Fri, 2 May 2025 16:45:28 GMT, Raffaello Giulietti
wrote:
> I don't think there's a quick, _precise_ pre-check that would ensure that the
> loop can just use simple, unchecked `*` multiplications.
>
> Consider `unsignedPowExact(3L, 40)`, which does not overflow, versus
> `unsignedPowExact(3
tion:
>>
>> if (x == 0 || x == 1 || n == 1) {
>
> @fabioromano1 Unless there's evidence that these cases are _very very_
> common, there's no point in adding fast paths.
> See this comment in `unsignedPowExact(long,int)`
>
>
> /*
> * T
On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti
wrote:
>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer
>> values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> a
On Fri, 2 May 2025 15:12:01 GMT, Raffaello Giulietti
wrote:
>> Add `powExact()` and `unsignedPowExact()` methods that operate on integer
>> values arguments.
>> Further, add `unsignedMultiplyExact` methods as well.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> a
On Wed, 30 Apr 2025 15:59:05 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the &quo
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplify long power computing
-
Changes:
- all: ht
On Wed, 30 Apr 2025 12:20:39 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplified the formula for detecting overflows
>
> src/java.base/share/classes/
On Wed, 30 Apr 2025 12:20:39 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplified the formula for detecting overflows
>
> src/java.base/share/classes/
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplified the formula for detecting overflows
-
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use a more accurate formula to detect certain overflows
--
On Tue, 29 Apr 2025 15:42:56 GMT, Raffaello Giulietti
wrote:
> I don't observe any significant difference on my environment
@rgiulietti Although there could be no significant differences, the method to
compute powers of `long`s could be useful, since it is used both by
`BigInteger.pow()` and
On Tue, 29 Apr 2025 15:18:35 GMT, Raffaello Giulietti
wrote:
> What went wrong before?
@rgiulietti For some reason, compiling the test with a custom JVM will produce
that exception at runtime. It must be compiled with the default JVM, then
change the JVM manually and run it with the chosen on
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Adjust the type of operand
- Use a more loose formula to do rang
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Take into account special case exponent == 1
-
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Don't exclude a priori valid results
Don't exclude
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed needless condition
-
Changes:
- all: https:/
On Mon, 28 Apr 2025 17:06:55 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added tests for memory consumption
>
> Can you show the benchmark results before
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update test parameters
-
Changes:
- all: https:/
On Mon, 28 Apr 2025 17:06:55 GMT, Raffaello Giulietti
wrote:
> Can you show the benchmark results before/after, perhaps specifying the
> characteristics of your machine (CPU make/model, RAM, OS)?
CPU: Intel Core i3 7100U @ 2.40GHz
RAM: 8,00GB Dual-Channel DDR4 @ 1063MHz
OS: Kali Linux 2025.1a-
se, so the base is not squared like in
> the current implementation, and this permits to save about half of the memory.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Decrease exponents in tests
-
Changes:
- all: ht
>>> * Another PR for the proposed _n_-th root.
>>
>> I'm not very sure if it is technically possible, because both `pow()` and
>> `nthRoot()` requires the computation of a power of a long, so that code has
>> to be shared by both methods, and so a supposed PR
1 - 100 of 486 matches
Mail list logo
