> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request with a new target base due to
a merge or a rebase. The pull request now contains 13 commits:
- Merge master.
- Refactoring to paramaterized tests.
- Remo
On Thu, 31 Jul 2025 08:40:40 GMT, fabioromano1 wrote:
>> 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 111 commits:
>
> - Merge branch
On Thu, 31 Jul 2025 13:13:39 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1921:
>>
>>> 1919: * The contents of {@code this} are not changed. The
>>> value of {@code this}
>>> 1920: * is assumed to be non-negative and the root degree {@c
On Mon, 14 Jul 2025 16:52:31 GMT, fabioromano1 wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed useless instruction
>
> The integers are closed under positive powers, and not under positive
> nthRoots, this
On Wed, 30 Jul 2025 14:18:49 GMT, Chen Liang wrote:
>> In #24773, people were concerned that the layout of a UTF16 byte array and a
>> char array may be incompatible. In fact, they are - they are asserted in a
>> corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>>
>
On Mon, 16 Jun 2025 18:19:29 GMT, Justin Lu wrote:
>> I don't have a specific example, so I've reverted to my original check. I'm
>> a bit unsettled by the check for an extreme value later in `doubleValue()`
>> comparing against `MIN_DECIMAL_EXPONENT - 1`
>
> IMO, the original check you had is
On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Tue, 29 Jul 2025 21:09:59 GMT, Chen Liang wrote:
> In #24773, people were concerned that the layout of a UTF16 byte array and a
> char array may be incompatible. In fact, they are - they are asserted in a
> corner in `LibraryCallKit::inline_string_char_access` in `library_call.cpp`.
>
> In
On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen wrote:
>> In BufferedReader.readLine and other similar scenarios, we need to use
>> StringBuilder.append(char[]) to build the string.
>>
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy
>> of the char-by-char loop to i
On Tue, 29 Jul 2025 14:38:40 GMT, fabioromano1 wrote:
>> Here we have a kind of opposite case: rad can become very imprecise, up to
>> losing all bits from x and become 0.
>> I think this deserves a quick comment.
>
>> Here we have a kind of opposite case: rad can become very imprecise, up to
>
On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Tue, 29 Jul 2025 14:19:19 GMT, fabioromano1 wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comment
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 2022:
>
>> 2020: } else { //
On Tue, 29 Jul 2025 13:55:08 GMT, fabioromano1 wrote:
>> Well, that was the easy case!
>> (BTW, the condition shExcess != 0 on L.2025 is always true, as shExcess >
>> Double.MAX_EXPONENT - Double.PRECISION there.)
>>
>> There should be similar reasoning for the `else` part on L.2020.
>>
>> And
On Tue, 29 Jul 2025 13:26:41 GMT, fabioromano1 wrote:
>> My point is that this should be done, not the exact form it takes. Mine or
>> yours are both better than nothing.
>>
>> Another point I wanted to make is that the `if` condition bl - (sh - ex) ≤
>> ME can be replaced with the simpler ex
On Tue, 29 Jul 2025 12:25:21 GMT, fabioromano1 wrote:
>> @rgiulietti Yes, but why that complication, it is not more natural to prove
>> it in the following way?
>>
>> recalling x < 2^bl:
>> x / 2^sh' = x / 2^(sh-ex) ≤ 2^bl / 2^(sh-ex) = 2^(bl - (sh-ex)) ≤ 2^ME <
>> Double.MAX_VALUE
>> ```
>>
On Tue, 29 Jul 2025 11:05:43 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 2002:
>>
>>> 2000: // Try to shift as many bits as possible
>>> 2001: // without losing precision in dou
On Tue, 29 Jul 2025 11:03:24 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Zimmermann suggestion
>
> src/java.base/share/classes/java/math/MutableBigInte
On Mon, 28 Jul 2025 14:03:16 GMT, fabioromano1 wrote:
>> 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:
>
> Zimmermann suggestion
src/java.base/shar
On Mon, 28 Jul 2025 17:13:48 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1993:
>>
>>> 1991: * non-significant bits), and the shift is performed in
>>> order to lose
>>> 1992: * the smallest number of bits in the signifi
On Mon, 28 Jul 2025 14:03:16 GMT, fabioromano1 wrote:
>> 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:
>
> Zimmermann suggestion
src/java.base/shar
On Mon, 28 Jul 2025 01:11:26 GMT, Shaojin Wen wrote:
>> I prefer to calculate an ARRAY_CHAR_SHIFT in the constant like ShortVector
>> does, like this
>>
>> static final int ARRAY_CHAR_SHIFT
>>= 31 -
>> Integer.numberOfLeadingZeros(Unsafe.ARRAY_CHAR_INDEX_SCALE);
>>
>>
On Sun, 27 Jul 2025 08:26:59 GMT, Thomas Zimmermann wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> A zero root's shift can't be excluded
>
> src/java.base/share/classes/java/math/BigInteger.java line 2773:
>
>> 2
On Fri, 25 Jul 2025 15:18:00 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1934:
>>
>>> 1932: return new MutableBigInteger[] { this, new
>>> MutableBigInteger() };
>>> 1933:
>>> 1934: final int bitLength = (int) this.bitLength
On Fri, 25 Jul 2025 15:26:37 GMT, fabioromano1 wrote:
>> Of course.
>> To the caller, a `final` parameter does not convey any information, and
>> makes the method/constructor header less concise.
>> There are thousands of methods in the JDK that do no alter their parameters,
>> and yet these ar
On Fri, 25 Jul 2025 15:36:59 GMT, Raffaello Giulietti
wrote:
>> Yes, but in this way you see at a glance that the parameter is a constant,
>> and you do not have to check all the method's code.
>
> I guess most developer use a Java IDE for Java development.
> My ID
On Fri, 25 Jul 2025 15:14:42 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1929:
>>
>>> 1927: * @return the integer {@code n}th root of {@code this} and the
>>> remainder
>>> 1928: */
>>> 1929: MutableBigInteger[] nthRootRem(final in
On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen wrote:
>> In BufferedReader.readLine and other similar scenarios, we need to use
>> StringBuilder.append(char[]) to build the string.
>>
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy
>> of the char-by-char loop to i
On Fri, 27 Jun 2025 01:04:32 GMT, Shaojin Wen wrote:
>> In BufferedReader.readLine and other similar scenarios, we need to use
>> StringBuilder.append(char[]) to build the string.
>>
>> For these scenarios, we can Unsafe.copyMemory instead of the character copy
>> of the char-by-char loop to i
On Wed, 23 Jul 2025 23:19:49 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti
>>> The Brent & Zimmermann paper assumes an initial estimate u ≥ ⌊ x 1 / n ⌋ ,
>>> probably for a (unstated) reason.
>>
>> The reason is the condition to stop the loop, since
On Wed, 23 Jul 2025 21:11:16 GMT, fabioromano1 wrote:
>> I noticed the usage of exp() and log(), thanks for the change.
>>
>> My concerns about using transcendental are rooted in [this
>> paper](https://members.loria.fr/PZimmermann/papers/accuracy.pdf).
>> The Javadoc claims an error of 1 ulp f
On Wed, 23 Jul 2025 17:40:22 GMT, fabioromano1 wrote:
>> Can you please provide a succinct "proof" in form of a comment? Needs to be
>> convincing, although not necessarily rigorous.
>
> @rgiulietti I've changed the formula that computes the initial estimate, now
> it does not use `Math.pow()`
On Wed, 23 Jul 2025 16:11:20 GMT, fabioromano1 wrote:
>> 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:
>
> More accurate lower bound for doubles val
On Mon, 14 Jul 2025 16:41:15 GMT, fabioromano1 wrote:
>> This is my hunch as well.
>> So while the use of `nextUp()` and `ceil()` certainly help to achieve an
>> overestimate, I'm less sure that this is sufficient when using `pow()`. If
>> the latter has some error bigger than a few ulps, then
On Tue, 22 Jul 2025 18:38:28 GMT, fabioromano1 wrote:
> The cases in which the method throws correspond to the cases in which the
> integer root is not defined.
Yes, that's why it should be part of the definition: like in "the largest
integer ..., if it exists; otherwise the result is undefine
On Wed, 16 Jul 2025 14:40:53 GMT, Raffaello Giulietti
wrote:
>> I don't know other ways to define it that don't involve the clause `!(x < 0
>> && n % 2 == 0)`. If the first definition is confusing, the only solution I
>> see is to remove it, and leave on
Hi,
the errors are so large that I'd dare to say that the measurements are
unreliable.
On 2025-07-22 13:44, Brett Okken wrote:
It does look like this is windows specific. If I run on WSL, I get
results similar to your linux-x64:
Benchmark (data) Mode Cnt Score
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Refactoring to paramaterized tests.
-
Changes:
- all: https://git.openjdk.org/
On Thu, 17 Jul 2025 23:15:44 GMT, John R Rose wrote:
>> Yep, to distinguish access and the encapsulated read-modify-write atomicity,
>> I decided to avoid using "atomic"/"non-atomic" altogether - now it is just
>> "make no atomicity guarantee"
>
> Not sure this is relevant, but isn't "opaque" a
On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Implement review feedback.
Since the refactoring
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Removed temporary comment from tests.
-
Changes:
- all: https://git.openjdk.org/
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added tests.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/26364/files
-
On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Implement review feedback.
Looks fine
--
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:26:14 GMT, Naoto Sato wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> Good to see this enhancement, Raffaell
On Thu, 17 Jul 2025 17:58:51 GMT, Justin Lu wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/internal/
On Wed, 16 Jul 2025 18:51:41 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> The methods directly affected by this update are atan, exp, and sin, cos,
> tan. The sin, cos, and tan method are affected by the updates to
> KernelRemPio2 and ta
On Thu, 17 Jul 2025 14:29:08 GMT, Raffaello Giulietti
wrote:
> What is the thinking when an `@IntrinsicCandidate` method invokes another
> `@IntrinsicCandidate` method? Which part is responsible for the checks?
>
> For example, the Java code of `StringCoding.encodeISOArray
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 10 Jul 2025 12:18:25 GMT, Volkan Yazici wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace casting with `as_Region()` in `generate_string_range_check`
>
> src/java.base/share/classes/java/lang/StringC
On Thu, 17 Jul 2025 07:20:34 GMT, Volkan Yazici wrote:
>> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
>> their documentation, enhance the checks in the associated IR or assembly
>> code, and adapt them to cause VM crash on invalid input.
>>
>> ## Implementation
On Thu, 17 Jul 2025 13:41:06 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added comment to COMPAT static field.
>
> src/java.base/share/classes/jdk/interna
> Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added comment to COMPAT static field.
-
Changes:
- all: https://git.openjdk.org/
On Wed, 16 Jul 2025 04:53:04 GMT, Joe Darcy wrote:
> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
The arrays at L.2257-2262 could be declared `static` and `@Stable` as well, and
moved outside the method.
src/java.base/share/classes/java/lang/FdLibm.java line 815:
Align the behavior of `DecimalFormat` on `double`s with that of `Formatter`.
-
Commit messages:
- Merge branch 'master' into 8362448
- 8362448: Make use of the Double.toString(double) algorithm in
java.text.DecimalFormat
- Remove some unused methods from FloatingDecimal.
- Rename
On Wed, 16 Jul 2025 10:32:41 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2755:
>>
>>> 2753: * is even and this BigInteger is negative, an {@code
>>> ArithmeticException} will be
>>> 2754: * thrown.
>>> 2755: *
>>
>> I think this specifi
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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 instruction
src/java.bas
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Tue, 15 Jul 2025 01:10:05 GMT, Joe Darcy wrote:
> From discussions related to IEEE 754, a few explicit test cases were
> identified where plausible, but incorrect, implementations of fma using
> higher precision. These test cases are useful to include in the regression
> tests of the float-
On Wed, 4 Jun 2025 13:12:33 GMT, Shaojin Wen wrote:
>> Some static final arrays of BigInteger and BigDecimal are stable and
>> immutable. We should add `@Stable` to give the optimizer more information
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a reba
On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti
wrote:
> Another step in enhancing floating-point <-> decimal conversions.
This pull request has now been integrated.
Changeset: 563e8762
Author:Raffaello Giulietti
URL:
https://git.openjdk.org/j
On Mon, 14 Jul 2025 15:46:47 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1936:
>>
>>> 1934: * where {@code nthRoot(., n)} denotes the mathematical {@code
>>> n}th root.
>>> 1935: * The contents of {@code this} are not changed. The
>>>
On Mon, 14 Jul 2025 15:40:18 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1964:
>>
>>> 1962: final double rad = Math.nextUp(x >= 0 ? x : x + 0x1p64);
>>> 1963: final double approx = n == 3 ? Math.cbrt(rad) :
>>> Math.pow(r
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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 instruction
I'm looking
On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>> 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 instruction
I agree that
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 wrote:
>> 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
Right.
--
On Fri, 11 Jul 2025 08:19:43 GMT, Aleksey Shipilev wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borr
On Fri, 6 Jun 2025 08:08:09 GMT, fabioromano1 wrote:
>> 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
Sure, the initial
On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote:
>> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is
>> about 3 weeks from now.
>>
>> I think it's a bit too late for API additions to be approved in due time.
>> And even if we could rush this work for 25, it mak
On Sat, 2 Dec 2023 15:42:18 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
> commit since the last revision:
On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 wrote:
>> So, item 1 is a non-issue and item 2 is not likely a problem in practice.
>> What, if anything, will be done about item 3?
>
> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a
> test class.
@fabioromano1 Do yo
On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote:
>> The uniqueness comes not just from the timestamp but also from the random
>> data in the other bytes that are generated for each new UUID.
>
> Hello Roger, that's true about the uniqueness semantics. However, from what I
> understand of RF
> Another step in enhancing floating-point <-> decimal conversions.
Raffaello Giulietti 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/rebase. The pull request conta
On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti
wrote:
> Documenting a suggestion for `float` arguments.
This pull request has now been integrated.
Changeset: 26848a7d
Author: Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/commit/26848a7d6ce4c573b679a690fd36e6d708224
> Documenting a suggestion for `float` arguments.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Suggestion by reviewer.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/25805/files
- new: ht
On Fri, 13 Jun 2025 17:39:38 GMT, Brian Burkhalter wrote:
>> Documenting a suggestion for `float` arguments.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 1383:
>
>> 1381: * the result usually contains too many trailing digits compared
>> 1382: * to the precision of a
Documenting a suggestion for `float` arguments.
-
Commit messages:
- 8358804: Improve the API Note of BigDecimal.valueOf(double)
Changes: https://git.openjdk.org/jdk/pull/25805/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25805&range=00
Issue: https://bugs.openjdk.org/
> Another step in enhancing floating-point <-> decimal conversions.
Raffaello Giulietti 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/rebase. The pull request contains two a
On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote:
>> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is
>> about 3 weeks from now.
>>
>> I think it's a bit too late for API additions to be approved in due time.
>> And even if we could rush this work for 25, it mak
On Wed, 4 Jun 2025 14:22:43 GMT, Raffaello Giulietti
wrote:
> Another step in enhancing floating-point <-> decimal conversions.
Changes include, but are not limited to:
- Accessing `g0()` and `g1()` with the exponent rather than the negated
exponent.
- Inverting the order of the `Ma
Another step in enhancing floating-point <-> decimal conversions.
-
Commit messages:
- 8358540: Enhance MathUtils in view of FloatingDecimal enhancements
Changes: https://git.openjdk.org/jdk/pull/25641/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25641&range=00
Issue:
On Wed, 4 Jun 2025 13:53:09 GMT, Raffaello Giulietti
wrote:
>> BigInteger is an object that is considered immutable, but its field mag is
>> actually changed. This is incredible and should be fixed here. It is easy to
>> make mistakes.
>
> Please do _not_ fix th
On Fri, 30 May 2025 22:21:34 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 192:
>>
>>> 190: * zero-length mag array.
>>> 191: */
>>> 192: @Stable
>>
>> `BigInteger.mag` gets written to a few times during computation in
>> `BigInteger.large
On Tue, 27 May 2025 21:42:37 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
> commit since the last revision
On Mon, 26 May 2025 18:44:58 GMT, Raffaello Giulietti
wrote:
> Add a `-Dcount=N` command line option to specify the number of random samples
> per test (default is 10'000).
This pull request has now been integrated.
Changeset: efeb050e
Author: Raffaello Giulietti
URL:
On Tue, 27 May 2025 17:14:32 GMT, fabioromano1 wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 4732:
>>
>>> 4730: /* Allocate output array. If all non-sign ints are 0x00, we
>>> must
>>> 4731: * allocate space for one extra output int. */
>>> 4732:
On Wed, 21 May 2025 09:12:49 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
> commit since the last revision
> Add a `-Dcount=N` command line option to specify the number of random samples
> per test (default is 10'000).
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Changed option name to "samples".
-
Add a `-Dcount=N` command line option to specify the number of random samples
per test (default is 10'000).
-
Commit messages:
- 8357808: Add a command line option for specifying a counter in
TestRandomFloatingDecimal
Changes: https://git.openjdk.org/jdk/pull/25460/files
Webrev:
Depending on which static final arrays, this might be fine.
On 2025-05-26 01:57, wenshao wrote:
Some static final arrays of BigInteger and BigDecimal are stable and
immutable. We should add @Stable to give the optimizer more information
-
Shaojin Wen
On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote:
>> Integer::digits type can use byte[] instead of char[], which can reduce the
>> conversion from char to byte in the process of Integer.toString. Using
>> byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementall
On Sat, 24 May 2025 07:19:24 GMT, Shaojin Wen wrote:
>> Integer::digits type can use byte[] instead of char[], which can reduce the
>> conversion from char to byte in the process of Integer.toString. Using
>> byte[] can also save memory.
>
> Shaojin Wen has updated the pull request incrementall
On Wed, 21 May 2025 09:09:15 GMT, Tagir F. Valeev wrote:
>> Implementation of Comparator.min and Comparator.max methods. Preliminary
>> discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max a
On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote:
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
> @rgiulietti It seems there is a s
On Tue, 20 May 2025 13:20:10 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
> commit since the last revision
On Fri, 16 May 2025 10:10:28 GMT, fabioromano1 wrote:
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
>> There are problems with the `test/jdk/java/math/BigInteger` tests. Can you
>> please crosscheck?
>
> @rgiulietti It seems there is a s
On Mon, 19 May 2025 17:16:58 GMT, fabioromano1 wrote:
>> I think the suggestion is fine.
>
> 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 t
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> Implementation of Comparator.min and Comparator.max methods. Preliminary
> discussion is in this thread:
> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
> The specification is mostly composed of Math.min/max and C
1 - 100 of 1007 matches
Mail list logo
