bug in simplify_radical()?
Stan Schymanski
I just noted some strange behaviour with simplify_radical():
----------------------------------------------------------------------
| SAGE Version 3.1.2, Release Date: 2008-09-19 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: sage: var('a b c')
(a, b, c)
sage: ((a*b - 0.5*a*(b - c))/a).simplify_radical()
0
sage: ((b - 0.5*(b - c))).simplify_radical()
0.500000000000000*c + 0.500000000000000*b
Clearly, the second result should be the same as the first one, as 'a'
cancels out. Does anyone know how to avoid such mistakes and whether
it is advisable to use simplify_radical at all?
Cheers
Stan
John Cremona
sage: ((a*b - (1/2)*a*(b - c))/a).simplify_radical()
(c + b)/2
which works fine. Maybe it's a bug in maxima. I don't see why you
would need simplify_radical() at all here, since your expression
contains no radicals.
John Cremona
2008/10/24 Stan Schymanski <schy...@gmail.com>:
Stan Schymanski
point numbers? By the way, simplify_trig and simplify_rational create
the same mistake. I agree that the use of simplify_radical() is not
very useful here, but if it makes such an obvious mistake, how
confident can we be that it doesn't make mistakes in more complicated
cases where we don't actually notice the mistake straight away? I
thought about using something like simplify_full() on any equation to
see if it can be simplified before I carry on with calculations.
Perhaps this is the wrong strategy, anyway. Any comments?
How could I actually get Sage to cancel out the 'a' in the equation?
None of the methods I tried do the job. I don't like doing things by
hand, because then I have to redo everything if I change an equation
somewhere at the top of the notebook.
Thanks a lot for thinking about it!
Stan
On Oct 24, 3:04 pm, "John Cremona" <john.crem...@gmail.com> wrote:
> A variation on your first try is:
>
> sage: ((a*b - (1/2)*a*(b - c))/a).simplify_radical()
> (c + b)/2
>
> which works fine. Maybe it's a bug in maxima. I don't see why you
> would need simplify_radical() at all here, since your expression
> contains no radicals.
>
> John Cremona
>
John Cremona
>
> That's interesting. It seems that the bug lies in the use of floating
> point numbers? By the way, simplify_trig and simplify_rational create
> the same mistake. I agree that the use of simplify_radical() is not
> very useful here, but if it makes such an obvious mistake, how
> confident can we be that it doesn't make mistakes in more complicated
> cases where we don't actually notice the mistake straight away? I
> thought about using something like simplify_full() on any equation to
> see if it can be simplified before I carry on with calculations.
> Perhaps this is the wrong strategy, anyway. Any comments?
> How could I actually get Sage to cancel out the 'a' in the equation?
> None of the methods I tried do the job. I don't like doing things by
> hand, because then I have to redo everything if I change an equation
> somewhere at the top of the notebook.
>
Here's an approach which does not use maxima at all, but rather more
"pure" algebra:
sage: R.<a,b,c> = QQ[]
sage: (a*b - (1/2)*a*(b - c))//a
1/2*b + 1/2*c
Here, R is the set of all polynomials in a,b,c with rational
coefficients, and // does an exact division. (If you use / instead
the answer looks the same but lies in a different place:
sage: parent((a*b - (1/2)*a*(b - c))/a)
Fraction Field of Multivariate Polynomial Ring in a, b, c over Rational Field
sage: parent((a*b - (1/2)*a*(b - c))//a)
Multivariate Polynomial Ring in a, b, c over Rational Field
Now, whether or not you like this solution seems to depend on whether
or not you are a pure mathematician who is used to rings and fields,
as opposed so someone who just deals with symbolic expressions. The
former are much faster (and, as in this case, more accurate!) but are
conceptually harder -- and do not allow things like radicals and
exponentials.
John Cremona
Burcin Erocal
> That's interesting. It seems that the bug lies in the use of floating
> point numbers? By the way, simplify_trig and simplify_rational create
> the same mistake. I agree that the use of simplify_radical() is not
> very useful here, but if it makes such an obvious mistake, how
> confident can we be that it doesn't make mistakes in more complicated
> cases where we don't actually notice the mistake straight away? I
> thought about using something like simplify_full() on any equation to
> see if it can be simplified before I carry on with calculations.
> Perhaps this is the wrong strategy, anyway. Any comments?
> How could I actually get Sage to cancel out the 'a' in the equation?
> None of the methods I tried do the job. I don't like doing things by
> hand, because then I have to redo everything if I change an equation
> somewhere at the top of the notebook.
In this case, expand seems to do what you want. I don't know if it will help
you with more complex expressions.
sage: var("a,b,c")
(a, b, c)
sage: e = ((a*b - (1/2)*a*(b - c))/a); e
(a*b - a*(b - c)/2)/a
sage: e.expand()
c/2 + b/2
or with float coefficients:
sage: e = ((a*b - (.5)*a*(b - c))/a); e
(a*b - 0.500000000000000*a*(b - c))/a
sage: e.expand()
0.500000000000000*c + 0.500000000000000*b
Jason Grout
In general, I find that expand will end up simplifying things a lot more
than the simplify functions will.
I suppose it's like our secondary school math: when in doubt, multiply
everything out and then see what cancels.
Jason
Stan Schymanski
simplify() would go a long way. Unfortunately, I am not a
Mathematician and hence struggle to understand rings and fields.
I am still a bit hesitant about simplify, though. Should a bug report
be filed to Maxima? By the way, is pynac going to replace the maxima
simplify algorithms? It seems that there is some potential for
improvement there.
Regards,
Stan
Burcin Erocal
Eventually, yes.
To be able to extend / improve / customize such maxima functions is one of the
main reasons behind the pynac backed symbolics effort.
Cheers,
Burcin