The enanchment is useful for applications that make heavy use of BitSet objects
as sets of integers, and therefore they need to make a lot of calls to
cardinality() method, which actually require linear time in the number of words
in use by the bit set.
This optimization reduces the cost of call
On Wed, 18 Jan 2023 06:36:56 GMT, Julian Waters wrote:
> @fabioromano1 Would you like me to create an entry for you for the Pull
> Request is linked to the appropriate mailing list? When I do that you will
> have to change the name of this Pull Request though
Yes, thank you
On Wed, 11 Jan 2023 12:57:47 GMT, Jim Laskey wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>> words
On Wed, 11 Jan 2023 15:33:47 GMT, Claes Redestad wrote:
>> I agree with the fact that is less intrusive, but certainly not potentially
>> quicker, since the complete recalculation of cardinality requires linear
>> time in the value of wordsInUse
>
> A perhaps slightly less racy way would be to
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Added author to includes(BitSet)
-
Changes:
-
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
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 brought in
by the merge/reb
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Added author and reverse the cicle order in includes(BitSet)
On Wed, 18 Jan 2023 11:37:05 GMT, Alan Bateman wrote:
> It looks all the javadoc and several areas of the code have been
> re-formatted. Please revert all of this as it's impossible to see what has
> been changed.
Done.
-
PR: https://git.openjdk.org/jdk/pull/11837
includes another bit set (i.e., the set of true bits of the parameter is a
> subset of the true bits of the instance).
fabioromano1 has updated the pull request incrementally with five additional
commits since the last revision:
- Revert "Formatted"
This reverts comm
On Wed, 18 Jan 2023 14:15:17 GMT, Uwe Schindler wrote:
> As one dealing with bitsets very often: In my opinion, adding this to bitset
> adds too much overhead on the hot methods like set/clear methods. Especially
> loops that populate a BitSet with values, I am not sure if the whole loop can
>
On Wed, 18 Jan 2023 21:51:02 GMT, Martin Buchholz wrote:
> Like other reviewers, changing the performance tradeoffs in BitSet make me
> uncomfortable.
>
> 30 years of code has adapted to the current performance tradeoffs. Those
> users who really need O(1) cardinality() can fairly easily imple
On Thu, 19 Jan 2023 13:24:03 GMT, Jim Laskey wrote:
> Libraries cannot be all things to all users. A library provides a service
> that would be difficult for a majority of users to implement on their own.
> Sometimes a library needs specialization for certain use cases. That is why
> we use su
On Thu, 19 Jan 2023 14:03:38 GMT, fabioromano1 wrote:
> Libraries cannot be all things to all users. A library provides a service
> that would be difficult for a majority of users to implement on their own.
> Sometimes a library needs specialization for certain use cases. That is why
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear tim
On Thu, 19 Jan 2023 23:14:12 GMT, John R Rose wrote:
> I'll pile on: This optimization doesn't buy much in today's world, where most
> machines execute `bitCount` in one cycle. It saves a trivial loop. Over very
> large bitsets that saves something, but most bitsets are likely to be medium
> t
ion reduces the cost of calling cardinality() to constant time,
> as it simply returns the value of the field, and it also try to make as
> little effort as possible to update the field, when needed.
fabioromano1 has updated the pull request incrementally with one additional
commit si
ion reduces the cost of calling cardinality() to constant time,
> as it simply returns the value of the field, and it also try to make as
> little effort as possible to update the field, when needed.
fabioromano1 has updated the pull request incrementally with one additional
commit si
On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 wrote:
> The enanchment is useful for applications that make heavy use of BitSet
> objects as sets of integers, and therefore they need to make a lot of calls
> to cardinality() method, which actually require linear time in the number of
branch 'openjdk:master' into patch-4
- Merge branch 'patch-4' of https://github.com/fabioromano1/jdk into patch-4
- Merge branch 'openjdk:master' into patch-4
- An optimization
- Correct BigInteger(int , Random)
- Made random generation of BigIntegers faster
Change
On Mon, 27 Nov 2023 22:34:12 GMT, Brian Burkhalter wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> src/java.base/share/classes/java/math/BigInteger.java line 754:
>
>> 752: // numInts >= 1, since
> A faster and simpler way to generate random BigIntegers, avoiding eventually
> trimming of leading zeros in magnitude array.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Update BigInteger(int, Random)
Update a c
On Tue, 28 Nov 2023 01:08:43 GMT, Brian Burkhalter wrote:
>> It's equivalent. If you watch the implementations of other methods in the
>> class where a mask out is made, this method is often used.
>
> Indeed it looks as if that is correct.
As specified in
https://docs.oracle.com/javase/specs/j
On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional
>
On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote:
>> Do you have any actual benchmark measurements that you could share?
>
>> @bplb I have not yet made benchmark measurements, but I can produce them.
>
> @fabioromano1 I think it would be good to measure and r
On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote:
>> Do you have any actual benchmark measurements that you could share?
>
>> @bplb I have not yet made benchmark measurements, but I can produce them.
>
> @fabioromano1 I think it would be good to measure and r
> A faster and simpler way to generate random BigIntegers, avoiding eventually
> trimming of leading zeros in magnitude array.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Create RandomBigIntegers.java
Create a benchm
On Thu, 30 Nov 2023 20:37:37 GMT, Roger Riggs wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update BigInteger(int, Random)
>>
>> Update a comment
>
> There are some
On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
On Mon, 4 Dec 2023 22:26:32 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
On Tue, 5 Dec 2023 22:01:04 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Create RandomBigIntegers.java
>>
>> Create a benchmark to measure the p
The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
Hacker's Delight (2nd ed), section 9.3, the same used in
`Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`, to
get the computation faster.
-
Commit messages:
- Merge branch 'openjdk
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated the
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated
On Mon, 8 Jan 2024 18:20:09 GMT, Brian Burkhalter wrote:
> Do you have any benchmark results demonstrating the increased throughput?
I just uploaded a class for random tests. But during the execution, I've found
a non banal problem concerning the old implementation's running time.
The problem i
On Mon, 22 Jan 2024 15:14:58 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> The test does not seem to check that the
On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> Sure. But the purpose of a test is not much t
On Mon, 22 Jan 2024 15:38:08 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> Sure. But the purpose of a test is not much t
On Mon, 22 Jan 2024 16:15:57 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> What about splitting the result of `divWord(
On Mon, 22 Jan 2024 17:23:22 GMT, Raffaello Giulietti
wrote:
> AFAIK, IntrinsicCandidate methods are only relevant in JIT compiled code. A
> test that checks correctness might not reach the compilation stage, and
> execute only in the bytecode interpreter.
>
> But IMO using the result of `div
On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> As you note, that would probably require two
> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
> Hacker's Delight (2nd ed), section 9.3, the same used in
> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
> to get the computation faster.
fabioromano1 has updated
On Mon, 22 Jan 2024 18:07:49 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed trailing whitespaces
>
> As you note, that would probably require two
On Mon, 22 Jan 2024 20:02:34 GMT, Brian Burkhalter wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update TestDivWord.java
>>
>> Added method to check results of divWo
On Mon, 22 Jan 2024 21:26:39 GMT, Brian Burkhalter wrote:
>> @bplb It is not used in jtreg testing.
>
> So it is only for verification purposes in the context of this PR?
@bplb Yes, it is.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17291#discussion_r1462444386
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
-
1 - 100 of 165 matches
Mail list logo
