Let's illustrate this with an example:

new Fraction((BigInteger)double.MaxValue * 2, (BigInteger)double.MaxValue * 2, false)

I actually discovered the issue when one of my square roots turned up with a 0:

        var largeNumber = BigInteger.Pow(10, 309);
        var fraction = new Fraction(4 * largeNumber, largeNumber, false);
        var actual = fraction.Sqrt();  // is Fraction.Zero..

..but I would have likely caught it when testing the INumber interface and the TryConvertToChecked, TryConvertToSaturating and TryConvertToTruncating (which are the only functions that require special attention).

I've already started implementing the INumber<Fraction> interface (two weeks ago) but wanted to finish up the tests for my (still unpublished) PR for UnitsNet - when one of the tests failed (note this wasn't some static test concocted with an extreme value, it was an actual root-sum-of-squares that failed one of the tests in my own code-base)..

This is a pretty extreme example (it's a small niche of values for which this could happen) but still - here's an example for which the Fraction.FromDoubleRounded(double, bool) is throwing an exception:

Fraction.FromDoubleRounded(1.0 / (double.MaxValue - 100))

"BigInteger cannot represent infinity."

   at System.Numerics.BigInteger..ctor(Double value)
   at Fractions.Fraction.FromDoubleRounded(Double value, Boolean reduceTerms) Fraction.ConvertFromDouble.cs:line 213
   at Fractions.Fraction.FromDoubleRounded(Double value) in Fraction.ConvertFromDouble.cs:line 142

If you create the following fraction:
var test = Fraction.FromString("1488999520739749466415116125446/201514171878494548217495987785")

And get the Decimal and compare to online calculator

test .ToDecimal().ToString():
7.3890560989306502272304274605

Calculator: https://www.mathsisfun.com/calculator-precision.html
7.3890560989306502272304274605750078...

Calculator: https://keisan.casio.com/calculator
7.389056098930650227230427460575008

The last digit of the ToDecimal() should be rounded to 6 and not 5
Or am I wrong?

After #10 there is no need to depend on System.Runtime.Numerics

Currently, supported target frameworks are:

<TargetFrameworks>netstandard1.1;netstandard2.0;netstandard2.1;net45;net48;net5.0;netcoreapp3.1</TargetFrameworks>

However, these list of frameworks have two issues:

1. .NET Standard versions (1.1, 2.0, 2.1) already cover specific versions (like .NET 4.5), meaning it's an unecessary duplication.
2. Some of them (.NET Standard 1.1 and .NET Framework 4.5) cover unsupported versions.

Here are some references to understand what I am talking about:

• Link of the .NET implementation list
• Link of the dynamic table of versions covered by .NET Standard
• Link of the supported version of .NET Framework

Unecessary duplications

As you can see in the dynamic table of versions covered by .NET Standard:

• .NET Framework 4.5 is already covered by .NET Standard 1.1
• .NET Framework 4.8 is already covered by .NET Standard 1.1, 2.0 and 2.1
• .NET Core 3.1 is already covered by .NET Standard 1.1, 2.0 and 2.1
• .NET 5.0 is already covered by .NET Standard 1.1, 2.0 and 2.1

So you could simplify it like this:

<TargetFrameworks>netstandard1.1;netstandard2.0;netstandard2.1</TargetFrameworks>

Unsupported versions

The main question about this point is to know if why there is a direct reference to .NET Framework 4.5?
Because .NET Framework 4.5 is not supported anymore since January 12, 2016. Furthermore, even if .NET Framework 4.5.2 is still supported, its support will end on April 26, 2022 so it could be a good idea to anticipate and change this now.
Moreover, .NET Framework 4.5.2, 4.6 and 4.6.1 versions support will end on April 26, 2022 so, as you can see in the dynamic table of versions covered by .NET Standard, .NET Standard 1.1 will soon become useless. So, the final version of targeted frameworks should be:

<TargetFrameworks>netstandard2.0;netstandard2.1</TargetFrameworks>

I am raising this issue because I am using your librairy and if its covering unsupported framework versions, then it may lead to security issues that my clients are concerned about.
So I would be glad to open a PR to fix that and do whatever is necessary for you to release a new version with these modifications.

Hi, I have been fiddling around to see if and how your library could be extended to support the new INumber interface in C# so that something like this will work Enumerable.Range(1,100).Select(x=>new Fraction(1,x*x)).Sum(); // doesn't wort today as Sum is NOT generic. The result was: implementing INumber is pretty straight forward.
But I stumbled upon the issue that converting the result failed returning double.NaN.
I had a quick look into the code for the ToDouble conversion. I think this would give a better result - but also be slower:
private static readonly int maxDoubleDigits = (int)Math.Floor(Math.Log10(double.MaxValue) + 1);
private static readonly BigInteger maxDoubleAsBigInt = new BigInteger(double.MaxValue);

    public double ToDouble()
    {
        if (IsZero)
        {
            return 0;
        }
        // here result could already be larger as double.MaxValue - but then the result is double.NaN anyways...
       // this can be avoided by the calling code be first getting the full part of the fraction and then only consider the fractional part for double conversion
        var result = BigInteger.DivRem(_numerator, _denominator, out BigInteger remainder);
        // ToDo: is _denominator always positive?
        if (_denominator > maxDoubleAsBigInt )
        {
            // get the number of digits of the _denominator
            int digits = (int)Math.Floor(BigInteger.Log10(_denominator) + 1);
            // create a factor that will reduce the number of digits to what double can still handle
            BigInteger factor = BigInteger.Pow(10, digits - maxDoubleDigits + 1);
            // now divide remainder and _denominator by the same factor (which will cancel them out - algebraically speaking).
            // and then divide the "shortened" values 
            double fraction = (double)(remainder / factor);
            fraction /= (double)(_denominator / factor);
            return (double)result + fraction;
        }
        else
        {
            return (double)result + (((double)remainder) / ((double)_denominator));
        }

}

An alternative would be to add a function (BigInteger FullPart, double Fraction) ToDouble()....

Thanks for providing this great library!

I'm curious about the use cases you have for the FractionState and weather you intend to extend or reduce the support for Improper (i.e. non-reduced/non-normalized) Fractions moving forward.

Here are some observations we can make:

• there is currently no Improper option in the FractionState
• if no support for an explicitly Improper state is required, the field could be replaced by a the equivalent private readonly bool _hasBeenNormalized (which, if necessary, could still be used to return the original State property)
• most operations with fractions such as Multiply and Divide currently result in a Fraction with an IsNormalized state (regardless of the input state(s))
• an app that only uses Normalized fractions can be thought of as using an upgraded version of the double type where as one that operates with Improper fractions is (IMO) similar to operating on an upgraded version of the decimal type
• Operations with Normalized fractions are generally faster than the equivalent operations on Improper fractions
• it is possible to represent the two use cases (Fraction, NormalizedFraction) using separate types having an implicit conversion between one another (without the need for any _state fields)

Here is an example of what I mean by having decimal-like operators:

Console.WriteLine(0.10m * 0.10m); // Outputs: "0.0100" which is effectively "100/10000" (as in 10/100 * 10/100)
Console.WriteLine(0.100m / 0.10m); // Outputs: "1.0" which is effectively "10/10" (as in 100/1000 / 10/100)

Here's the output from the debugger

Would it be possible to add methods for Floor / Ceil / Round to round the Fraction to the nearest integer? This would be helpful for cases where for example you want to convert out afterwards to BigInteger or other integer types, but doing so at the moment will lose the information from the fractional value to allow for the appropriate rounding to be performed.

I know that for small enough values I could do the rounding via a decimal or double workaround step first, but when it comes to BigInteger there isn't a similar workaround. The use case I have is for an incremental game where I want to multiply very large BigInteger numbers by a fractional scalar, for example 1.3x. I'm doing this by performing the calculation as Fraction and then using .ToBigInteger afterwards, but this is always returning a floored integer and ideally I'd like to have the options of round or ceil as well, without having to write some clunky > or < comparison code.

Have a Square root function for a Fraction ever been on the table?
I need it from time to time.

Im guessing that it needs to be done in an iterative process and it might not be a easy as it sounds.
I could start working on it for this package if it would be accepted?

First of all, thank you for this project it works really great!

I wish for a contractor that takes 2 decimals

ex

Fraction value = new Fraction(4, 0.0254);
so it sets it to 40000 / 254

I tried using
Fraction value = Fraction.FromString("4/0.0254");
but that ignores the dot and returns a false result

Fraction.Zero.ToString("m") throws a divide by zero.

So google says (19/9) % (19/27) is 0.21019721019.

Yet this code (from latest nuget version):

            var a = new Fraction(19, 9);
            var b = new Fraction(19, 27);

            var mod = a % b;
            if (mod == 0) {
                Console.WriteLine("Bug");
            }

Gives:

I am looking into creating more math operations for this library however i am hitting a wall where if I do too many calculation on a Fraction its 'size' gets too large and slows down the calculation.
Many of the math operations will have a fixed Precision so it doesn't make much sense if the fraction can grow forever.

ex.
1071283/28187739 (decimal: 0.0380052830771563 )

Reduce precision so the largest BigInt is 4 -->
107/2815 (decimal: 0.038010657 )

I have looked into creating a method that does this but I cant seem to find a good way.
Do you have an idea for this?

I think there is a regression (but I cannot find where the change occurred):

In v7 this used to work:

public static bool TryParse(string? valueString, NumberStyles parseNumberStyles, IFormatProvider? formatProvider, out QuantityValue quantityValue)
{
    if (Fraction.TryParse(valueString, parseNumberStyles, formatProvider, out Fraction fraction))
    {
        quantityValue = new QuantityValue(fraction);
        return true;
    }

    quantityValue = default;
    return false;
}

Error (active) CS8604 Possible null reference argument for parameter 'value' in 'bool Fraction.TryParse(string value, NumberStyles numberStyles, IFormatProvider? formatProvider, out Fraction fraction)'.

I've messed up one of the edge cases in the implementation of #23

Support for NaN and Infinity

Hey,
I've been digging into the code and I think we can add support for NaN and +/- Infinity. Here's what I'm thinking:

1. Update GetReducedFraction(..) to return 0/0 (NaN) for 0 in the numerator and denominator. Right now, it's returning Zero.
2. For a positive numerator and 0 in the denominator, return +1/0 (+Inf).
3. For a negative numerator and 0 in the denominator, return -1/0 (-Inf).

We might need to tweak FractionState to {Zero, Unknown, Normalized} to avoid default(Fraction) being NaN. Also, in that case, Reduce() should check for FractionState.Zero and return a true Zero (0/1).
There might be a few more checks needed (like in the constructor from double), but I think it's doable.

I'm ready to make these changes and submit a PR if you're on board with this.

Let me know what you think!

Hi,
I've started to use this package but it's missing Reciprocal method. I can add it with extension method but that doesn't have access to private constructor of Fraction.

I've created a PR adding the method and tests.
#21

One got away...

Present in versions 8.0.0 & 8.0.1.

Here is the summary of the tests that are failing in the current code base (a total of 107 per framework):

1. Parsing_a_fraction_from_a_long_decimal_string_with_specific_number_style (23 tests)

• Should_not_work_with_groups_in_the_middle("123456789987654321.,123456789987654321")
• Should_not_work_with_groups_in_the_middle("123456789987654321.123456789,987654321")
• Should_return_the_expected_value_when_the_string_is_valid("1234,56789987654321.-",Any,) // all strings with the +/- sign on the right side
• Should_return_the_expected_value_when_the_string_is_valid(" (.1) ",Any,) // all strings with "(..)" as negative pattern

2. Same issues are repeated with the scientific notation
3. All currency formats are affected as well
4. When parsing a string with a culture where the symbols are not the standard length (e.g. having "minus" instead of "-" for the negative sign).

When parsing a string with the sign / currency symbol to the right side, the results are incorrect due to the fact that the symbols to the right do not contribute to the number of decimals in the denominator:

The_result_should_be_minus_7_over_2("3,5-") Failed: Expected object to be equal to -7/2, but found -7/20.
Expected object to be equal to -7/2, but found -7/20.
   at FluentAssertions.Execution.LateBoundTestFramework.Throw(String message)
   at FluentAssertions.Execution.AssertionScope.FailWith(Func`1 failReasonFunc)
   at FluentAssertions.Numeric.ComparableTypeAssertions`2.Be(T expected, String because, Object[] becauseArgs)
   at Fractions.Tests.FractionSpecs.FromString.When_creating_a_fraction_from_minus_3_5_with_German_culture.The_result_should_be_minus_7_over_2(String value) in C:\Users\galin\source\repos\Fractions-fork\tests\Fractions.Tests\FractionSpecs\FromString\Method_FromString.cs:line 142

A PR is coming in a bit..

Here and elsewhere in Microsoft and Stackoverflow forums, the advice on approximating the rational number one-tenth can be approximated in binary notation by .'0011', that is .001100110011 and so on. But it should read as .0'0011' or .0001100110011 and so on. I've checked this manually for the first 9 binary places to get 51/512ths, which is close enough for me to put my correction. The current wording approximates one-fifth, not one-tenth.

Consider the following scenario:

Normally this should have been true for the Equals as well, but I think this illustrates the issue better.

This problem stems from the fact that the sign of the fraction is not handled here

    public static Fraction Reciprocal(Fraction fraction) =>
        new Fraction(fraction.Denominator, fraction.Numerator, fraction.State);

According to GetReducedFraction a Normalized fraction should have it's signs normalized:

            if (denominator.Sign == -1) {
                // Denominator must not be negative after normalization
                numerator = BigInteger.Negate(numerator);
                denominator = BigInteger.Negate(denominator);
            }

I'd be willing to create a PR, but I was hoping that we could merge my "cleanup" of the test project first, if you don't mind..