Structures for non-primitive numerical data types

[dylanrafael05]

Please excuse my terrible explanation skills, it is very late and I am very tired

Overview

Currently in C#, there is no built-in analogs to half, binary256, int128, and other such types seen in both the IEEE754 specification, and other programming languages. Such numerical types, although less flexible than the BigInteger and BigDecimal structures of the System.Numerics namespace, would theoretically allow for faster code, as the need for dynamic sizing would be eliminated.

Larger Numeric Values

In scientific and data-analysis oriented programs, it is often found that the provided numerical types of C# are insufficient to represent the data needed. As such, the following structures should be added to the Standard library, using the primitive type ulong to store the raw data:

struct Float128 {} //uses two ulongs
struct Float256 {} //uses four ulongs

struct Int128   {} //uses two ulongs
struct UInt128  {} //uses two ulongs
struct Int256   {} //uses four ulongs
struct UInt256  {} //uses four ulongs

Half-precision Floating Point Values

Furthermore, several graphics engines require the usage of half-precision floating point values. As such, a System.Half struct would prove extremely useful (and can be created relatively easily, using a ushort backing). For example:

using System.Half as half;

half shaderParamForGL3 = 0; //Implicit conversion from byte to half
shaderParamForGL3 = (half)1028.1; //explicit conversion from all other numeric types

The above code would provide library creators with much simpler ways to interace with existing code, like OpenGL, which uses half-precision floats.

Notes

All above types should define the following:

//CONSTANTS
public const <type> MinValue = <min value of type>;
public const <type> MaxValue = <max value of type>;

//MATH OPERATORS
public static <type> operator +(<type> l, <type> r);
public static <type> operator +(<type> v);
public static <type> operator -(<type> l, <type> r);
public static <type> operator -(<type> v);

public static <type> operator *(<type> l, <type> r);
public static <type> operator /(<type> l, <type> r);
public static <type> operator %(<type> l, <type> r);

//BOOL OPERATORS
public static bool operator ==(<type> l, <type> r);
public static bool operator !=(<type> l, <type> r);
public static bool operator <(<type> l, <type> r);
public static bool operator >(<type> l, <type> r);
public static bool operator <=(<type> l, <type> r);
public static bool operator >=(<type> l, <type> r);

//CONVERSIONS
  //TO AND FROM ALL OTHER NUMERIC TYPES, INCLUDING THOSE DEFINED HERE
  //FOR FLOATING POINT TYPES, ONLY TO/FROM BYTE IS IMPLICIT
  //FOR INTEGER TYPES, TO/FROM ALL INTEGERS WITH LESS CAPACITY, AS WELL AS ALL FLOATING POINTS THAT
    //CAN CONTAIN THE INTEGERS WITHOUT ROUNDING ERROR ARE IMPLICIT

[huoyaoyuan]

This is a BCL feature request, not a C# one.
The "built in" numeric types are special because they are special in IL. They have corresponding IL instructions for arithmetic operations, IL specication about how to store it for constant.
The proposed new types would behave closer to decimal. It's not primitive in IL, but gets primitive-like support in C#. However, specially treating such type is non pratical. There is a proposal to encode constants for non primive types.

Arithmetic operators are totally BCL feature request.

[CyrusNajmabadi]

Transferring to dotnet/runtime for this API request. If the BCL added this, we might consider having aliases for this in the c# language itself (similar to decimal). However, that work would be gated on this being in the runtime in the first place. Thanks!

[tannergooding]

As per my comment below (#51046 (comment)), these types fall into an odd category where they generally cannot be shipped by the runtime and supported by the language later.

There are many differences in how the compiler treats operators and conversions that make this breaking. For System.Half we had some fairly extensive discussions with LDM to determine the correct approach and eventually determined that for Half the tradeoffs were reasonable.
We might be able to say the same is true for any other floating-point type, like a System.Quad (128-bit float)

Integral types, like Int128, are strictly blocked today without simultaneous language support as they support checked/unchecked contexts when language primitives. If the runtime ships and the language does not, then checked { Int128 x= Int128.MaxValue + 1; } will not overflow like you might expect, where-as it will when the language eventually adopts it.

I've proposed a way to support checked/unchecked operators on user-defined types in the past, but it hasn't gotten much traction: dotnet/csharplang#686
I'm attempting to renew some of the discussion in relation to the static abstracts on interfaces work.

[tannergooding]

We already expose System.Half, it shipped in .NET 5: https://docs.microsoft.com/en-us/dotnet/api/system.half?view=net-5.0

Float128 and Float256 could be conceivably exposed today and Float128 (quad-precision floating-point) is at least strictly defined by the IEEE spec. Float256 is not, and informally falls into the "general" extension of BigFloat where the bitness is a multiple of 32. Much like Half they would not have support for constants, literals, or a few of the other niceties that require language support.

Int128/UInt128 and Int256/UInt256 cannot be exposed without simultaneous language support today. There is no way for the BCL to support checked/unchecked operators without this and so the libraries exposing these without simultaneous language support becomes a breaking change if the language wants to adopt them later (this is the IntPtr/nint problem, all over again).

If you would like to see any of these added I would suggest opening individual API proposals following our template: https://github.com/dotnet/runtime/issues/new?assignees=&labels=api-suggestion&template=02_api_proposal.md