Int multiplication methods producing value in larger type

[acaly]

Is there or will there be a general way in the generic maths to allow us to multiply the value and get the result in a larger type, e.g. multiply two ints into a long, or multiply two ulong into a UInt128?

Thanks.

[danmoseley]

@dotnet/area-system-numerics

[tannergooding]

I don't think its something that will very feasible to expose at this time as without something like "Associated Types", the closest we could get is something like (T Lower, T Upper) BigMul(T left, T right).

This then has some potentially questionable semantics with regards to non-fixed width types like BigInteger and may be difficult to use in contexts where you don't know the actual underlying type.

[acaly]

Thanks for the reply.

I don't think (T Lower, T Upper) BigMul(T left, T right) is the correct API. BigMul(int, int) should gives long, which is effectively a int + uint, not two ints. I think what we need is a TLonger BigMul(T, T).

So what is the problem of adding a new interface IBigMul<TSelf, TLonger> and implement int : IBigMul<int, long> and so on for now?

[tannergooding]

So what is the problem of adding a new interface IBigMul<TSelf, TLonger> and implement int : IBigMul<int, long> and so on for now?

Such an interface requires any consumer of IBigMul to track and know which two types are valid, which ends up being a limited and very specific set of types in practice. This is also not a "common" operation like the I*Operators interfaces. It largely only impacts the fixed-width primitive types. This makes it much harder to actually successfully utilize the interface and achieve success.

Math.BigMul already has a pattern for the shape (T Lower, T Upper) BigMul(T left, T right), as do several other languages that provide "big mul" like intrinsics or APIs so this ends up working slightly better with what we can support today, but it is still overall difficult to use correctly in a generic context.

I think this is something we need to wait for more language features around. Devs who have specific needs can always provide their own extensions, helper methods, specializations, etc. The algorithm for computing the "big" version is overall fairly straightforward after all.