Square roots are simplified to decimals

[omelancon]

The function simplify always evaluates sqrt instead of leaving some forms such as sqrt(2) unchanged.

To Reproduce

Simplify the following:

math.simplify('sqrt(2)')

The result is a ConstantNode with value 1.4142135623730951, but I expected a FunctionNode where the sqrt function was not applied.

When its argument is an exact, it feels like sqrt should only simplify to a constant if the result is an exact integer. This would be akin to divide that simplifies fractions, but does not apply division if the result is not an integer.

[josdejong]

We can discuss how to improve on this. Let's do that in the discussions section.

[josdejong]

Right now, simplify will indeed evaluate functions when possible, also when resulting in a decimal result. There is an option exactFractions than can be useful to output a fraction like 2/5 instead of 0.4, but that is not helpful for irrational numbers.

I can imagine that we built a new option that counts the number of digits after a calcuation, and if that more than a configured maximum, leaves that part of the expression unevaluated. For example abs(-1) is ok to simplify to 1, and 0.2 + 0.01 should be simplified to 0.21, but sqrt(2) should not be simplified to 1.4142135623730951. More complex: 1/3 should not be simplified to 0.3333333333333333, but if it is part of an expression 1/3+2/3, we do want to calculate the end result, so it is not enough to look locally.

[omelancon]

Thanks for you answer! 😃

That sounds like a good start, I tried on a few input and it feels like this would give the expected result. Checking for decimals works well with the fact the root of an integer is always either an irrational or an integer.

math.simplify('(1 + sqrt(3))/ 2') // would not be simplified because no term can be simplified further without introducing decimals
math.simplify('(1 + sqrt(4))/3') // would be simplified to 1 after sqrt(2) is simplified to 2
math.simplify('(1 + sqrt(9))/3') // would be simplified to 4/3 after sqrt(9) is simplified to 3
math.simplify('1/sqrt(2)') // would not be simplified because sqrt(2) would introduce decimals.

Some cases would not be covered, so maybe a rule should attempts to distribute the square root on multiplication and division and keep the result with distribution if that allowed simplification in either operand:

math.simplify('sqrt(1/9)') // should simplify to 1/3
math.simplify('sqrt(4 * x)') // should simplify to 2 sqrt(x)
math.simplify('sqrt(2/3)') // should not distribute because neither sqrt(2) nor sqrt(3) simplifies

Maybe also introduce a case where simplifying to a decimal number is allowed if the argument already contains a constant that exceeds the decimal limit?

math.simplifiy('sqrt(0.1234567)') // should probably simplify anyway

I only spent about ten minutes looking at simplify.js so I am mostly listing examples for now. I don't know how easy that would be to implement.

[josdejong]

Thanks for your inputs!

Anyone interested in improving simplify with some of these ideas? Help would be welcome.

[nickkolok]

The upcoming journey seems to be long, very long...
Looks like we should start with introducing a special atom in simplify rules that corresponds only to integers (no matter to what of them: 'usual' JS ones, BigInts etc). For a constant, we have c1, c2 etc; for integers, let's assume m1, m2 etc.

Then, let us state that some operations on integers are absolutely safe. These are: addition, division, multiplication. Then the corresponding simplification rules are:

safeIntegerSimplification = [
	{ l: "m1+m2",   r: "forceSimplifyConstants(m1+m2)" },
	{ l: "m1-m2",   r: "forceSimplifyConstants(m1-m2)" },
	{ l: "m1*m2",   r: "forceSimplifyConstants(m1*m2)" },
];

function forceSimplifyConstantsInNode(node){
	if(node.fn && node.fn.name === 'forceSimplifyConstants'){
		return math.simplifyConstant(node.args[0]);
	}
	for(let i = 0; node.args && i < node.args.length; i++){
		node.args[i] = forceSimplifyConstantsInNode(node.args[i]);
	}
	return node;
}

Now we can deal with fractions, e.g. {l: 'm1/m2 + m3/m4', r: '(m1*m4 + m3*m2) / (m2*m4)'}

The problem sounds classic and should have been solved somehow - e.g. in Maxima.

[nickkolok]

I did a completely other attempt, my it didn't work for me (it runs forever). Maybe someone can find anything useful in it :)

let mathjsRules = {};
mathjsRules.simplifyCarefully = [
	{ l: 'ce1', r: 'carefullySimplifyConstants(ce1)', repeat: false },
	mathjs_helpers.carefullySimplifyConstantsInNode,
];

let mathjs_helpers = {
	carefullySimplifyConstantsInNode : function(node){
		if(node.fn && node.fn.name === 'carefullySimplifyConstants'){
			let simp = math.simplifyConstant(node.args[0]/*,{exactFractions:true}*/);
			if (simp.toTex().length < 10){
				return simp;
			}
			//Failure!
		}
		for(let i = 0; node.args && i < node.args.length; i++){
			node.args[i] = mathjs_helpers.carefullySimplifyConstantsInNode(node.args[i]);
		}
		return node;
	},
};

