On Sep 25, 12:35 pm, Francois Maltey <fmal...@nerim.fr> wrote:
> Hi Burcin,
>
> Many thanks for theses details about sage. I try to understand what you
> prefer, and why.
>
> > The main reason I left this simplification "exp(a)^2 to exp(2*a)" while 
> > fixing #6948 was that MMA does things this way.
>
> All right : MMA is good.
>
> > Another consideration was that before performing any nontrivial operation 
> > on symbolic expressions (integration,
> > transforms, etc.), we would have to perform some normalization, and this 
> > seemed like a normal form as it is.
>
> It's often true, but on the other hand I'm quite sure the main Risch
> algorithm for integration looks at independant algebraic functions and
> transforms exp(2x) and exp(3x) to y^2 and y^3 with y=exp(x) : the
> opposite transform.
>
> This almost canonical transform can also be the first call in sum,
> diffenrentiate, and so. (I'm not sure about integrate).
>
> An other point : I see that sage is very lazy over expressions : (1+1/x)
> / (2+1/x) remains.
> So I don't find very logically consistent to be hurry with exp(a)^2 and
> to be lazy with fractions.
>
> With rational expressions the single functions expand and factor
> transform (a-b)*(a+b) and a^2-b^2,
> and sage remains both expressions in their input forms. And I look at
> exp by analogies.
>
> Thanks a lot for your workaround for tests, but I expect an easiest way
> for students.
>
> As a workaround, you can do the following to replace exp(x) with y in the 
> example above:
>
> sage: t = exp(2*x)/(exp(3*x)+1)
> sage: w = SR.wild()
> sage: match_list = t.find(exp(w*x)); match_list
> ...
>
> The way with hold(exp(a))^5 expressions is less symetric in the mind but
> lets also possible a lot of computations in both way. An
> expand(exp(2*a)) may return hold(exp(a))^2 even if the next eval go back
> to exp(2*a).
>
> > If you think it'll help, I can probably prepare a pynac package that
> > disables the automatic simplification of exp powers. I don't have time
> > to submit that to Sage (say, as an alternative solution to #6948), but
> > it's not hard to do this for experimental purposes.
>
> Your offer is superb and I keep it in my mind.
> But I'll continue to play with the standard sage, and learn it. Even if
> I feel we should come back to this point later.
>
> 3 more practice questions.
>
> 1/ I see you have already patched the exp(a)^b problem. I use sage-4.1.1
> and run sage -upgrade, but I don't get any update. Of corse I can wait
> the next sage, but is there a way to get a  new-and-unstable sage ?
>

See http://groups.google.com/group/sage-devel, and look for things
that talk about releases.  In this case,
http://groups.google.com/group/sage-devel/browse_thread/thread/bdf60570317ba5ad
has information about the development version.  Or you can look at the
group http://groups.google.com/group/sage-release, but it's not as
interesting of a group :)  Also, be careful using sage -upgrade unless
you have already built from source and are in a clean branch (even
then bad things can happen...).

> 3/ How in sage can I test if a sub-expression I get with
> expr.operands()[0 or 1 or 2] is a integer, a single variable, a real
> expression in its tree.

Use .pyobject() on the coefficient, I think (I got this from Burcin in
an earlier thread).

- kcrisman
--~--~---------~--~----~------------~-------~--~----~
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
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to