Final Pynac Switchover Push for Sage-4.0

See also http://trac.sagemath.org/sage_trac/ticket/5930

Latest Pynac spkg

sage -f -m http://sage.math.washington.edu/home/mhansen/pynac-0.1.6-mh.spkg

Note that we do "-f -m" so that spkg/build/pynac-0.1.6-mh is left around. Now you can do 

./sage -sh
cd spkg/build/pynac-0.1.6-mh/src/ginac
# change anything
make install

Mike's Repo

On sage.math, do 

hg pull -u /scratch/mhansen/sage-3.4.2.alpha0-sage.math-only-x86_64-Linux/devel/sage-symbolics#symbolics_switch

And don't forget to do this from SAGE_ROOT: 

rm devel/sage/build/*/sage/symbolic/constants*; rm devel/sage/build/sage/symbolic/constants.so

Contents

  1. Final Pynac Switchover Push for Sage-4.0
    1. Latest Pynac spkg
    2. Mike's Repo
    3. Unpickling of old SymbolicExpressions
    4. (DONE) A serious printing BUG
    5. (DONE) sqrt(2)^2
    6. (DONE) sqrt(16)
    7. (DONE) Missing parentheses
    8. (DONE) Missing mathematica conversions
    9. pynac gcd broken
    10. Number Fields
    11. (DONE) Formal Derivatives
    12. Doctest Grunt Work
    13. Massive Speed Regressions
    14. (DONE) I = sqrt(-1)
    15. Doctest status: May 9
    16. Doctest status: May 7-8

Unpickling of old SymbolicExpressions

For backward compatibility, we need to be able to unpickle the old symbolic objects.

(DONE) A serious printing BUG

sage: var('A,B,n')
(A, B, n)
sage: (A*B)^n
A*B^n
sage: f = (A*B)^n; f(A=5,B=5)
25^n

It's just a printing bug. Also we have 

sage: n*x^(n-1)
n*x^((n - 1))

http://sage.math.washington.edu/home/wstein/symbolics/pynac-fix_printing.patch

and 

http://sage.math.washington.edu/home/wstein/symbolics/trac_5930-some_symbolic_doctests.patch
http://sage.math.washington.edu/home/wstein/symbolics/trac_5930-some_symbolic_doctests-part2-add_pyrepr.patch

(DONE) sqrt(2)^2

sage: sqrt(x)^2
x
sage: sqrt(2)^2
sqrt(2)^2

wstein@sage:~$ ginsh 
ginsh - GiNaC Interactive Shell (ginac V1.4.1)
...
> sqrt(2)^2;
2

Fix at http://sage.math.washington.edu/home/robertwb/patches/pynac-sqrt.patch

(DONE) sqrt(16)

sage: sqrt(SR(16))
sqrt(16)
sage: 27^(1/3)
27^(1/3)

$ ginsh
> sqrt(16);
4
> 27 ^ (1/3);
3

Fix at http://sage.math.washington.edu/home/robertwb/patches/pynac-pow.patch however 

sage: sqrt(27)
sqrt(27)

refuses to be simplified (despite the code to do so being executed).

(DONE) Missing parentheses

sage: a = (2/3) ^ (2/3); str(a)
'2/3^(2/3)'
sage: latex(a)
\frac{2}{3}^{\frac{2}{3}}
sage: (-x)^(1/4)
-x^(1/4)

(DONE) Missing mathematica conversions

All should be capitalized: 

sage: (tan(x) + exp(x) + sin(x))._mathematica_init_()
 '(exp[x])+(Sin[x])+(tan[x])'

(seems like something we could do generically).

* Fixed in Mike's branch.

pynac gcd broken

sage: var('n,x')
(n, x)
sage: g= (n+1)/x^n - n/x^n 
sage: g.collect_common_factors() 
/home/wstein/build/sage-3.4.2-symbolics/local/bin/sage-sage: line 198: 29952 Segmentation fault      sage-ipython "$@" -i

Since the change in the definition of gcd of rational numbers in Sage, the gcd in pynac doesn't terminate in some cases. This can crash Sage as above. A quick fix might be to change sage.symbolic.pynac.py_gcd to handle gcd of rationals as before. AFAIK, collect_common_factors() is the only function we expose to the user that calls gcd() in pynac. -- burcin

The above isn't the solution, unfortunately. Putting print statements in py_gcd shows it is never called with rational input for the above example. In fact it isn't even called by the collect_common_factors line. What happens is that there is an infinite recurssion in normal.cpp involving convering something to a polynomial.

Number Fields

(DONE) Formal Derivatives

Doctest Grunt Work

Massive Speed Regressions

Pynac on May 9:

sage: _=var('x,y,z'); f=expand((x+y+z)^6); g=f+1
sage: timeit('(f*g).expand()')
5 loops, best of 3: 241 ms per loop

SAGE-3.2.3 with pynac:
sage: _=var('x,y,z',ns=1); f=expand((x+y+z)^6); g=f+1
sage: timeit('(f*g).expand()')
125 loops, best of 3: 3.19 ms per loop

Singular:
sage: R.<x,y,z> = QQ[]; f=(x+y+z)^6; g=f+1
sage: timeit('h=f*g')
625 loops, best of 3: 29.7 µs per loop

SAGE-3.2.3 (using Maxima on clisp; on ecl it can do this 3-4 times as fast):
sage: _=var('x,y,z'); f=expand((x+y+z)^6); g=f+1
sage: timeit('(f*g).expand()')
5 loops, best of 3: 118 ms per loop

(DONE) I = sqrt(-1)

Mike:  I think what we want is just a QQ*I ring which automatically goes to SR when you do arithmetic with anything outside of it.
 me:  ok.
You suggested that before, and it makes some sense.
Can't we just make a quadratic number field, and enhance it a tiny spec.
 Mike:  I think if we had that, then everything should work out.
 Sent at 11:31 AM on Thursday
 me:  That sounds easy enough, and it would be super fast, since quadratic fields are very very fast.
 Mike:  We just don't have an exact way to work with complex numbers.
 me:  robertwb could whip it out, as he wrote quadratic fields, etc.
 Mike:  Yep
For RR we have QQ, but we don't have quite an analogue for CC.

Doctest status: May 9

The failures as of May 9 at 4:19pm are here:

http://sage.math.washington.edu/home/wstein/build/sage-sym/test-all-2.out

Doctests fail in 59 distinct files.

Doctest status: May 7-8

As of right now -- May 7 at 11:38 am, doing

results in http://sage.math.washington.edu/home/wstein/build/sage-3.4.2-symbolics/test-all.out

Nearly all of the errors have to do with sqrt, specifically, 

sage: sqrt(SR(16))
 sqrt(16)
sage: sqrt(16 + x - x)
 sqrt(16)

and 

$ grep "CombinatorialFreeModule instance as first argument" /home/wstein/build/sage-3.4.2-symbolics/test-all.out | wc
    240    4080   34320

The issue is that ginac treats sqrt(x) as having an ambiguous sign, whereas before we choose a branch. The symbolic sqrt(perfect_square) is used all over in the library, so I think we need to allow this. We should not, however, simplify sqrt(x^2).