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

[rwst]

comment:10

After the last fix I feel justified to introduce this change in Pynac-0.7.10. I'll remove the branch now but it can still be checked out for testing. This ticket now depends on a future Pynac upgrade ticket, and it should add the bool... doctest and some more for good measure.

[rwst]

Changed branch from u/rws/more_immediate_symbolic_powers_simplification to none

[rwst]

Changed commit from ed4dece to none

[rwst]

Changed upstream from Reported upstream. No feedback yet. to Fixed upstream, in a later stable release.

[rwst]

Dependencies: pynac-0.7.10

[rwst]

comment:11

There were complications, see #23325 comment:21
So a full implementation depends on improved simplifcation, probably outside Maxima.

[rwst]

comment:12

Examples and doctests that would change:

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

Expected:
    1/4*sqrt(5) + 1/4*I*sqrt(2*sqrt(5) + 10) - 1/4
Got:
    1/4*I*sqrt(2)*sqrt(sqrt(5) + 5) + 1/4*sqrt(5) - 1/4

Expected:
    (-1)^floor(1/2*x/pi)*sqrt(-1/2*cos(x) + 1/2)
Got:
    sqrt(1/2)*(-1)^floor(1/2*x/pi)*sqrt(-cos(x) + 1)

Expected:
    -1/2*(1/18*sqrt(23)*sqrt(3) - 1/2)^(1/3)*(I*sqrt(3) + 1) - 1/6*(-I*sqrt(3) + 1)/(1/18*sqrt(23)*sqrt(3) - 1/2)^(1/3)
Got:
    -1/2*(1/18)^(1/3)*(sqrt(23)*sqrt(3) - 9)^(1/3)*(I*sqrt(3) + 1) - 3*(1/18)^(2/3)*(-I*sqrt(3) + 1)/(sqrt(23)*sqrt(3) - 9)^(1/3)

Expected:
    -1/8*sqrt(5) + 1/4*sqrt(-3/2*sqrt(5) + 15/2) - 1/8
Got:
    1/4*sqrt(3/2)*sqrt(-sqrt(5) + 5) - 1/8*sqrt(5) - 1/8

Expected:
    1/4*sqrt(-2*sqrt(6) - 2*sqrt(2) + 8)
Got:
    1/4*sqrt(2)*sqrt(-sqrt(6) - sqrt(2) + 4)

That sqrt(23)*sqrt(3) is not combined should be addressed elsewhere.

[rwst]

Changed upstream from Fixed upstream, in a later stable release. to none

[rwst]

Changed dependencies from pynac-0.7.10 to pynac-0.7.14

[rwst]

comment:13

There would be 30 doctest changes in the 5 main symbolic directories alone. I'm not prepared to push this as default behaviour---but maybe as separate method.

[rwst]

comment:14

The code has been archived at: pynac/pynac#292

[EmmanuelCharpentier]

comment:15

Replying to @rwst:

There would be 30 doctest changes in the 5 main symbolic directories alone. I'm not prepared to push this as default behaviour

Exactly why I got cold feet with the (much smaller) distribution of a few operations over sum and product, and created distribute. Seconded.

---but maybe as separate method.

canonicalize_power(s) (parallel to canonicalize_radical) ?

Another possibility to discuss : extend canonicalize_radical : same category of operations, but this would change its definition.

[rwst]

comment:16

Yes, third possibility is to extend factor with a powers=True argument. In any case I need to think about how to implement it conditionally in Pynac.

[rwst]

Changed dependencies from pynac-0.7.14 to none