More immediate symbolic powers simplification

[rwst]

We already do:

sage: sqrt(4/9*x)
2/3*sqrt(x)
sage: sqrt(-4*x)
2*sqrt(-x)
sage: (4*x + 12)^(-3)
1/64/(x + 3)^3
sage: (4/9*x)^(3/2)
8/27*x^(3/2)

This should be extended to rational exponents of sums:

sage: sqrt(-4*x-4)
sqrt(-4*x - 4)
sage: (4*x + 12)^(-3/2)
(4*x + 12)^(-3/2)

It's a matter of implementing the case add^rational in Pynac's power::eval

CC: @EmmanuelCharpentier

Component: symbolics

Issue created by migration from https://trac.sagemath.org/ticket/23368

[EmmanuelCharpentier]

comment:2

Thanks for Cc'ing me !

I'm not convinced that's necessarily the Right Thing (TM) to do : it might prohibit more interesting operations, such as factorization after expand().

I was thinking of adding (after 8.0) a few methods for symbolic expressions, such as x.simplify_sum() (a wrapper for x.maxima_methods().ev(simpsum=True) and possibly a collection of useful-but-not-always-pertinent transformations (such as trig (e. g. conversions to tan(x/2), rewriting products as sums and vice-versa, etc...) that might be easier to call at willwityh such "syntactic sugar" methods.

Changing Maxima's domain can be done easily enough for one evaluation of a given expression E by asking E.maxima_methods().ev(domain=real), or for the long term via maxima_calculus("domain:real").

Could we take a bit of time to think about what would be useful to implement in such methods ? This simplification is an obvious candidate, but probably not the only one, and probably not as a systematic simplification.

I'm also considering extending E.distribute() to the case of the distribution of a differentiation over a sum ; I'm not yet convinced it is useful, but I'm looking for reasons (//pro// or contra).

BTW, this (as well as your previous work on symbolic sums and products) and the recent distribute() should be reported back to Maxima (but the implementation is not as easy in Maxima/lisp as in Sage...).

Furthermore, let's not forget that "Syntactic sucar causes cancer of the semicolon" (A. J. Perlis, IIRC) : in other words, let's not paint ourselves in a too-difficult-to-maintain corner.

[rwst]

comment:3

Fact is, there is already such simplification with integer exponents. Please give an example where extension to rational should not be allowed. Note also there is a canonical form Pynac adheres to and that affects if this simplification is applied (leading coeff positive). Note too that the long term goal is to become more independent from Maxima, for known reasons.

[EmmanuelCharpentier]

comment:4

Replying to @rwst:

Fact is, there is already such simplification with integer exponents. Please give an example where extension to rational should not be allowed.

No example on hand at the moment, but ISTR to have been bitten by too-eager simplifications in integration of trig functions (undergrad-level exercises...) : "obvious" changes of variable became largely unobvious, and some factorizations were missed.

Note also there is a canonical form Pynac adheres to and that affects if this simplification is applied (leading coeff positive).

And that sometimes gives birth to strange expressions, that have to be re-massaged. A minimal example (quoted from memory, no Sage available ATM) :

var("y,z,k,theta", domain="positive")
assume(k,"noninteger")
dbeta(y,k,theta)=y^(k-1)*e^-(y/theta)/(theta^k*gamma(k)
integrate(dbeta(z,k,theta)*dbeta(y-z,k,theta),z,0,y) ## Fails (returns an unevaluated integral)
integrate((dbeta(z,k,theta)*dbeta(y-z,k,theta)).expand(),z,0,y) ## Succeeds

Note too that the long term goal is to become more independent from Maxima, for known reasons.

Agreed. But I have to confess that, to me at least, Maxima is muche easier to grasp than Pynac (my command of C++ is not up to the level of mt grasp of Lisp and Maxima...).

[rwst]

Branch: u/rws/more_immediate_symbolic_powers_simplification

[rwst]

comment:6

You can try it out. I added the Pynac patch in this branch, so you can see yourself which doctests fail and how they fail. Test the directories symbolic, calculus, tests, and src/doc to see the effects of this patch.

---

New commits:

b17dedb

23368: More immediate symbolic powers simplification

[rwst]

Commit: b17dedb

[sagetrac-git]

Changed commit from b17dedb to 3cd17f5

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

3cd17f5

23368: new patch

[rwst]

comment:8

Actually a better alternative is to draw only the rational part of the root outside. The new patch does it and "fails" only these tests:

File "src/sage/calculus/calculus.py", line 233, in sage.calculus.calculus
Failed example:
    f.derivative(x)
Expected:
    1/3/sqrt(1/9*x^2 + 1)
Got:
    1/sqrt(x^2 + 9)

File "src/sage/functions/hypergeometric.py", line 776, in sage.functions.hypergeometric.closed_form
Failed example:
    closed_form(hypergeometric([1, 1, 2], [1, 1], z))
Expected:
    (z - 1)^(-2)
Got:
    1/(z - 1)^2

Do you agree the failures are okay?

I'm still investigating the fails in src/doc.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

ed4dece

23368: fix patch

[sagetrac-git]

Changed commit from 3cd17f5 to ed4dece