Sage: Ticket #12737: Remove simplify_radical() from simplify_full()
https://trac.sagemath.org/ticket/12737
<p>
There are a number of tickets open due to the use of <code>simplify_radical()</code> in <code>simplify_full()</code>.
</p>
<p>
Removing it would fix at least,
</p>
<ul><li><a class="ext-link" href="http://ask.sagemath.org/question/767/simplification-errors-in-simple-expressions"><span class="icon"></span>Ask Sage 767</a>
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/3520" title="defect: inconsistency in simplify_radical (closed: duplicate)">#3520</a> - inconsistency in simplify_radical
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/11934" title="defect: Symbolic simplification error (closed: fixed)">#11934</a> - Symbolic simplification error
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/12322" title="defect: invalid simplification of complex logarithm (closed: fixed)">#12322</a> - invalid simplification of complex logarithm
</li><li><a class="ext-link" href="http://ask.sagemath.org/question/1983/strange-way-to-simplify-square-roots"><span class="icon"></span>Ask Sage 1983</a>
</li></ul><p>
And maybe more. Here are some related tickets.
</p>
<ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a> is related, though about <code>simplify_radical</code> specifically.
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/11668" title="defect: abs(a+b)^2 == (a+b)^2 (closed: fixed)">#11668</a> - <code>abs(a+b)^2 == (a+b)^2</code> is now fixed by <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>
</li><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/14305" title="defect: Doctest: Immediate simplifications of symbolic powers (closed: fixed)">#14305</a> is tangentially related
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12737
Trac 1.1.6mjoFri, 23 Mar 2012 18:47:27 GMTattachment set
https://trac.sagemath.org/ticket/12737
https://trac.sagemath.org/ticket/12737
<ul>
<li><strong>attachment</strong>
set to <em>sage-trac_12737.patch</em>
</li>
</ul>
<p>
Add the flag and update doctests.
</p>
TicketmjoFri, 23 Mar 2012 18:48:39 GMTstatus changed
https://trac.sagemath.org/ticket/12737#comment:1
https://trac.sagemath.org/ticket/12737#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketnbruinFri, 23 Mar 2012 19:21:56 GMT
https://trac.sagemath.org/ticket/12737#comment:2
https://trac.sagemath.org/ticket/12737#comment:2
<p>
It's not entirely clear to me which simplifications are "safe" and which are not. Simplifying <code>x^2/x</code> to <code>x</code> is also not "safe" in the sense that equality does not hold for <code>x=0</code>. In many computer algebra systems, acceptable simplifications are not "safe" in this respect. By including a default <code>unsafe=False</code> I'm afraid you'll be raising expectations to a level that Sage does not attain (yet?).
</p>
TicketmjoFri, 23 Mar 2012 19:32:50 GMT
https://trac.sagemath.org/ticket/12737#comment:3
https://trac.sagemath.org/ticket/12737#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12737#comment:2" title="Comment 2">nbruin</a>:
</p>
<blockquote class="citation">
<p>
It's not entirely clear to me which simplifications are "safe" and which are not. Simplifying <code>x^2/x</code> to <code>x</code> is also not "safe" in the sense that equality does not hold for <code>x=0</code>. In many computer algebra systems, acceptable simplifications are not "safe" in this respect. By including a default <code>unsafe=False</code> I'm afraid you'll be raising expectations to a level that Sage does not attain (yet?).
</p>
</blockquote>
<p>
It's completely heuristic: the four I chose nobody seems to have a problem with. <code>simplify_radical</code>, on the other hand, wreaks havoc on trivial functions and has been the cause of numerous bug reports and mailing list discussions.
</p>
<p>
In <code>simplify</code>, after <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>, I say that a safe simplification is one "for which we are reasonably sure that the input will be considered equivalent to the output." That's probably the best we can do for now, and I'm <em>reasonably sure</em> that most people would consider <code>x^2/x</code> equivalent to <code>x</code>.
</p>
<p>
As it stands, I think <code>full_simplify</code> <em>sounds</em> safe so people will assume that anyway. This fix, while not perfect, at least improves things.
</p>
TicketkcrismanSat, 24 Mar 2012 02:17:23 GMT
https://trac.sagemath.org/ticket/12737#comment:4
https://trac.sagemath.org/ticket/12737#comment:4
<blockquote class="citation">
<blockquote class="citation">
<p>
It's not entirely clear to me which simplifications are "safe" and which are not. Simplifying <code>x^2/x</code> to <code>x</code> is also not "safe" in the sense that equality does not hold for <code>x=0</code>. In many computer algebra systems, acceptable simplifications are not "safe" in this respect. By including a default <code>unsafe=False</code> I'm afraid you'll be raising expectations to a level that Sage does not attain (yet?).
</p>
</blockquote>
<p>
It's completely heuristic: the four I chose nobody seems to have a problem with.
</p>
</blockquote>
<p>
Only in that we couldn't find Trac tickets about them.
</p>
<blockquote class="citation">
<p>
<code>simplify_radical</code>, on the other hand, wreaks havoc on trivial functions and has been the cause of numerous bug reports and mailing list discussions.
</p>
<blockquote>
<p>
In <code>simplify</code>, after <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>, I say that a safe simplification is one "for which we are reasonably sure that the input will be considered equivalent to the output." That's probably the best we can do for now, and I'm <em>reasonably sure</em> that most people would consider <code>x^2/x</code> equivalent to <code>x</code>.
</p>
</blockquote>
</blockquote>
<p>
I'm reasonably sure that no mathematician would consider them equivalent unless you add "almost everywhere". Simplification <em>simplifies</em>, hence makes it not actually the same (at least potentially). This shouldn't be controversial.
</p>
<blockquote class="citation">
<p>
As it stands, I think <code>full_simplify</code> <em>sounds</em> safe so people will assume that anyway. This fix, while not perfect, at least improves things.
</p>
</blockquote>
<p>
Well, everything <em>sounds</em> safe unless you put in the word "unsafe".
</p>
<p>
I'm pretty confused as to the relation of this to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>. See <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650#comment:6" title="Comment 6 for Ticket #12650">my comments there</a>.
</p>
<p>
I'm sympathetic to doing something about <code>radcan</code>, but simplification is simplification, not identity.
</p>
<p>
Doesn't it make more sense to either document fully what can go wrong with <code>simplify_full</code>, or to add a flag <code>simplify_radicals</code> or something? I think that changing behavior in this case is probably the best compromise, but probably <code>unsafe</code> is sending the wrong message. There isn't anything unsafe about <code>radcan</code>, it's just a different point of view than ours - symbolic expressions versus functions. Spend some time on the Maxima list :)
</p>
TicketmjoMon, 26 Mar 2012 19:13:55 GMT
https://trac.sagemath.org/ticket/12737#comment:5
https://trac.sagemath.org/ticket/12737#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12737#comment:4" title="Comment 4">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
It's not entirely clear to me which simplifications are "safe" and which are not. Simplifying <code>x^2/x</code> to <code>x</code> is also not "safe" in the sense that equality does not hold for <code>x=0</code>. In many computer algebra systems, acceptable simplifications are not "safe" in this respect. By including a default <code>unsafe=False</code> I'm afraid you'll be raising expectations to a level that Sage does not attain (yet?).
</p>
</blockquote>
<p>
It's completely heuristic: the four I chose nobody seems to have a problem with.
</p>
</blockquote>
<p>
Only in that we couldn't find Trac tickets about them.
</p>
<blockquote class="citation">
<p>
<code>simplify_radical</code>, on the other hand, wreaks havoc on trivial functions and has been the cause of numerous bug reports and mailing list discussions.
</p>
<blockquote>
<p>
In <code>simplify</code>, after <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>, I say that a safe simplification is one "for which we are reasonably sure that the input will be considered equivalent to the output." That's probably the best we can do for now, and I'm <em>reasonably sure</em> that most people would consider <code>x^2/x</code> equivalent to <code>x</code>.
</p>
</blockquote>
</blockquote>
<p>
I'm reasonably sure that no mathematician would consider them equivalent unless you add "almost everywhere". Simplification <em>simplifies</em>, hence makes it not actually the same (at least potentially). This shouldn't be controversial.
</p>
</blockquote>
<p>
Before our discussion on another one of these tickets, I had assumed it was not controversial that simplification had to return an equivalent expression. So it is at least a little controversial.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
As it stands, I think <code>full_simplify</code> <em>sounds</em> safe so people will assume that anyway. This fix, while not perfect, at least improves things.
</p>
</blockquote>
<p>
Well, everything <em>sounds</em> safe unless you put in the word "unsafe".
</p>
<p>
I'm pretty confused as to the relation of this to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>. See <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650#comment:6" title="Comment 6 for Ticket #12650">my comments there</a>.
</p>
<p>
I'm sympathetic to doing something about <code>radcan</code>, but simplification is simplification, not identity.
</p>
<p>
Doesn't it make more sense to either document fully what can go wrong with <code>simplify_full</code>, or to add a flag <code>simplify_radicals</code> or something? I think that changing behavior in this case is probably the best compromise, but probably <code>unsafe</code> is sending the wrong message. There isn't anything unsafe about <code>radcan</code>, it's just a different point of view than ours - symbolic expressions versus functions. Spend some time on the Maxima list :)
</p>
</blockquote>
<p>
All expressions in sage are callable like functions, so if you have both radicals and a variable in an expression, <code>simplify_radical()</code> is unsafe. I.e. you're probably gonna get the wrong answer. I think marking it as unsafe is more likely to catch someone's attention than asking him to read the documentation. I almost certainly used <code>full_simplify()</code> for years without doing so, since I thought I knew what it was doing and had used similar functions in e.g. Mathematica. I think the problem is that it's called "simplification," not that it exists.
</p>
<p>
Either way, <code>f.full_simplify(simplify_radicals=True)</code> is not much better than <code>f.full_simplify().simplify_radical()</code>... the keyword argument is the easy way out, but I feel like it should control more than one method call if we do it. And if we remove the unsafe simplifications from <code>full_simplify()</code>, that seems to make <code>simplify()</code> redundant, too. That's the dual situation to what we'd have after <a class="closed ticket" href="https://trac.sagemath.org/ticket/12650" title="enhancement: Perform safe simplifications in Expression.simplify() (closed: invalid)">#12650</a>, but at least we could add more stuff to <code>full_simplify()</code> in the future to change that.
</p>
TicketmjoTue, 27 Mar 2012 17:40:14 GMTstatus changed
https://trac.sagemath.org/ticket/12737#comment:6
https://trac.sagemath.org/ticket/12737#comment:6
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
There is not consensus that this is even a good idea, so I'll leave it alone until we can discuss it further.
</p>
TicketmjoSat, 14 Apr 2012 23:02:04 GMTstatus, description, summary changed; author set; dependencies deleted
https://trac.sagemath.org/ticket/12737#comment:7
https://trac.sagemath.org/ticket/12737#comment:7
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
set to <em>Michael Orlitzky</em>
</li>
<li><strong>dependencies</strong>
<em>#12650</em> deleted
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=7">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Add an `unsafe` argument to Expression.simplify_full()</em> to <em>Remove simplify_radical() from simplify_full()</em>
</li>
</ul>
<p>
This should be a more straight-forward proposal. I just removed <code>simplify_radical()</code> from <code>simplify_full()</code> and fixed a few doctests (details in the commit message).
</p>
<p>
One of the doctest fixes is duplicated in <a class="closed ticket" href="https://trac.sagemath.org/ticket/12780" title="enhancement: Be more careful about setting the Maxima 'domain' (closed: fixed)">#12780</a>; the doctest is wrong (missing assumptions) but we're masking that fact at the moment.
</p>
TicketmjoSun, 15 Apr 2012 18:34:43 GMTattachment set
https://trac.sagemath.org/ticket/12737
https://trac.sagemath.org/ticket/12737
<ul>
<li><strong>attachment</strong>
set to <em>sage-trac_12737-remove_radcan.patch</em>
</li>
</ul>
<p>
Same patch with the functional.py doctest factored out
</p>
TicketmjoSun, 15 Apr 2012 18:35:16 GMTdependencies set
https://trac.sagemath.org/ticket/12737#comment:8
https://trac.sagemath.org/ticket/12737#comment:8
<ul>
<li><strong>dependencies</strong>
set to <em>#12845</em>
</li>
</ul>
<p>
I moved the common doctest to <a class="closed ticket" href="https://trac.sagemath.org/ticket/12845" title="defect: Incorrect doctest in sage/misc/functional.py (closed: fixed)">#12845</a> and removed it from this patch.
</p>
TicketkcrismanWed, 14 Nov 2012 19:18:27 GMTdescription changed
https://trac.sagemath.org/ticket/12737#comment:9
https://trac.sagemath.org/ticket/12737#comment:9
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=9">diff</a>)
</li>
</ul>
<p>
Lest it seem weird that I'm adding to the list in the description, let it be known that I haven't necessarily changed my mind here, but fairness dictates that I point this additional example out!
</p>
TicketkcrismanWed, 12 Jun 2013 19:31:31 GMTdescription changed
https://trac.sagemath.org/ticket/12737#comment:10
https://trac.sagemath.org/ticket/12737#comment:10
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=10">diff</a>)
</li>
</ul>
TicketkcrismanWed, 12 Jun 2013 19:32:48 GMTdescription changed
https://trac.sagemath.org/ticket/12737#comment:11
https://trac.sagemath.org/ticket/12737#comment:11
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=11">diff</a>)
</li>
</ul>
TicketmjoSat, 15 Jun 2013 16:30:15 GMTdescription changed
https://trac.sagemath.org/ticket/12737#comment:12
https://trac.sagemath.org/ticket/12737#comment:12
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=12">diff</a>)
</li>
</ul>
TicketkcrismanTue, 18 Jun 2013 18:44:48 GMT
https://trac.sagemath.org/ticket/12737#comment:13
https://trac.sagemath.org/ticket/12737#comment:13
<p>
Burcin agrees here at SD that this should be done. I concur with him that probably we should solve <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a> (perhaps even deprecating the simplify name?) at the same time. What do you think?
</p>
TicketmjoTue, 18 Jun 2013 18:58:27 GMT
https://trac.sagemath.org/ticket/12737#comment:14
https://trac.sagemath.org/ticket/12737#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12737#comment:13" title="Comment 13">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Burcin agrees here at SD that this should be done. I concur with him that probably we should solve <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a> (perhaps even deprecating the simplify name?) at the same time. What do you think?
</p>
</blockquote>
<p>
Once it's gone from simplify_full(), personally I would deprecate <code>simplify_radical()</code> and rename it to <code>radcan()</code>. It's probably impossible to clearly explain what radcan does, but we can try to fix the docs and add many more examples.
</p>
TicketkcrismanTue, 18 Jun 2013 19:01:30 GMT
https://trac.sagemath.org/ticket/12737#comment:15
https://trac.sagemath.org/ticket/12737#comment:15
<blockquote class="citation">
<blockquote class="citation">
<p>
Burcin agrees here at SD that this should be done. I concur with him that probably we should solve <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a> (perhaps even deprecating the simplify name?) at the same time. What do you think?
</p>
</blockquote>
<p>
Once it's gone from simplify_full(), personally I would deprecate <code>simplify_radical()</code> and rename it to <code>radcan()</code>. It's probably impossible to clearly explain what radcan does, but we can try to fix the docs and add many more examples.
</p>
</blockquote>
<p>
Do you mind putting that on <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a>, as the architect of this set of changes?
</p>
TicketjvkerschMon, 01 Jul 2013 10:37:37 GMT
https://trac.sagemath.org/ticket/12737#comment:16
https://trac.sagemath.org/ticket/12737#comment:16
<p>
Here's another example of unexpected behavior introduced by using simplify_radical as a part of simplify_full: <a class="ext-link" href="https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/Pq9hyOTzrL8"><span class="icon"></span>https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/Pq9hyOTzrL8</a>.
</p>
TicketjvkerschMon, 01 Jul 2013 10:38:34 GMTcc set
https://trac.sagemath.org/ticket/12737#comment:17
https://trac.sagemath.org/ticket/12737#comment:17
<ul>
<li><strong>cc</strong>
<em>jvkersch</em> added
</li>
</ul>
TicketmjoMon, 01 Jul 2013 13:16:23 GMT
https://trac.sagemath.org/ticket/12737#comment:18
https://trac.sagemath.org/ticket/12737#comment:18
<p>
I think there's consensus to remove it now, but this will need rebasing. There are also a ton of related tickets which will all need to be coordinated so that the patches apply cleanly.
</p>
<p>
As soon as I get time I'll start by updating this patch.
</p>
TicketmjoTue, 02 Jul 2013 21:59:19 GMTattachment set
https://trac.sagemath.org/ticket/12737
https://trac.sagemath.org/ticket/12737
<ul>
<li><strong>attachment</strong>
set to <em>sage-trac_12737-rebased.patch</em>
</li>
</ul>
<p>
Rebased patch against 5.11.beta3
</p>
TicketmjoTue, 02 Jul 2013 22:01:00 GMT
https://trac.sagemath.org/ticket/12737#comment:19
https://trac.sagemath.org/ticket/12737#comment:19
<p>
I just put up a new patch that should apply cleanly. There are some failing tests in doc/de/thematische_anleitungen/sage_gymnasium.rst, but I don't know what the surrounding context is and so I'm not sure how best to fix them. Will need some attention from the Germans.
</p>
TicketkcrismanWed, 03 Jul 2013 14:47:06 GMT
https://trac.sagemath.org/ticket/12737#comment:20
https://trac.sagemath.org/ticket/12737#comment:20
<blockquote class="citation">
<p>
Here's another example of unexpected behavior introduced by using simplify_radical as a part of simplify_full: <a class="ext-link" href="https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/Pq9hyOTzrL8"><span class="icon"></span>https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/Pq9hyOTzrL8</a>.
</p>
</blockquote>
<p>
In that same thread: Robert D. of Maxima reports
</p>
<pre class="wiki">> sage: u, v = var('u, v', domain='real')
> sage: sqrt(-1/(u^2+v^2-1)).simplify_radical() # This will hang
This is a bug in Maxima:
(%i2) radcan (sqrt (-1 / (u^2 + v^2 - 1))), domain=complex;
It waits apparently forever here -- but it is actually looping over
*ALPHA (not sure why) which is a large prime number (8388593).
(%i3) :lisp (setq *alpha 17)
17
(%i3) radcan(sqrt(-1/(u^2+v^2-1))), domain=complex;
(%o3) 1/sqrt(-v^2-u^2+1)
I've reported this as bug # 2605.
</pre><p>
E.g. <a class="ext-link" href="http://sourceforge.net/p/maxima/bugs/2605/"><span class="icon"></span>Maxima 2605</a>. We may want to open a ticket for this or something, maybe along with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a>.
</p>
<hr />
<p>
I'll take a look at the failures in the new German tutorial at some point today, it's probably not a big deal.
</p>
TicketkcrismanWed, 03 Jul 2013 18:17:08 GMTstatus, cc changed; reviewer set; dependencies deleted
https://trac.sagemath.org/ticket/12737#comment:21
https://trac.sagemath.org/ticket/12737#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>dependencies</strong>
<em>#12845</em> deleted
</li>
<li><strong>cc</strong>
<em>navigium</em> added
</li>
</ul>
<blockquote class="citation">
<p>
I'll take a look at the failures in the new German tutorial at some point today, it's probably not a big deal.
</p>
</blockquote>
<pre class="wiki">sage -t doc/de/thematische_anleitungen/sage_gymnasium.rst
**********************************************************************
File "doc/de/thematische_anleitungen/sage_gymnasium.rst", line 397, in doc.de.thematische_anleitungen.sage_gymnasium
Failed example:
(log(8)/log(2)).simplify_full()
Expected:
3
Got:
log(8)/log(2)
**********************************************************************
File "doc/de/thematische_anleitungen/sage_gymnasium.rst", line 703, in doc.de.thematische_anleitungen.sage_gymnasium
Failed example:
log(10^5).simplify_full()
Expected:
5*log(5) + 5*log(2)
Got:
log(100000)
**********************************************************************
</pre><p>
Well, unfortunately the context is that the authors of the tutorial really really like using just one simplification command. In particular, they advertise <code>simplify_full</code> as providing log addition rules "for free". Which I don't really see as "simplification in the latter example! (Which is some of what you've been saying earlier.) However, it does mean it would be interesting to see whether it might be worth adding <code>canonicalize_exp</code> or <code>canonicalize_log</code> at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11912" title="enhancement: Clarify simplify_radical and Maxima's radcan (closed: fixed)">#11912</a> as aliases...
</p>
<p>
Anyway, I can fix this, but I don't have time right now, because I would have to think about how best to preserve the authors' intentions. I assume it would be annoying to all of a sudden point out that there are multiple "simplification" options. I've cc:ed the author of <a class="closed ticket" href="https://trac.sagemath.org/ticket/14550" title="enhancement: German tutorial for school teachers (mainly aimed at Gymnasium level) (closed: fixed)">#14550</a> to see if he has any suggestions.
</p>
<p>
@navigium - man könnte behaupten, dass <code>log(10^5) = > 5*log(5) + 5*log(2)</code> nicht eine Vereinfachung, sondern eine ... "Gezetzeseinsetzung" ist. Im jeden Fall sieht es nicht einfacher aus! Dennoch wollen wir die Einleitung nicht einfach so ohne weiteres zerlegen. Vorausgesetzt, dass <code>simplify_radical</code> von <code>simplify_full</code> verschwindet, wie wäre es am Besten (d. Hinsicht nach) <code>simplify_radical</code> im Gymnasialkontext zu erwähnen?
</p>
TicketnavigiumThu, 04 Jul 2013 08:50:46 GMT
https://trac.sagemath.org/ticket/12737#comment:22
https://trac.sagemath.org/ticket/12737#comment:22
<p>
I'm at the moment unsure how to fix this. I guess the first example that fails could just be removed since it can be numerically evaluated. But I think the second example should remain in the tutorial and should be fixed. At the moment I don't have the time to look into it. I won't be around till mid August.
</p>
<p>
@kcrisman Ich habe es vor allem als Vereinfachung bezeichnet, da es die notwendige Umformung ist, welche man für das Lösen von Exponentialgleichungen benötigt. Aus diesem Grund halte ich es auch für wichtig, dass man erwähnt, wie man eine solche Umformung machen kann.
</p>
<p>
Man könnte es aber natürlich umbennen. Ich würde es als "Zerlegung durch Benutzen der Logarithmengesetze" oder ähnlich nennen.
</p>
<p>
Natürlich wäre es schon, wenn man simplify_radical nicht separat aufführen muss, um die Sache einfach zu halten. Wenn es aber aus simplify_full fliegt, müsste man es wohl erwähnen.
</p>
TicketkcrismanThu, 04 Jul 2013 13:21:08 GMT
https://trac.sagemath.org/ticket/12737#comment:23
https://trac.sagemath.org/ticket/12737#comment:23
<blockquote class="citation">
<p>
@kcrisman Ich habe es vor allem als Vereinfachung bezeichnet, da es die notwendige Umformung ist, welche man für das Lösen von Exponentialgleichungen benötigt. Aus diesem Grund halte ich es auch für wichtig, dass man erwähnt, wie man eine solche Umformung machen kann.
</p>
<p>
Man könnte es aber natürlich umbennen. Ich würde es als "Zerlegung durch Benutzen der Logarithmengesetze" oder ähnlich nennen.
</p>
</blockquote>
<p>
Eigentlich genügt das!
</p>
<blockquote class="citation">
<p>
Natürlich wäre es schon, wenn man simplify_radical nicht separat aufführen muss, um die Sache einfach zu halten. Wenn es aber aus simplify_full fliegt, müsste man es wohl erwähnen.
</p>
</blockquote>
<p>
Tja...
</p>
<p>
Michael, I'll try to keep this on the front burner for finding a good fix - navigium has a good phrase we can use, and I don't really see any other way to fix this, since it does happen to be very convenient that we can use radcan in some cases to do log expansion.
</p>
TicketmjoSat, 06 Jul 2013 16:31:56 GMT
https://trac.sagemath.org/ticket/12737#comment:24
https://trac.sagemath.org/ticket/12737#comment:24
<p>
It is regrettable that there's no other way to get log simplification of things like <code>log(8)/log(2)</code>, but <code>simplify_radical()</code> will do the same thing even when the argument to the log function is a complex function of, say, <code>z</code>.
</p>
<p>
It'd be nice to have something that worked for constants at least, but avoided e.g. <a class="closed ticket" href="https://trac.sagemath.org/ticket/12322" title="defect: invalid simplification of complex logarithm (closed: fixed)">#12322</a>.
</p>
TicketkcrismanTue, 09 Jul 2013 20:22:24 GMTstatus, reviewer, description changed
https://trac.sagemath.org/ticket/12737#comment:25
https://trac.sagemath.org/ticket/12737#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Karl-Dieter Crisman</em> to <em>Karl-Dieter Crisman, Beni Keller</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=25">diff</a>)
</li>
</ul>
<p>
I'd appreciate a quick review from navigium as to whether my German syntax is 100% correct, but this should take care of it, and conforms to what he suggested as a solution.
</p>
<p>
Patchbot, apply sage-trac_12737-rebased.patch and trac_12737-de.patch
</p>
TicketkcrismanWed, 10 Jul 2013 15:48:10 GMTattachment set
https://trac.sagemath.org/ticket/12737
https://trac.sagemath.org/ticket/12737
<ul>
<li><strong>attachment</strong>
set to <em>trac_12737-de.patch</em>
</li>
</ul>
TicketkcrismanWed, 10 Jul 2013 15:48:45 GMT
https://trac.sagemath.org/ticket/12737#comment:26
https://trac.sagemath.org/ticket/12737#comment:26
<p>
Patchbot, apply sage-trac_12737-rebased.patch and trac_12737-de.patch
</p>
TicketnavigiumWed, 10 Jul 2013 18:13:08 GMT
https://trac.sagemath.org/ticket/12737#comment:27
https://trac.sagemath.org/ticket/12737#comment:27
<p>
I think that's a great way to solve my document. Now the readers even get something extra because they are taught how to apply log rules both ways. Thanks @kcrisman for solving it.
</p>
TicketkcrismanWed, 10 Jul 2013 18:38:07 GMT
https://trac.sagemath.org/ticket/12737#comment:28
https://trac.sagemath.org/ticket/12737#comment:28
<p>
Great. Now someone (other than me) just needs to check that it passes tests and they can set it to positive review.
</p>
TicketjvkerschMon, 15 Jul 2013 16:34:58 GMTstatus changed
https://trac.sagemath.org/ticket/12737#comment:29
https://trac.sagemath.org/ticket/12737#comment:29
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
<code>make ptestlong</code> does not report any errors so I'm setting this to positive review.
</p>
TicketjdemeyerSun, 21 Jul 2013 21:37:50 GMTmilestone changed
https://trac.sagemath.org/ticket/12737#comment:30
https://trac.sagemath.org/ticket/12737#comment:30
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketjdemeyerFri, 02 Aug 2013 14:14:51 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/12737#comment:31
https://trac.sagemath.org/ticket/12737#comment:31
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-5.12.beta0</em>
</li>
</ul>
TicketkcrismanWed, 06 Nov 2013 15:59:28 GMTdescription changed
https://trac.sagemath.org/ticket/12737#comment:32
https://trac.sagemath.org/ticket/12737#comment:32
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12737?action=diff&version=32">diff</a>)
</li>
</ul>
<p>
Updates:
</p>
<p>
Removed
</p>
<ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/3520" title="defect: inconsistency in simplify_radical (closed: duplicate)">#3520</a> - inconsistency in simplify_radical
</li></ul><p>
from description, as that was not about <code>simplify_full</code> to start with.
</p>
<p>
I posted updates on the ask.sagemath questions just now.
</p>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/11934" title="defect: Symbolic simplification error (closed: fixed)">#11934</a> needs review.
</p>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/12322" title="defect: invalid simplification of complex logarithm (closed: fixed)">#12322</a> needs to be reworded since we didn't use the "unsafe" parameter in <code>simplify_full</code>.
</p>
Ticket