IFloatingPoint math functions

[rick-de-water]

Right now almost all math functions are part of the IFloatingPoint interface. The problem with this is that it makes it very difficult to make generic math objects that require any math functions.

For example, it is impossible to make a generic vector with a Length property that also allows for integers:

public struct Vector2<T>
    where T : INumber<T>
{
    T X { get; set; }
    T Y { get; set; }

    T Length => // ???
}

I need Sqrt to calculate the length, but it is only available for IFloatingPoint.

Another issue of placing math functions in IFloatingPoint is that everything that wants to support these math functions has to be a IFloatingPoint So if I want to make Vector2 support Ceiling, that would mean that Vector2 is a IFloatingPoint, which seems a bit odd.

So I suggest two changes to fix these issues:

1. Treat the mathematical functions like the operators, and give most of them their own interfaces: ITrigonometryMethods, IRoundingMethods, IExponentMethods, etc. This allows anything to implement a subset of the math functions without having to become IFloatingPoint. It also makes it so you don't have to implement every single math function when you just want to add a Sqrt to your object.
2. Implement these math functions for ALL INumber types, even integers. Even if the result get rounded, and if some functions like Sin and Cos don't return something that is actually very useful, it is still a lot better than having to drop all integer support in your class because you happen to call Sqrt in one function.

[CyrusNajmabadi]

This is not a language concern. Moving to runtime.

[msedi]

The question is if it really needs to be called IFloatingPoint instead of something like IMath.
Nevertheless the problem could be that some operations might not be defined for example IsNan for int, or what is Log on an int. I would think that it should return float (or double)?

I fully agree with you that there needs to be a common solution because I have very often stumbled across the same problem and I don't know if this problem can be solved. You might need different return types, specific for what you want to have as a result, but I think that's currently out of scope for C# and will surely be a breaking change.

The IMath would then have a possibility for different return types IMath<Tin,Tout>.

[rick-de-water]

Hmmm, a different return type would make a lot more sense. int goes in, double comes out is better than int goes in, some rounded int comes out with a lot of these functions.

Deciding which one to then pick as the output and cast back to your own number type is a bit more complicated though, especially if you also want to handle custom types such as BigInteger.

[tannergooding]

Floating-point in .NET, and computers in general, tends to be IEEE 754 floating-point. The interface here represents that and so exposes the operations that are expected or recommended to exist by the spec.

We could certainly look at separating certain functionality out slightly, but there are limits to the number of interfaces we should expose here and to how that would be exposed or usable in practical scenarios.

At the end of the day, exposing a number type that meets users needs and expectations is non-trivial and always will be. Even just considering arithmetic operations there are a multitude of things to support, but types are also typically expected to implement contracts around equality, to provide parsing/formatting support, to expose "basic" functionality around more complex operations (like Sign, Max, Min, Clamp, Log, Tan, Sqrt, etc), and more.

This is also not unique to .NET. This is how many popular languages that have direct support for various types of "number-contracts" expose that contract.

[rick-de-water]

there are limits to the number of interfaces we should expose here and to how that would be exposed or usable in practical scenarios.

Once you look at the operators as math functions themselves, and the amount of interfaces that were created for them, it does not seem strange to me to add interfaces for certain groups of math functions, like I stated in the post.

At the end of the day, exposing a number type that meets users needs and expectations is non-trivial and always will be.

I agree, and the average programmer would never even touch this stuff. But in my opinion it is important to give library writers the tools they need to write the libraries they want to write. I feel like .NET is definitely going in the right direction with features such as Span and source generators, and I really think that this would also be a valuable addition to these new interfaces.