search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.17k stars 4.72k forks source link

System.Numerics work planned for .NET 8 #79004

Closed dakersnar closed 1 year ago

dakersnar commented 1 year ago

This is a work in progress as we develop our .NET 8 plans. This list is expected to change throughout the release cycle according to ongoing planning and discussions, with possible additions and subtractions to the scope.

Summary

During .NET 8, we will be introducing three new IEEE floating-point types to System.Numerics: Decimal32, Decimal64, and Decimal128. These types have been requested before by community members and are being added to the C23 standard, so we are excited to bring them to .NET. These types will not be replacing the existing decimal primitive type, which will continue to be fully supported. They will instead exist in addition to provide users performant and IEEE-compliant decimal floating-point implementations.

Beyond that major theme, we will invest in quality, enhancements and new APIs, plus performance improvements. This is an ambitious set of work, so it's likely that several of the items below will be pushed out beyond .NET 8. It is also likely additional items will be added throughout the year.

Planned for .NET 8

Quality

Enhancements / New APIs

Performance

ghost commented 1 year ago

Tagging subscribers to this area: @dotnet/area-system-numerics See info in area-owners.md if you want to be subscribed.

Issue Details
**This issue captures the planned work for .NET 8. This list is expected to change throughout the release cycle according to ongoing planning and discussions, with possible additions and subtractions to the scope.** ## Summary During .NET 8, we will be introducing three new IEEE floating-point types to `System.Numerics`: `Decimal32`, `Decimal64`, and `Decimal128`. These types have been requested before by [community members](https://github.com/dotnet/runtime/issues/69777) and are being added to the [C23 standard](https://en.cppreference.com/w/c/23#New_language_features), so we are excited to bring them to .NET. These types will not be replacing the existing `decimal` primitive type, which will continue to be fully supported. They will instead exist _in addition_ to provide users performant and IEEE-compliant decimal floating-point implementations. Beyond that major theme, we will invest in quality, enhancements and new APIs, plus performance improvements. This is an ambitious set of work, so it's likely that several of the items below will be pushed out beyond .NET 8. It is also likely additional items will be added throughout the year. ## Planned for .NET 8 ### Quality - [ ] https://github.com/dotnet/runtime/issues/12139 - [ ] https://github.com/dotnet/runtime/issues/70460 - [ ] https://github.com/dotnet/runtime/issues/73150 - [ ] https://github.com/dotnet/runtime/issues/74758 ### Enhancements / New APIs - [ ] https://github.com/dotnet/runtime/issues/69777 This API proposal will be redone by an area owner - [ ] https://github.com/dotnet/runtime/issues/75431 ### Performance - [ ] https://github.com/dotnet/runtime/issues/61785 - [ ] https://github.com/dotnet/runtime/issues/65189 - [ ] https://github.com/dotnet/runtime/issues/65191
Author: dakersnar
Assignees: -
Labels: `Epic`, `area-System.Numerics`, `Team:Libraries`
Milestone: 8.0.0
KTSnowy commented 1 year ago

Looking forward to use the new IEEE floating-point types. Our C# project depends on those types and we're currently Pinvoking a C library to use them, which is not ideal for portability and makes the build process much more complex.

I'd like to help with this if possible. Let me know if there's anything I can do.

dakersnar commented 1 year ago

Hi @KTSnowy, glad to hear you are looking forward to using the types! Do you mind sharing a little bit more about how you plan on using them? We are currently trying to nail down what aspects of this project we want to prioritize for .NET 8, as we likely won't be able to commit to it all in one release cycle. For example, some of the "recommended" IEEE functions (advanced math stuff like the trig functions, exp functions, etc) might be out of scope. Additionally, we haven't totally decided which of the three types we should prioritize for .NET 8 (whether it be one, two, or all three). We would love your perspective as a user!

KTSnowy commented 1 year ago

Hi @dakersnar, we are developing a free and open source COBOL compiler for dotnet ( Otterkit ) and COBOL itself depends heavily on decimal arithmetic, which includes the Decimal128 type that is required by the COBOL standard. We currently PInvoke calls to the mpdecimal library to provide the Decimal128 functionality needed for the compiled code on dotnet.

Additionally, we haven't totally decided which of the three types we should prioritize for .NET 8 (whether it be one, two, or all three).

I would recommend supporting the Decimal128 format first, it would be more useful than the Decimal32 and Decimal64 formats in real world scenarios involving monetary values. Also, the main complaints I have with the current C# decimal is that it is not precise enough (compared to IEE Decimal128), doesn't match the 34 digit size of the Decimal128 format, and it is not a standard decimal implementation.

I'm looking forward to being able to use these types in our compiler.

dakersnar commented 1 year ago

Hi @KTSnowy, thanks for the details.

Out of curiosity, does that project require support for any of the "recommended" IEEE functionality exposed in the following C# interfaces: IExponentialFunctions, IHyperbolicFunctions, ILogarithmicFunctions, IPowerFunctions, IRootFunctions, ITrigonometricFunctions?

These are currently the things we think might be out of scope due to the high implementation cost. However, if we have evidence that this functionality is needed by users, we can reevaluate what we aim to ship.

KTSnowy commented 1 year ago

Hi @dakersnar, COBOL provides some of those math functions with its intrinsic functions, and implementing those is required by the COBOL standard. The mpdecimal library that we're using unfortunately does not completely provide that functionality so we had to implement it ourselves in the runtime library (mpdecimal doesn't provide trigonometric functions).

Because of the COBOL standard's requirements we would require support for the IExponentialFunctions, ILogarithmicFunctions, IPowerFunctions, IRootFunctions, ITrigonometricFunctions.

COBOL itself does not provide support for anything from IHyperbolicFunctions so we would not require support for it.

Having those directly in C# would be awesome, we would be able to provide that COBOL functionality in our compiler in a way that is compatible with C#, and might make it easier to implement our COBOL <=> C# Bridge in the future.

I'm not sure if I can request any extra functionality for this, but if possible, would there be a way to support a ToSpan and a FromSpan methods for these types? Otterkit heavily depends on Span<byte> and Memory<byte> for every COBOL data type, every type is implemented using UTF8-encoded Spans.

dakersnar commented 1 year ago

@KTSnowy I recommend summarizing our discussion in the API proposal thread https://github.com/dotnet/runtime/issues/81376. That is ultimately where discussion is going to happen on what we want to commit to for .NET 8 and beyond. I would:

I can't make any promises for what we end up approving or committing to, but sharing a usage scenario is a good way to motivate this work.

colejohnson66 commented 1 year ago

If Decimal128 support is being added, shouldn't binary128 also be implemented (possibly as System.Quad)?

tannergooding commented 1 year ago

Closing as this was a meta issue.

The core work got completed. Various non-critical bits were pushed out or not worked on.

Most notably, The IEEE 754 decimal ended up being pushed out