[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 [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org