[sage-support] Re: Simplification Issue Implicates Canonical Form
On Feb 22, 2:37 am, JamesHDavenport j.h.davenp...@bath.ac.uk wrote: Canonical form and simplify aren't the same thing (necessarily). See Carette,J., Understanding Expression Simplification. Proc. ISSAC 2004 (ed. J. Gutierrez), ACM Press, New York, 2004, pp. 72-79. I don't have access to that source but I completely agree, noting that the passage you quoted discusses the results of full_simplify(). What I've reported is primarily a bug in Sage simplification. However, the underlying cause appears to be an issue with the GiNaC canonical form, which apparently tends to proliferate radicals of small integers. Given Sage's dependence upon GiNaC's canonical form, unless Sage aggressively simplifies such expressions, Sage users will see many more expressions like -(3*sqrt(-2/3*(2*(3*sqrt(-2*sqrt(5) + 5) - 2*sqrt(5) +3)/ (sqrt(-2*sqrt(5) + 5) - sqrt(5) + 2) - 3)*el + 1/9*(3*sqrt(-2*sqrt(5)+ 5) - 2*sqrt(5) + 3)^2/(sqrt(-2*sqrt(5) + 5) - sqrt(5) + 2)^2) - (3*sqrt(-2*sqrt(5) + 5) - 2*sqrt(5) + 3)/(sqrt(-2*sqrt(5) + 5) - sqrt(5)+ 2))/(2*(3*sqrt(-2*sqrt(5) + 5) - 2*sqrt(5) + 3)/ (sqrt(-2*sqrt(5) + 5)- sqrt(5) + 2) - 3) My system engineering gut feel is that it would be desirable to address this particular simplification issue closer to the source rather than to try to engineer around it on the simplification end. When I get some free time, I'm going to raise this issue on GiNaC- list. I'm not sure how soon that will be though. -Mark -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Simplification Issue Implicates Canonical Form
So once it comes back to Sage, its internal representation goes back to the Ginac one. Doh! So much for a possible workaround involving maxima. Dox, I was using full_simplify() and also the handful of simplify methods it invokes. Evaluate a.full_simplify? to see their names. Nils, trivial comparison is a major reason to use a canonical form but it isn't an argument that favors a particular canonical form. For example, to simplify your example expressions, I would factor the 6 inside the radical and continue with substitutions as I recommended. The resulting expressions would be easy to compare because they would be identical: 2/sqrt(6) - 2/(sqrt(3)*sqrt(2)) - sqrt(2)/sqrt(3) sqrt(6)/3 - (sqrt(3)*sqrt(2))/3 - sqrt(2)/sqrt(3) My initial problem was the severe obfuscation that resulted when extra factors added by the canonical form refused to cancel and then replicated geometrically. Severe obfuscation is obviously a bad thing. It grows out of simple obfuscation of much simpler expressions. Should ( 1/7 * sqrt(21) ).full_simplify() produce 1/7*sqrt(3)*sqrt(7) when sqrt(3)/sqrt(7) is an option? Having fewer factors is an important part of being simpler. In the more complicated expression, the factors involving 7s aren't even adjacent. I don't know if the more complicated forms are required for GiNaC to perform efficiently. However, from an interactive user's perspective, this issue is perplexing because it only involves the representation of constants. What could be simpler? (pun intended) -Mark -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Simplification Issue Implicates Canonical Form
I appreciate that background info. I hadn't tried invoking maxima because I read somewhere that simplify() used maxima. I must've been reading outdated material. As you stated, maxima does the correct thing. Because Sage can invoke maxima, perhaps I have a work around. You're right that this issue should be considered in the context of powers. In that context, I think it is even more clear that 5^(-1/2) is simpler than (1/5) * 5^(1/2). Leaving the additional term doesn't seem like a big deal, but by preventing subsequent simplifications, and by combining and recombining with other large expressions, it can have highly undesirable effects. I took a quick look at ginsh, the GiNaC interactive shell. It converts 1/sqrt(5) to 1/5*sqrt(5) so I suspect that this issue can be traced to the GiNaC canonical form. I'm not a CAS expert but I know a fair amount about computer system interfaces and I'm sure this issue adversely impacts the user experience. Nobody would select equation obfuscation mode given the choice. I think this issue should be taken up with the GiNaC folks. Do they hang out in this group? -Mark -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Simplification Issue Implicates Canonical Form
Hello sage-support, I'm a Sage newbie who just joined the group. Before I get to the meat of my post, I'd like to thank the open source math software community for all of your hard work! Nothing I say should be misinterpreted as a complaint. I have only admiration and gratitude. I ran into an issue that I thought was worth reporting. As I worked on a relatively simple math problem, I noticed that my screen became filled with complicated expressions involving square roots of small integers. I knew the result couldn't be as complicated as it looked. Trying the various simplify methods didn't help. I scratched my head for a while and experimented. I eventually isolated the issue to the fact that Sage doesn't simplify sqrt(5) / 5 to 1 / sqrt(5). Worse, it dutifully replaces 1 / sqrt(5) with sqrt(5) / 5, implying that an underlying canonical form definition is systematically making expressions more complicated than necessary. I can imagine a theoretical argument about positive exponents being simpler than negative exponents of the same magnitude but that argument falls apart quickly in practice. The problem with keeping expressions like sqrt(5) / 5 is that they grow uncontrollably with subsequent operations. For example, it keeps expressions like -1/5*(sqrt(-2*sqrt(5) + 5) - sqrt(5))*sqrt(5) from simplifying to - sqrt(-2/sqrt(5) + 1) + 1. Several operations later, a screenful of unnecessary radicals completely obscures the underlying math. Given how common square roots of small integers are, particularly in newbie math problems, I expect this issue to be a significant stumbling block for many folks trying to learn Sage. I know that expression simplification is a black art so I can't pretend to know how to fix this issue. However, I'm certain that 1 / sqrt(5) is simpler than sqrt(5) / 5 in some important way. For what it's worth, I think that most of us would make that substitution if we were doing math without automated support. -Mark -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
