Proposal: Quadruple precision floats

[TheUnlocked]

As the title suggests, adding a new quad type with a literal like 3.141592653589793238462q. I understand that Decimal currently exists, but it has a very small maximum range compared to the massive range of a quadruple precision float (or even just a double). I suppose that a qint and uqint could also be added as well, though probably with better thought out names.

A potential drawback is that quadruple precision math doesn't tend to have the same kind of hardware acceleration that double precision math does, but sometimes the extra precision is worth that price.

[tannergooding]

This would require a corresponding type in CoreFX first.

Additionally, given that IL doesn't support literals for non-primitive types, there would need to be an alternative mechanism for supporting quad constants. Such support is probably better suited to a more general language feature (such as blittable constants).

As a workaround

.NET Core provides the BigNumber type which supports an arbitrary precision: https://source.dot.net/#System.Runtime.Numerics/System/Numerics/BigNumber.cs,969928e529663ace

[TheUnlocked]

Ah, I wasn't aware that .NET Core had a bignum implementation. I'll leave this open anyways because it still might be nice to have 128-bit numbers.

[iam3yal]

@TheUnlocked The question is what would be the benefit of 128-bit number as part of the language? I mean, "nice to have" can be interpreted as "redundant/unnecessary" so you may want to cover how the language benefits from this.

[TheUnlocked]

I initially thought that this would be useful upon seeing how the game Kerbal Space Program (written in C#) starts to bug out when you have a massive number of objects interacting with eachother due to double imprecision. While I'm not suggesting that it would make any sense to add a new language feature for a single program, that particular example shows that when dealing with massive simulations with a lot of moving pieces, doubles sometimes aren't enough.

I suppose another interesting thing to see would be a benchmarking (probably written in a language that does support quadruple precision) between quads and BigNumbers, to see if quads are sufficiently faster and less memory intensive to be worth it.

[4creators]

The question is what would be the benefit of 128-bit number as part of the language?

@eyalsk

This proposal is about implementing one of the binary formats from IEEE 754:2008 standard (currently translated into ISO/IEC/IEEE 60559:2011). In general implementation of parts or all of the IEEE 754:2008 is tracked by several issues in coreclr and corefx repos. Language support would be helpful at the level of numeric literals supporting new types initialization or constant definition and perhaps, however not strictly required for having this type available in framework, addition of new built in types to support new numeric types (i.e. float16, float128).

[IS4Code]

It depends on the relative performance of the type to other floating-point types. If float128 was a thing understood at least by the JITter, it could be optimized to rely on the features of the CPU and it would make sense to include it in the list of type keywords, but not if it would be just another decimal.

Language support in this case either means special understanding of operators and emitting a special signature, but that means modifying CIL to support float128, which isn't probably going to happen. So it would be just something like mapping quad to System.Quadruple and understanding const quad.

[Happypig375]

Cross-reference to corresponding issue at corefx: https://github.com/dotnet/corefx/issues/17267

[asyncawaitmvvm]

If you are creating big number types without matching trigonometry/log functions, please have a seat. Don't waste your time. Only a complete implementation is useful, otherwise it's a high school project.

@TheUnlocked The question is what would be the benefit of 128-bit number as part of the language? I mean, "nice to have" can be interpreted as "redundant/unnecessary" so you may want to cover how the language benefits from this.

IPv6 addresses and Guid literals, derp. Quicker static initialization. Combine this with something like constexpr and it would be just lordly.

[MovGP0]

There is only very few hardware (source: Wikipedia) that supports quadruple precision floats.

As such, (most of) the calculations would have to be implemented in software and very slow.

An dedicated library would be probably a better fit for such a type than it beeing an integral part of the framework.

[jnm2]

Though, it wouldn't be an integral part of the framework, because where would be the point?