let e1 = math.parse('1+2+sqrt(3)+sqrt(4)');
math.simplify(e1).toTex();
math.simplify(e1,mathjsRules.simplifyCarefully, {repeat:false}).toTex();

[josdejong]

Thanks for looking into this @nickkolok!

[nycos62]

Hello, so, is there a way currently to keep roots instead of decimals with simplify ?
math.simplify('((1+sqrt(5))/2)^2').toTex(); //=2.6180339887... instead of (3+sqrt(5))/2 or 1+Phi

[josdejong]

There is no option for that, but you could always alter the rules. Or you could replace the numbers with a symbol, then simplify, and in the end replace the sybols with their value again.

[dcaillibaud]

At this point, what's the best way to achieve the initial goal : do not simplify sqrt(2) but keep all other simplifications ?

I saw the rule named simplifyConstant in simplify.rules, but filtering it cause others troubles (it's responsible of '1+1 => 2' simplification)

I'm wondering about implementing a custom simplify with my own parser and

• on non-sqrt nodes call simplify
• on sqrt nodes call simplify only on argument, then if result is constant
  • if perfect square return constant node with square root as int
  • if constant node replace it with symbol

and after all, replace all symbols with their value

Is there a better way ? making a customSimplifyConstant wrapper of simplifyConstant to replace it in rules (with perhaps two different wrappers for first call and second call, because simplifyConstant appears twice in rules list) ?

[dcaillibaud]

I tried something like

import { fraction, isConstantNode, isFunctionNode, parse, simplify, ConstantNode } from 'mathjs'
import { almostEqual } from 'src/lib/utils/comparators'

let areRulesPatched = false

const squares = []
while (squares.length < 21) {
  const n = squares.length
  squares.push(n * n)
}

function simplifySqrt (node) {
  try {
    // On regarde si l’argument est un carré parfait après simplification/évaluation
    const sqrtArg = node.args[0]
    if (isConstantNode(sqrtArg)) {
      const value = sqrtArg.evaluate()
      if (typeof value === 'number' && value > 0) {
        const n = Math.round(value)
        const r = Math.round(Math.sqrt(n))
        if (almostEqual(value, n)) {
          // n est entier
          if (almostEqual(r * r, n)) {
            // carré parfait
            return new ConstantNode(r)
          }
          let a = 1
          let b = n
          for (let i = Math.max(squares.length - 1, r); i > -1; i--) {
            const i2 = squares[i]
            if (b % i2 === 0) {
              b = b / i2
              a = a * i
            }
          }
          if (a > 1) {
            return parse(`${a}sqrt(${b})`)
          }
          // l'entier ne peut pas être simplifié, on laisse intact
          return node
        }

        // test p/q avec p & q entiers
        const frac = fraction(value)
        const p = Number(frac.n)
        const q = Number(frac.d)

        if (p >= 0 && Number.isInteger(p) && Number.isInteger(q)) {
          const rp = Math.round(Math.sqrt(p))
          const rq = Math.round(Math.sqrt(q))
          if (rq * rq === q) {
            if (rp * rp === p) {
              return parse(`${rp}/${rq}`)
            }
            // reste un radical au numérateur
            return parse(`sqrt(${p})/${rq}`)
          }
        }
      }
    }
  } catch (error) {
    console.error(error)
  }

  // pas de simplification
  return node
}

function patchSimplifyConstant () {
  if (areRulesPatched) return console.error(Error('rules have been already patched'))
  areRulesPatched = true
  const rules = simplify.rules

  const simplifyConstant = rules.find(r => typeof r === 'function' && r.name === 'simplifyConstant')
  if (!simplifyConstant) {
    console.warn('Rule simplifyConstant not found, rules patch ignored')
    return
  }

  const customSimplifyConstant = function customSimplifyConstant (node) {
    if (isFunctionNode(node) && node.fn.name === 'sqrt') {
      const sqrtArg = node.args[0]
      if (isConstantNode(sqrtArg)) {
        return simplifySqrt(node)
      }
      // sinon il faut simplifier l'argument
      const simplifiedArg = simplifyConstant(sqrtArg)
      if (simplifiedArg !== sqrtArg) {
        const clone = node.clone()
        clone.args = [simplifiedArg]
        if (isConstantNode(simplifiedArg)) {
          return simplifySqrt(clone)
        }
        // sinon y'a rien à faire de plus
        return clone
      }
    }
    return simplifyConstant(node)
  }

  simplify.rules = simplify.rules.map(r => {
    return typeof r === 'function' && r.name === 'simplifyConstant'
      ? customSimplifyConstant
      : r
  })
}

function customSimplify (expr, simplifyOptions) {
  if (!areRulesPatched) {
    patchSimplifyConstant()
  }
  return simplify(parse(expr), {}, simplifyOptions)
}

It works to preserve sqrt(2) or simplify sqrt(4) -> 2 but fails on sqrt(12) (returns 3.4641016151377544 instead of 4 sqrt(3) expected) or (1-sqrt(2))/3 which returns -0.8047378541243649 instead of original unchanged.

There is two uses of simplifyConstant in simplify.rules, is it possible to replace the sqrt arg by a symbol on the first use (of my customSimplifyConstant) and then replace the symbol by the original node on the second one ?

[gwhitney]

This is not a bad try. Some thoughts/advice:

1. I would recommend not patching the standard rules, but rather calling simplify with a modified copy of the standard rules (it takes a rule set as an argument.
2. I don't see why sqrt(12) is not simplifying to 2sqrt(3) as you have code to try to check for this. More generally, though, there should be a function to find the largest square divisor of an integer, so you don't have to rely on a table of the first 21 squares. (I'm not saying there is such a function now in mathjs, but it would be good to have the functions needed to do this anyway.) Anyhow, to debug this, I would try (a) calling your simplifySqrt() directly and see if that works. If so, I would (b) call your custom simplify with the consoleDebug option, so you can see what it is doing step-by-step.
3. When you check fractions, which is a good idea, I would leave the numerator and denominator as bigints, since you are doing integer arithmetic here anyway. But you should probably respect the exactFractions configuration parameter, and only try to convert into fractions if it is true.

Obviously one key step is getting simplifyConstant to leave sqrts alone, I will make a separate comment on that.

[gwhitney]

Oh another comment: probably safer (avoid weird syntax coincidences) and quicker to make your own multiply node, rather than calling parse in the middle of simplify, to create the result of sqrt(12) -> 2*sqrt(3).

[gwhitney]

One thought on the specific case of sqrt:

• This idea clearly interacts with proposals (for example see the later part of Extend simplify with rules for `log(e)=1`, `sin(pi)=0`, etc #2725) to convert all sqrt(expr) to (expr)^1/2 before going through the main simplification rules, and then at the end reverting any remaining (expr)^(1/2) back to sqrt(expr). I am not sure whether these two efforts would help each other or be at odds, but it would be good to try them in conjunction before settling on a solution for either, in case they either interact badly, or in case doing one actually solves the other, for example.

More general thoughts on function-specific simplification in general:

• See also Enhance simplify so that it can be directed to only make mathematically exact simplifications? #3372 and Custom Simplify Constant Rule Exceptions? #3273, which are closely related and show that these concerns are not limited to sqrt.
• Note that functions that comb through the syntax tree are not necessarily needed; the simplify rules have pretty powerful pattern-matching capability. As a very simple example, there is already a rule log(e) -> 1. So you can just add rules like sqrt(n1)*sqrt(n2) -> sqrt(n1*n2) which could be helpful (although probably better to go through changing sqrt to a power expression, since all of those term-gathering rules are already there for dealing with exponents).
• Clearly we do need a way to control unwanted inexact evaluations in simplifyConstant. Here are two not-necessarily-exclusive ways that might work in the current framework:

1. We already have "contexts" in which function symbols have properties like "commutative". Add a property like "evaluatable" that defaults to true, and make simplifyConstant check that a function symbol is "evaluatable" before calculating its value on a constant. Now run simplify with a constant in which sqrt or log is has the property {evaluatable: false} and bam, simplifyConstant stops messing with those function calls.
2. Have a simplification option flag like exactFunction that has been suggested elsewhere, such that if the input to a function is an exact numerical representation (bigint or Fraction, as opposed to an approximate floating-point representation, like number or BigNumber), but the output is not an exact numerical representation, then it does not perform that simplifyConstant step.

Now, none of the above principles then allows things like sqrt(12) -> 2sqrt(3) or log(x^2) -> 2log(x), so indeed, additional knowledge of the behavior of these functions will need to be added, and some of those rules will have to be function-based rules because of things like having to examine the argument of sqrt for perfect squares internally and other patterns. For example, we likely want to simplify sqrt(4*n) to 2*sqrt(n) and maybe even sqrt(-1) to i.

Hope these ideas help a future implementor here.

[dcaillibaud]

Thanks for all your suggestions. I finally had what I wanted, but it's really complicated

• before the first simplifyConstant call on the pipeline, simplify sqrt then replace them by a SymbolNode
• before the second call of simplifyConstant on the pipeline, check if there is any OperatorNode pow applied to our SymbolNode, if any restore sqrt, simplify, mask
• after the whole simplification, restore our sqrt

You can see it there, but it's probably still buggy !

it works with this unit test, feel free to suggest more complicated expression to test.

I did others tries before, as you can see on this history

But all this is a really complicated workaround, an implementation of your suggesion (property evaluatable and exactFunction option) would be a better solution, even if we have then to had some rules to simplify arguments of sqrt or log.

[nycos62]

don't forget forms like cbrt(27) or nthroot(4,2) or 4^(1/2) or pow(4,1/2)

[gwhitney]

Yes, I agree that a comprehensive attack on the sorts of behavior discussed here and in the references above need to address all of these. I strongly suspect that such a strategy will need to unify all of the above into (expr1)^(expr2) forms, simplify those carefully according to the options specified (such as respecting putative exactFunction or evaluatable properties), and then finally restore some customary, comfortable presentation equivalences (such as (expr)^(1/2) -> sqrt(expr), (expr)^(1/3) -> cbrt(expr), etc.