mmermann's algorithm, it turns out that it
is faster than my algorithm even for small numbers.
-
Commit messages:
- Merge branch 'openjdk:master' into patchSqrt
- An optimization
- Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into
pa
On Thu, 13 Jun 2024 18:31:33 GMT, fabioromano1 wrote:
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_r
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Special cases and base ca
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplification of code
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed unused import
-
C
On Sun, 23 Jun 2024 05:57:56 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 293:
>>
>>> 291: */
>>> 292: private int compareShifted(MutableBigInteger b, int ints) {
>>> 293: this.normalize();
>>
>> See
>> [JDK-8334483](http://b
On Sun, 23 Jun 2024 06:19:17 GMT, Daniel Jeliński wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unused import
>
> Thanks for contributing to the OpenJDK!
> What tests did
On Sun, 23 Jun 2024 09:48:59 GMT, Daniel Jeliński wrote:
> Most likely. If you check the code you'll notice that most methods that
> change the `MutableBigInteger` value (like `subtract`) call `normalize` after
> performing the operation, so the values should be normalized most of the time.
@d
On Sun, 23 Jun 2024 10:23:15 GMT, Daniel Jeliński wrote:
>>> Most likely. If you check the code you'll notice that most methods that
>>> change the `MutableBigInteger` value (like `subtract`) call `normalize`
>>> after performing the operation, so the values should be normalized most of
>>> th
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Normalize blocks
-
C
On Sun, 23 Jun 2024 10:52:13 GMT, Daniel Jeliński wrote:
>> @djelinski I'm referring to the tests of square root for BigIntegers.
>
> ah, so before your changes, the arguments were always normalized, and now
> they are not?
@djelinski Now I found the issue and resolved it normalizing the Zimmer
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Merge branch 'patchSqrt' of
On Sun, 23 Jun 2024 06:19:17 GMT, Daniel Jeliński wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unused import
>
> Thanks for contributing to the OpenJDK!
> What tests did
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code optimization
-
C
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code optimization
-
C
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Optimized multiplication
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Optimized to compute the remainder
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed unnecessary variable
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplified computing square root of Big
On Mon, 24 Jun 2024 17:09:30 GMT, Daniel Jeliński wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code optimization
>
> Thanks. That's a very nice performance improvement, on
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct BigDecimal.sqrt()
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Reverted changes in BigDecimal
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Ensure normalized value in MutableBigI
On Thu, 4 Jul 2024 12:51:47 GMT, Raffaello Giulietti
wrote:
>> @djelinski I also improved the `BigDecimal.sqrt()` algorithm exploiting
>> `BigInteger.sqrtAndRemainder()`.
>
> @fabioromano1 I'll review your contribution starting sometimes next week.
> Please stab
On Tue, 9 Jul 2024 17:17:48 GMT, Raffaello Giulietti
wrote:
> Let's agree that the reference for this PR is the
> [algorithm](https://inria.hal.science/inria-00072113/document) described by
> Bertot, Magaud and Zimmermann.
>
> From a first reading, the algorithm implemented here appears diffe
On Tue, 9 Jul 2024 18:04:43 GMT, Raffaello Giulietti
wrote:
> These helpful considerations, and others that are not obvious when comparing
> with the paper, should really be part of comments in the code. As mentioned,
> this helps with reviewing and for maintenance.
@rgiulietti I will add the
On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti
wrote:
> Everything not obvious that departs from the paper by Bertot, Magaud and
> Zimmermann should be commented. Unfortunately, I can't say precisely what and
> to which extent until I see a first version.
@rgiulietti Well. Regarding the
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes bro
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Added comment
On Tue, 9 Jul 2024 18:14:03 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Ensure normalized value in MutableBigInteger initialization with ints
>
> Every
On Wed, 10 Jul 2024 12:13:32 GMT, Raffaello Giulietti
wrote:
> Yes, thanks, I saw it.
If some other clarifications are needed, please let me know.
-
PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2220362708
This implementation of MutableBigInteger.leftShift(int) optimizes the current
version, avoiding unnecessary copy of the MutableBigInteger's value content and
performing the primitive shifting only in the original portion of the value
array rather than in the value yet extended with trailing zero
On Fri, 12 Jul 2024 13:04:42 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:06:35 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:06:46 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:07:02 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:49:55 GMT, Raffaello Giulietti
wrote:
>> The proof has been made simply by exaustive experiment: for every long value
>> `s` in [0, 2^32) such that `x == s * s`, it is true that `s == (long)
>> Math.sqrt(x >= 0 ? x : x + 0x1p64)`. This can be verified directly by a Java
On Fri, 12 Jul 2024 13:07:39 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:07:51 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:08:29 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 14:16:38 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 2040:
>>
>>> 2038: sqrt.add(q);
>>> 2039:
>>> 2040: MutableBigInteger chunk = u;
>>
>> I don't g
On Fri, 12 Jul 2024 13:08:37 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 13:08:59 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment on normalization in MutableBigInteger.sqrtRemZimmermann()
>
> sr
On Fri, 12 Jul 2024 14:42:33 GMT, Raffaello Giulietti
wrote:
>> Like `u_a0`? It is the most "mathematical" name that comes to my mind.
>
> In the paper `u` is called R'', so I'd rename it as `rpp` (for R prime
> prime). Generally, the more the names in the code match the ones in the
> paper, t
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Removed trailing whitespace
-
On Fri, 12 Jul 2024 14:39:51 GMT, Raffaello Giulietti
wrote:
>> The full explanation for the unnormalization is in the second paper, "A
>> proof of GMP square root", par. 3.2 at page 11.
>
> Well, I have to compare that section, which is clear to me, with the code
> again.
@rgiulietti I notic
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Simplified the computation of th
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct typo in comment
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Optimized shift-and-add operations
-
On Mon, 15 Jul 2024 19:58:23 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_p
On Wed, 17 Jul 2024 13:15:17 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Optimized shift-and-add operations
>
> src/java.base/share/classes/java/math/Mu
On Wed, 17 Jul 2024 13:48:59 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1978:
>>
>>> 1976: * is either correct, or rounded up by one if the value
>>> is too high
>>> 1977: * a
On Wed, 17 Jul 2024 13:57:20 GMT, Raffaello Giulietti
wrote:
>> I hope these errors are not due to an implementation change in the virtual
>> machine instructions...
>
> There are no counterexamples for perfect squares if you write `long s =
> (long) Math.rint(Math.sqrt(x >= 0 ? x : x + 0x1p64
On Wed, 17 Jul 2024 14:17:48 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Is it normal that the same code did not find counterexamples
>> until recently, and now it finds them?
>
> I tried on older release, they all agree.
@rgiulietti This is so strange... anyway, I tried also `long x = n *
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct square root computation
On Wed, 17 Jul 2024 15:11:36 GMT, Raffaello Giulietti
wrote:
>> Also, this avoids a test
>>
>> if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over-
>> and underflows
>> s--;
>> }
>
> Sorry, disregard the above as it doesn't work for x = 0.
>
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
More accurate comment
-
C
On Wed, 17 Jul 2024 15:11:36 GMT, Raffaello Giulietti
wrote:
>> Also, this avoids a test
>>
>> if (Long.compareUnsigned(x, s * s - 1) <= 0) { // benign over-
>> and underflows
>> s--;
>> }
>
> Sorry, disregard the above as it doesn't work for x = 0.
@r
On Wed, 17 Jul 2024 16:16:12 GMT, Raffaello Giulietti
wrote:
>> Can try with the old release and the incorrect code again?
>> If the results disagree with newer releases then I'd be interested in which
>> release you were using, as to analyze the generated code and possibly file a
>> bug repor
On Wed, 17 Jul 2024 16:16:12 GMT, Raffaello Giulietti
wrote:
>> Can try with the old release and the incorrect code again?
>> If the results disagree with newer releases then I'd be interested in which
>> release you were using, as to analyze the generated code and possibly file a
>> bug repor
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Optimized the square root's
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Uniforming the computation of long valu
On Thu, 18 Jul 2024 13:39:01 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More accurate comment
>
> src/java.base/share/classes/java/math/MutableBigInte
On Thu, 18 Jul 2024 13:40:38 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More accurate comment
>
> src/java.base/share/classes/java/math/MutableBigInte
On Thu, 18 Jul 2024 14:50:00 GMT, Raffaello Giulietti
wrote:
>> I mean only restricted to unsigned `long` perfect squares, something like
>> the following, but written as a proper test
>>
>>
>> long i = 0;
>> for (; i < 1L << 32; ++i) {
>> long x = i * i;
>>
On Thu, 18 Jul 2024 15:01:22 GMT, fabioromano1 wrote:
>> It takes about 5 s on my laptop.
>
>> I mean only restricted to unsigned `long` perfect squares, something like
>> the following, but written as a proper test
>>
>> ```
>> long i =
On Thu, 18 Jul 2024 15:27:53 GMT, Raffaello Giulietti
wrote:
> Experimentally, the following seems a bit faster. In some cases, it avoids a
> full multiplication, some updates, and has one less test. I hope it is
> correct as well ;-)
It's a nice code, but I'm afraid that if `s == LONG_MASK`
On Thu, 18 Jul 2024 16:06:31 GMT, Raffaello Giulietti
wrote:
>>> Experimentally, the following seems a bit faster. In some cases, it avoids
>>> a full multiplication, some updates, and has one less test. I hope it is
>>> correct as well ;-)
>>
>> It's a nice code, but I'm afraid that if `s ==
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Second revision changes
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Conditions' order reverse
On Tue, 23 Jul 2024 14:42:36 GMT, Raffaello Giulietti
wrote:
> AFAIU, in the Bertot, Magaud, Zimmermann paper there is just one
> "denormalization" step in the wrapper, before returning the final result to
> the client.
>
> Here, there seems to be a denormalization before returning from each
On Tue, 23 Jul 2024 15:16:27 GMT, Raffaello Giulietti
wrote:
> AFAIU, the wrapper performs the normalization, invokes the core algorithm,
> and does the denormalization just before returning the final result. There's
> no mention that normalization/denormalization need to be performed at each
On Tue, 23 Jul 2024 15:19:30 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Conditions' order reversed in MBI.ulongSqrt()
>
> To clarify, the PR'
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Made normalization consistent with
On Wed, 24 Jul 2024 10:07:48 GMT, Raffaello Giulietti
wrote:
> As I see it, there are some advantages in making the PR code as similar as
> possible to the code in the paper:
>
> * It might result in simpler code (and maybe even faster code).
>
> * It would make the Java code easier t
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
An optimization
-
Changes
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Revert "An optimization"
On Wed, 24 Jul 2024 11:46:03 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Made normalization consistent with that of the C code in the paper
>
> The aim
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use primitive right shift for speed
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Optimized division by 2*sqrt
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Slightly slower but safer code
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Code simplification
-
C
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
More accurate condition for MBI.s
On Sat, 27 Jul 2024 11:47:23 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More accurate condition for MBI.safeRightShift()
>
> test/mic
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Avoid overflow in benchmark
--
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Range checks are already done by the B
On Sat, 27 Jul 2024 13:46:14 GMT, Raffaello Giulietti
wrote:
>> The benchmark `BigIntegers.java`, on which I based this, has the same
>> problem.
>
> It wasn't the overflow by itself that worried me, but that a later invocation
> of `sqrt*()` could throw.
>
> Again, the "huge" numbers are les
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Correct test method name
- Up
On Sat, 27 Jul 2024 14:55:04 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Correct test method name
>> - Updated sqrt speed test benchmark
>
&
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Removed MBI.sqrt() old method
-
hm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
If the input is a square, then s
On Mon, 29 Jul 2024 17:00:09 GMT, Raffaello Giulietti
wrote:
> Sorry, not `<<` but `*`
or `(x.intLen & 1) << 5`
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1695649080
On Mon, 29 Jul 2024 16:50:10 GMT, Raffaello Giulietti
wrote:
> The following variant should be preferred, as it has a readable figure on p.
> 21, whereas the same figure in the variant linked in the PR seems broken for
> some reason. https://inria.hal.science/inria-00072113/document
What is t
1 - 100 of 568 matches
Mail list logo
