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 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 (
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);
> }
>
T
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
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
*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);
Until there's a no-throw version of Math.*Exact I may have to go with this
code.
*Charles Oliver
