[API Proposal/Question]: IFloatingPoint<TSelf> is totally base 2 IEEE 1985 oriented. We also need the basics for base10/decimal and other rational/fraction/real like numbers

[maxild]

Background and motivation

I know IFloatingPoint<TSelf> has this covered, but the interface is MUCH too big for other floating/fixed point/fractional numbers to support it.

We need a more basic (more generic) fractional number abstraction for all "real" like types (IEEE, decimal, Rational/Fraction/FixedPointNumber etc).

Functions like

• truncate
• floor
• ceil
• round

are concepts of all fractional numbers (aka fractions).

For floating point types (decimal and IEEE types) you could add

• nextUp (BitIncremenet in BCL)
• nextDown (BitDecrement in BCL)
• epsilon (why is epsilon defined as the smallest denormalized number in the BCL???, when it is defined as the distance between numbers in the [1,2), for base 2, and [1,10) , for base 10, segments in the academic litterature. The number important for relative errors and ulps (unit in last place, nextUp(x) - x, x > 0) around the number one)

I am guessing that System.Decimal (base 10) floating point numbers can be sorted (bit traversed), but I am not 100 pct sure, have to check the precise encoding used in Decimal.cs!?!

Before a more precise API proposal. Is this an oversight? Are you working on something without NaN, Denormalized/Subnormal, +/- infinity , +/-zero, and all the other IEEE 1985 related static methods that can be used with (supported by) for example System.Decimal? And maybe something without the many trigonometric and logarithmic functions?

API Proposal

API Usage

Alternative Designs

No response

Risks

No response

[ghost]

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

Issue Details

---

Background and motivation

I know IFloatingPoint has this covered, but the interface is MUCH too big for other floating/fixed point/fractional numbers to support it.

We need a more basic (more generic) fractional number abstraction for all "real" like types (IEEE, decimal, Rational/Fraction/FixedPointNumber etc).

Functions like

• truncate
• floor
• ceil
• round

are concepts of all fractional numbers (aka fractions).

For floating point types (decimal and IEEE types) you could add

• nextUp (BitIncremenet in BCL)
• nextDown (BitDecrement in BCL)
• epsilon (why is epsilon defined as the smallest denormalized number in the BCL???, when it is defined as the distance between numbers in the [1,2), for base 2, and [1,10) , for base 10, segments in the academic litterature. The number important for relative errors and ulps (unit in last place, nextUp(x) - x, x > 0) around the number one)

I am guessing that decimal (base 10) floating point numbers can be sorted (bit traversed), but I am not 100 pct sure, have to check!?!

Before a more precise API proposal. Is this an oversight? Are you working on something without NaN, Denormalized/Subnormal, +/- infinity , +/-zero, and all the other IEEE 1985 related static methods that can be used with (supported by) for example System.Decimal? And maybe something without the many trigonometric and logarithmic functions?

API Proposal

namespace System.Collections.Generic
{
    public class MyFancyCollection<T> : IEnumerable<T>
    {
        public void Fancy(T item);
    }
}

API Usage

// Fancy the value
var c = new MyFancyCollection<int>();
c.Fancy(42);

// Getting the values out
foreach (var v in c)
    Console.WriteLine(v);

Alternative Designs

No response

Risks

No response

Author:	maxild
Assignees:	-
Labels:	api-suggestion, area-System.Numerics, untriaged
Milestone:	-

[maxild]

@tannergooding 2 things.

1. System.Runtime.Experimental is at version 6.0.0 on nuget.org, but runtime is 6.0.1 as of today, so any project that has taken a dependency on this experimental feature cannot build if using 6.0.1 SDK. Is that correct/expected? (the "ref" assembly need to be loaded for the roslyn compiler to resolve the types, right? And I guess the versions need to match for this to work)....anyway I am seeing it build on SDK 6.0.0 and fail on SDK 6.0.1.
2. Are you going to enhance the design of the generic math number "arithmetic-operator/function-interfaces" for fractional (non integer) numbers? It is very IEEE 754 (1985) centric. See above.

[tannergooding]

@maxild, the first issue is #62840.

Are you going to enhance the design of the generic math number "arithmetic-operator/function-interfaces" for fractional (non integer) numbers? It is very IEEE 754 (1985) centric. See above.

It is intentionally IEEE 754 (actually 2008/2019, not 1985) centric.

Most of the operations, like transcedental functions, powers, logarithms, etc are not generally applicable. They only function "well" in the presence of support for things like NaN, Infinity, and even -0.0.

There may be a few tweaks or additional splits we can make for it to be a bit more fine grained and usable by other types, where applicable; and this is something I'm looking at; but I expect a large portion of this will be limited.

[tannergooding]

The latest design is updated to have IFloatingPoint and IFloatingPointIeee754

See the base document and additional changes covered in dotnet/designs#262