Simplify `sqrt(1)` to `1`

[samuela]

From https://discourse.julialang.org/t/why-wont-symbolics-jl-simplify-sqrt-1-to-1/65921,

@variables x
sqrt(cos(x)^2 + sin(x)^2) |> simplify

gives me sqrt(1). Why isn't this reduced to simply 1?

OTOH

sqrt(0*x+1) |> simplify

reduces to 1, no problem.

┆Issue is synchronized with this Trello card by Unito

[samuela]

On a related note, how does one add custom rules to the Symbolics.jl simplifier? I was not able to find any pointers in the docs.

[dlfivefifty]

I had a similar issue that was fixed #178

Perhaps looking at the fix would help?

[samuela]

Also sqrt(x^2) |> simplify gives me sqrt(x^2).

[dlfivefifty]

Are you expecting abs(x) ?

[samuela]

Are you expecting abs(x) ?

Yes, although this is not nearly as problematic for me as the sqrt(1) issue.

[dlfivefifty]

The solution would also be much more complicated...

If you look at the fix for the sign(1) example it should be clear what needs to be done to solve this issue

[samuela]

It looks like the #178 changes were reverted in 9843a0f which gives me pause.

Also FWIW sign(cos(x)^2+sin(x)^2) |> simplify returns sign(1) as of [0c5d862f] Symbolics v2.0.0. So I'm not sure that the sign(1) issue is fixed anymore.

[samuela]

As a meta-comment, why are these fixes not as simple as defining a new SymbolicsUtils.@rule and adding it to the standard set of @rules?

[dlfivefifty]

@YingboMa care to comment about what's going on re: sign(1)?

[YingboMa]

Simplify doesn't behave exactly like evaluation.

julia> 0*x+1
1

already evaluates to 1. So sqrt(0*x+1) is just evaluating sqrt(1). But cos(x)^2+sin(x)^2 simplifies to 1. Currently, we don't evaluate the function by default if there are concrete numbers, thus the discrepancy.

[samuela]

I'm a little bit confused by that example because OTOH 0*x + 1 |> typeof gives me Num, so it's not quite the same as vanilla floating point Julia evaluation either. Is it correct to think of there being three modes of evaluation/simplification: standard Julia evaluation of floating point types (etc), evaluation of Num types implemented via multiple dispatch, and Num canonicalization via simplify?

What would be necessary to fix the sign(1) and sqrt(1) behavior?