System.Numerics work planned for .NET 8 #79004
Comments
dakersnar
added
Epic
|
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsThis 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. SummaryDuring .NET 8, we will be introducing three new IEEE floating-point types to 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 8Quality
Enhancements / New APIs
Performance
|
|
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. |
|
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! |
|
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.
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. |
|
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: 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. |
|
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 COBOL itself does not provide support for anything from 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 |
|
@KTSnowy I recommend summarizing our discussion in the API proposal thread #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. |
|
If |
|
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 |
ghost
locked as resolved and limited conversation to collaborators
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, andDecimal128. 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 existingdecimalprimitive 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
pow(x, 1)#12139Enhancements / New APIs
This API proposal will be redone by an area owner
Performance
The text was updated successfully, but these errors were encountered: