You pretty much are missing the boat on what to do here. You seem to think you are constrained to return something that Maxima returns, and simultaneously think that you are building some kind of new mathematical "correct" system.
There are two branches to the square root. If you want to represent the result of sqrt(x^2) correctly, you must represent both x and -x. If you "assume x is positiv" that changes nothing. 3 is positive but sqrt (3^2) and sqrt((-3)^2) are both sqrt(9) which is BOTH -3 and 3. It gets worse for cube roots, nth roots, and for that matter, log, or even arcsin. So if you want to be correct, please do so. Some people who have been using Maxima for decades have puzzled over how to handle this in the context of a system that was too large and difficult to change in so dramatic a way. Indeed this problem was known before the start of Maple or Mathematica, and each either ignored or was ignorant of the problem. Now we have Sage, which has a 3-way choice. Do something, ignore it, or (as currently?) be ignorant of it. RJF On Sunday, March 4, 2012 4:12:13 PM UTC-8, Michael Orlitzky wrote: > > Right now, we have a problem with simplification. There are a couple of > open tickets about it, and an Ask Sage thread, but it's easier to give > an example (thanks to logix on IRC for the minimal test case): > > sage: f = sqrt(x^2 + 2*x + 1) > sage: f.full_simplify() > x + 1 > > I think the user should have to try *really* hard to ask us for this > simplification. > > Right now, simplify() just sends an expression to maxima and back. Full > simplify does every simplification, including simplify_radical() which > is to blame for the error above. > > There are a couple of ways we could improve the situation, some > combination of the following. > > simplify > -------- > > 1. We could leave simplify alone. We don't have to change anything, but > if we also make full_simplify() safe, everyone will just use > full_simplify instead of simplify and have to type five extra characters > every time. > > 2. We can replace the existing simplify with, > > simplify_factorial -> > simplify_trig -> > simplify_rational -> > simplify_log > > which seem to be safe in practice. I like this, because it does actually > try to simplify the expression but you can have some faith in the > result. Only two trivial tests are affected by this change. > > > full_simplify > ------------- > > 1. We can leave it alone. The worst choice in my opinion. If you can't > trust the results, it's useless. > > 2. We can deprecate full_simplify and rename it unsafe_simplify. It > still exists, but it's obvious that it's unsafe to use. This is made > better if we improve simplify() because then unsafe_simplify will only > be needed in extreme cases. > > 3. We can add an option e.g. unsafe=True to full_simplify allowing it to > do simplify_radical(). Some people won't know it's there, but we don't > have to deprecate anything in that case. This makes simplify() pretty > much useless though. > > > Thoughts? Did I overlook anything? > > On Sunday, March 4, 2012 4:12:13 PM UTC-8, Michael Orlitzky wrote: > > Right now, we have a problem with simplification. There are a couple of > open tickets about it, and an Ask Sage thread, but it's easier to give > an example (thanks to logix on IRC for the minimal test case): > > sage: f = sqrt(x^2 + 2*x + 1) > sage: f.full_simplify() > x + 1 > > I think the user should have to try *really* hard to ask us for this > simplification. > > Right now, simplify() just sends an expression to maxima and back. Full > simplify does every simplification, including simplify_radical() which > is to blame for the error above. > > There are a couple of ways we could improve the situation, some > combination of the following. > > simplify > -------- > > 1. We could leave simplify alone. We don't have to change anything, but > if we also make full_simplify() safe, everyone will just use > full_simplify instead of simplify and have to type five extra characters > every time. > > 2. We can replace the existing simplify with, > > simplify_factorial -> > simplify_trig -> > simplify_rational -> > simplify_log > > which seem to be safe in practice. I like this, because it does actually > try to simplify the expression but you can have some faith in the > result. Only two trivial tests are affected by this change. > > > full_simplify > ------------- > > 1. We can leave it alone. The worst choice in my opinion. If you can't > trust the results, it's useless. > > 2. We can deprecate full_simplify and rename it unsafe_simplify. It > still exists, but it's obvious that it's unsafe to use. This is made > better if we improve simplify() because then unsafe_simplify will only > be needed in extreme cases. > > 3. We can add an option e.g. unsafe=True to full_simplify allowing it to > do simplify_radical(). Some people won't know it's there, but we don't > have to deprecate anything in that case. This makes simplify() pretty > much useless though. > > > Thoughts? Did I overlook anything? > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
