On Sat, Jan 11, 2025 at 12:09 AM John Rose wrote:
> https://bugs.openjdk.org/browse/JDK-8285871
> Math.multiplyHigh and multiply on same inputs can be computed faster if
> their computation is shared
>
I must admit it seemed odd to me that there was a `multiplyHigh` without a
corresponding `mult
On 13 Dec 2024, at 5:22, Raffaello Giulietti wrote:
> For your specific multiplication use case you might try with
>
> long high = Math.multiplyHigh(a, b);
> long low = a * b;
> if (high == 0) return low;
> return "the big integer consisting of high and low";
>
> It might be possible that the mult
On Fri, Jan 10, 2025 at 8:48 PM Charles Oliver Nutter
wrote:
> This pasted weirdly... but it doesn't matter because there's an additional
> flaw: it will reject *all* negative results because the high 64 bits will
> be non-zero.
>
This version passes all my tests:
if ((high == 0 && low >= 0) //
On Fri, Jan 10, 2025 at 8:31 PM Charles Oliver Nutter
wrote:
> long high = Math.multiplyHigh(value, other);
> long low = value * other;
> if (high == 0 && low >= 0 || value < 0 || high == 0 && other < 0) {
> return asFixnum(context, low);
> }
>
This pasted weirdly... but it doesn't matter be
On Fri, Dec 13, 2024 at 7:22 AM Raffaello Giulietti <
raffaello.giulie...@oracle.com> wrote:
> long high = Math.multiplyHigh(a, b);
> long low = a * b;
> if (high == 0) return low;
> return "the big integer consisting of high and low";
>
There's a flaw in this logic: the overflowed multiplication
Chen Lian wrote:
> can you showcase any related ruby behavior using this model?
The use case is normal Ruby integer math: there's only one Integer type
that is backed either by 64-bit(ish) fixnums (wrapping a Java long) and
arbitrary precision bignums (wrapping BigInteger).
The logic in JRuby is
Hi,
Another API alternative would be to add a version that triggers a lambda
on overflow and allow the caller to determine the value or throw.
public static long multiplyExact(long x,long y,LongBinaryOperator recompute) {
long r =x *y;
long ax =Math.abs(x);
long ay =Math.abs(y);
On 2024-12-12 23:58, Charles Oliver Nutter wrote:
Question two: Am I losing the benefits of *Exact if I use the following
code to "pre-check" for overflow?
long high = Math.multiplyHigh(a, b);
if (high == 0) return Math.multiplyExact(a, b);
return bigIntegerMultiply(a, b);
For your spec
es Oliver Nutter"
> To: "Core-Libs-Dev Libs"
> Sent: Thursday, December 12, 2024 11:58:32 PM
> Subject: High cost of failed Math.*Exact calls
> Hey folks, I was looking into a performance bug report for JRuby that did a
> lot
> of numeric work (a prime number
Seems what we desire here is an "exact or alternative value" model instead of
an "avoid overflow" model. This sounds interesting - can you showcase any
related ruby behavior using this model?
I think an alternative can be *IfExact that returns a nullable value, if we do
not need more informatio
On Thu, Dec 12, 2024 at 6:22 PM Ethan McCue wrote:
> Placement in the standard library aside, I think Java needs value types
> and patterns before a non-throwing version of Math.multiplyExact can be
> made that achieves the same semantic goals.
>
> switch (Maths.multiplyExact(a, b)) {
> case
Placement in the standard library aside, I think Java needs value types and
patterns before a non-throwing version of Math.multiplyExact can be made
that achieves the same semantic goals.
switch (Maths.multiplyExact(a, b)) {
case Product.of(long result) -> {}
case Product.overflow() -> {}
Hey folks, I was looking into a performance bug report for JRuby that did a
lot of numeric work (a prime number detector) and ran into a bottleneck due
to our use of Math.multiplyExact.
Basically, the *Exact methods work great as long as you never actually
overflow. If you overflow (too much), the
13 matches
Mail list logo
