bug in simplify_radical

[zimmermann6]

the documentation of simplify_radical says:

sage: x.simplify_radical?
...
       Simplifies this symbolic expression, which can contain logs,
       exponentials, and radicals, by converting it into a form which is
       canonical over a large class of expressions and a given ordering of
       variables

however if indeed it is able to recognize zero:

sage: a=1/(sqrt(5)+sqrt(2))-(sqrt(5)-sqrt(2))/3
sage: a.simplify_radical()
0

it does not return a canonical expression:

sage: a1=1/(sqrt(5)+sqrt(2))
sage: a2=(sqrt(5)-sqrt(2))/3
sage: a1.simplify_radical()
1/(sqrt(2) + sqrt(5))
sage: a2.simplify_radical()
-1/3*sqrt(2) + 1/3*sqrt(5)
sage: (a1-a2).simplify_radical()
0

Apply only attachment: 8497_fix_doc.patch

CC: @kcrisman @burcin @jasongrout @mwhansen

Component: calculus

Keywords: simplify, radical, sqrt

Author: Paul Zimmermann, Jeroen Demeyer

Reviewer: Burcin Erocal

Merged: sage-4.7.2.alpha4

Issue created by migration from https://trac.sagemath.org/ticket/8497

[zimmermann6]

comment:1

Note the original question posed to me was: how to multiply say 1/(1+sqrt(2)+sqrt(3)) by the
conjugate expression?

[mwhansen]

comment:2

This is the full docstring from Maxima:

Simplifies expr, which can contain logs, exponentials, and radicals, by converting it into a form which is canonical over a large class of expressions and a given ordering of variables; that is, all functionally equivalent forms are mapped into a unique form. For a somewhat larger class of expressions, radcan produces a regular form. Two equivalent expressions in this class do not necessarily have the same appearance, but their difference can be simplified by radcan to zero.

    For some expressions radcan is quite time consuming. This is the cost of exploring certain relationships among the components of the expression for simplifications based on factoring and partial-fraction expansions of exponents. 

Perhaps we should include this

[zimmermann6]

comment:3

Perhaps we should include this

yes (unless of course upstream finds a way to get a real canonical form).
And maybe adding an example showing the difference when checking for 0.

[kcrisman]

comment:5

What is really going on here is that simplify_radical uses radcan under the hood, which treats things as symbolic expressions, not functions, and just chooses a branch - consistently, but arbitrarily. At least I think that is what is going on here. See the Maxima list thread starting here.

[zimmermann6]

comment:6

then should we simply change the documentation, in saying that simplify_radical gives a
canonical expression for zero, but if a and b are two identical expressions, they might not
be "simplified" to the same expression?

Paul

[kcrisman]

comment:7

You are correct. I was just updating, though, at this point.

It gets worse, because some expressions that are definitely not 1 will simplify to just 1, because that is the branch that was picked. See this ask.sagemath.org question, and Fateman's accurate response.

[zimmermann6]

comment:8

then I suggest to simply remove this function from Sage, unless there are ideas how to fix it.

Paul

[kcrisman]

comment:9

Well, in Fateman's eyes (and I would remind that he is an expert, if not THE expert, in this), the only bug is in users who treat these expressions as functions. At least, that's how I interpret it. So updating the documentation may be the better way.

But this shouldn't be a duologue; hopefully some others will have ideas. Cc:ing a few others who have thought about at least one or two of these things, just in case they have thoughts at this time. Otherwise it will sit - I simply don't have time to deal with it right now, because it needs to be part of a general overhaul of simplification if we don't just change documentation.

[kcrisman]

comment:10

I mean change documentation to give examples in prominent places, both in simplify_radical and simplify_full.