`Unit.equals` throws an exception when using Fractions, whilst `math.equal` works as expected

[josdejong]

From #2915

I parameterize the mathjs like this :

const config: math.ConfigOptions = {
  number: "Fraction",
};
const math: MathJsStatic = create(all, config);

I create units like this :

math.createUnit('rotation', {definition: '360 deg', aliases: ['tour','tr']})

I try to do this :

const a = math.unit(360, "deg");
const b = math.unit(1, "rotation");
expect(b.equals(a));

And i have this error :

TypeError: Cannot implicitly convert a number to a Fraction when there will be a loss of precision (value: 6.283185307179586). Use function fraction(x) to convert to Fraction.

Any idee ??!
tks.

Apparently the method Unit.equals internally tries to convert the Fraction into a number. For some reason the function math.equal(a, b) does work as expected whereas b.equals(a) throws this error.

It sounds like this is a solvable bug. Anyone able to look into this? Help would be welcome.

[brunoSnoww]

okay, so after some debugging I think the problem comes from precision when converting the unitary degree to a fraction. I've come up with the following:

Because we're using the Fraction parametrisation, at the time we compare such values, we end up in the following piece of code ( inside typed.js ):

  from: 'number',
  to: 'Fraction',
  convert: function (x) {
    if (!Fraction) {
      throwNoFraction(x)
    }
   const f = new Fraction(x)
   if (f.valueOf() !== x) {
      throw new TypeError('Cannot implicitly convert a number to a Fraction when there will be a loss of precision ' +
        '(value: ' + x + '). ' +
        'Use function fraction(x) to convert to Fraction.')
    }
    return f
 }

With 'f' and 'x' given by:

So the condition

if(f.valueOf() !== x){
   ...
}

evaluates to true because f.valueOf() and x still differ by a small margin, and therefore the mentioned error is thrown. But even if this expression evaluates to false, we end up in this final comparison inside equalScalar.js

 'Fraction, Fraction': function (x, y) {
    return x.equals(y)
 },

Where the 'equals' function used comes from this line from fraction.js. And when the such function is called with the below arguments, it returns false:

What I came up locally to get the right result is to instead use an equality based on if the modulo of difference is less than the default epsilon. Do we use this solutions in order to get it right ? Any thoughts ?

[josdejong]

Testing this again I now get the same error in both cases a.equals(b) and math.equal(a, b), that makes much more sense at least.

The cause is indeed the error that warns about losing precision. The error is thrown because we try to compare a Fraction with a number and there is indeed an inaccuracy when converting the number to a Fraction.

I think we can change the strict test if (f.valueOf() !== x) into for example if (!nearlyEqual(f.valueOf(), x, epsilon)). That way we use the same logic as in other parts of the code base. What do you think Bruno?

[maverick56]

I don't understand why we compare a fraction with a number...
In this example, both are fraction. isn't it ?

I'm surpise we need to use an epsilon to compare two fractions ... they are exact numbers, comparison should be exact. I guess.

[josdejong]

The reason is that in the following code the unit deg is created with a value being a number (since deg is defined as a number internally), and units rotation are created as a Fraction since they have a value defined as Fraction since mathjs was configured with fractions at the moment the unit was created.

const math = create(all, { number: 'Fraction' })
math.createUnit('rotation', {definition: '360 deg', aliases: ['tour','tr']})

const a = math.unit(360, 'deg');    // a has a value being a number since deg is defined as number
const b = math.unit(1, 'rotation'); // b has a value being a Fraction since rotation is defined as Fraction
expect(b.equals(a));

[maverick56]

OK thanks, this is clear !

[josdejong]

This is solved now by extending the function math.fraction, math.bignumber, and math.number with support for units. So, if there is a conflict, you can solve it yourself. Also, the docs now have a section explaining this in more detail.