[API Proposal]: Add missing BigMul overload for uint x uint -> ulong

[lilinus]

Background and motivation

Many of the integer types available for other operations are missing for Math.BigMul

API Proposal

namespace System;

public static class Math
{
    public static Int128 BigMul(long a, long b);
    public static ulong BigMul(uint a, uint b);
    public static UInt128 BigMul(ulong a, ulong b);
}

public readonly struct Int32
{
    public static long BigMul(int a, int b);
}

public readonly struct Int64
{
    public static Int128 BigMul(long a, long b);
}

public readonly struct UInt32
{
    public static ulong BigMul(uint a, uint b);
}

public readonly struct UInt64
{
    public static UInt128 BigMul(ulong a, ulong b);
}

API Usage

// Fancy the value
var x = uint.MaxValue;
var y = uint.MaxValue - 1;
var z = Math.BigMul(x, y);

Alternative Designs

Only adding it to Uint32 class instead of Math. (BigMul doesnt exist on other concrete types yet, but can be taken in other api suggestion if relevant)

namespace System;

public readonly struct UInt32
{
    public static ulong BigMul(uint a, uint b);
}

Risks

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

Many of the integer types available for other operations are missing for Math.BigMul

API Proposal

namespace System;

public static class Math
{
    public short BigMul(sbytet a, sbyte b);
    public ushort BigMul(bytet a, byte b);
    public short BigMul(bytet a, short b);
    public uint BigMul(ushort a, ushort b);
    public ulong BigMul(uint a, uint b);
}

API Usage

// Fancy the value
var x = uint.MaxValue;
var y = uint.MaxValue - 1;
var z = Math.BigMul(x, y);

Alternative Designs

No response

Risks

No response

Author:	lilinus
Assignees:	-
Labels:	api-suggestion, area-System.Numerics
Milestone:	-

[huoyaoyuan]

In fact, there's no arithmetic operator defined for small integer types. They need to be upcasted to 32bit. The default operator already behaves as BigMul.

[lilinus]

Ah i see, the main one IMO that is missing is uint x uint -> ulong, suince we already have int x int -> long

[colejohnson66]

What's wrong with just using (ulong)left * (ulong)right? IMO, long BigMul(int, int) shouldn't exist.

[tannergooding]

What's wrong with just using (ulong)left * (ulong)right? IMO, long BigMul(int, int) shouldn't exist.

It's not as clear and not as easy to take advantage of hardware specific optimizations, particularly on 32-bit platforms.

Ah i see, the main one IMO that is missing is uint x uint -> ulong, suince we already have int x int -> long

We have this one internally, so if you update the proposal we can discuss exposing it.

Notably, we may want to discuss whether or not this should be int.BigMul and uint.BigMul instead, since generic math has effectively soft-obsoleted Math and new APIs were planned to be static methods on the concrete types instead.

[lilinus]

Updated suggestion accordingly @tannergooding

[MichalPetryka]

Should there be some new IBigMultiplicable<TSelf, TResult> for this?

[lilinus]

Should there be some new IBigMultiplicable<TSelf, TResult> for this?

Sounds reasonable. Maybe IBigMultiplicable<TSelf, TOther, TResult> so it is more aligned with e.g. IMultiplyOperators<TSelf,TOther,TResult>

Best to make separate api suggestion for that?

[tannergooding]

Exposing a different interface for big multiplication is difficult and not necessarily extensible.

It only works with very precise types (T and a type that is effectively twice the bitwidth of T). It really needs something more akin to associated types to make work in the ways people would actually want. Without such a feature, you basically end up not being able to write generic code that actually works with BigMul the way people would want.

You could define a general signature that returns upper/lower halves in a tuple instead, but that can have its own problems as well.

[bartonjs]

Video

• The question was raised of why add these on the Math type, since we have previously said that the type is soft-deprecated.
  • The answer is "because they're overloading an existing member."
• There was a brief question about the applicability to generic math, but since that requires (TSelf, TBigger) or (TSelf, TSmaller) that's too complicated, so this finite set is all we get.
• We'll leave the ones on Math as (a, b) to match the current method, but the ones on each type will use the more globally-consistent (left, right) naming.
• There's no real need to do this for (s)byte -> (~u)short, or (u)short -> (u)int.

namespace System;

public static partial class Math
{
    public static Int128 BigMul(long a, long b);
    public static ulong BigMul(uint a, uint b);
    public static UInt128 BigMul(ulong a, ulong b);
}

public readonly partial struct Int32
{
    public static long BigMul(int left, int right);
}

public readonly partial struct Int64
{
    public static Int128 BigMul(long left, long right);
}

public readonly partial struct UInt32
{
    public static ulong BigMul(uint left, uint right);
}

public readonly partial struct UInt64
{
    public static UInt128 BigMul(ulong left, ulong right);
}