Generic overloads for Math.Max etc that take T where T : IComparisonOperators<T, T, bool>

[Richiban]

There are some very useful methods in the Math static class that would benefit from "generic math" overloads, such as Max, Min etc.

I'm imagining that the source would look something like this:

        T Max<T>(T left, T right) where T : IComparisonOperators<T, T, bool>
        {
            return left > right ? left : right;
        }

Come to think of it, I also don't see generic math implementations for things like IEnumerable.Sum*. Are these coming in a future version of .NET?

*where the implementation would be something like

    public static R Sum<T, R>(this IEnumerable<T> source) 
        where T : IAdditiveIdentity<T, R>,
                  IAdditionOperators<T, R, R>
    {
        var sum = T.AdditiveIdentity;

        foreach(var x in source)
        {
            sum = x + sum;
        }
                      
        return sum;
    }

[huoyaoyuan]

#63732

[Richiban]

Thanks! I was expecting this to have been asked before but (for some reason) searching the repo for things like IComparisonOperators returned no results!

[tannergooding]

Yep there is also #85979 and #18481.

TL;DR: We're not planning on exposing such APIs.

Math/MathF are effectively frozen and not being versioned anymore moving forward. where T : INumberBase<T> gives you access to MinMagnitude, MinMagnitudeNumber, MaxMagnitude, and MaxMagnitudeNumber. While where T : INumber<T> gives you access to Min, MinNumber, Max, and MaxNumber.

Something that is constrained where T : IComparable<T> could also be supported, but it would have distinct/separate semantics.

That being said, I would be open to someone creating a proposal for some static class Comparable that exposes methods such as Min/Max/Clamp constrained to IComparable<T> and willing to take that to API review. That would isolate its location and provide clearer semantics around it being tied to IComparable.

[Richiban]

Thanks @tannergooding

I'm a bit dismayed to hear this, but I do fully understand why.

The reason I'm dismayed is because I was hoping the functions would have the minimal possible requirements on T so that I can implement things like IComparisonOperators on my own types and then get functions like Min, Max, Sum etc "for free". The problem is that INumber<T> is a huge interface, and it's completely impractical to implement it on your own types (not to mention it might be wrong to do so; e.g. a type called Money might naturally support addition and subtraction, but not multiplication or division).

Thank you for your consideration though! A static class Comparable might be a good way to go.

[tannergooding]

An issue is that you can't provide the full set of correct Min/Max/Clamp operations given simply IComparisonOperators.

Types may have special or additional semantics that apply, such as how NaN is handled. That is why the APIs are defined as part of INumberBase<T> and INumber<T>, respectively. As it allows us to take the general purpose operators and give them well-defined semantics in the face of number like concepts such that the entire set of 8 Min/Max APIs can be defined.

Likewise, the existence of IAdditionOperators doesn't necessarily mean you can make Sum well defined. There are types that support + but treat it more like concatenate (string for example) and while you can squint and say that concatenating many strings is like computing their sum; things don't quite align nicely.

It is indeed not a low bar to implement and support something like INumber<T>. However, it prescribes the set of functionality that is expected of number like types in the broader sense and which allows that support to be versioned over time without requiring breaking changes or INumber2, INumber3, INumberEx like interfaces.