Regression: Many mathematica doctests now fail

[flawrence]

Since #3587, which implements a _sage_() method for mathematica elements, many mathematica doctests fail. E.g:

sage: def math_bessel_K(nu,x): 
     ...       return mathematica(nu).BesselK(x).N(20).sage() 
     ... 
     sage: math_bessel_K(2,I) 
NotImplementedError: Unable to parse 
Mathematica output: 
-2.5928861754911969781676606702635284285719718407749199115289`20.1494653502 82203 
+ 
0.1804899720669620266296208808560650432663536549483055754141`18.99213497581 376*i 

[flawrence]

Before #3587, mathematica's output was sent to ExpectElement?._sage_repr() in expect.py, which called repr() and tidied up the results (converting {} to [], stripping new line characters etc) then sage_eval() was called on the results. With this approach, mathematica functions that returned numbers, symbolic variables or arrays could be imported successfully into sage. The approach had the disadvantage that all symbolic variables had to be passed in manually as locals, and that functions couldn't be translated from mathematica to their equivalents in sage.

#3587 instead calls str() on mathematica's results (which has the alarming option ascii_art = True), then replaces []s by (), changes everything to lower case and sends it to SR. This works for simple functions but fails for arrays and probably anything affected by ascii_art = True

I'm not familiar with SR, but at a minimum MathematicaElement?._sage_() should be patched to call sage_repr() instead of str(). I don't know whether SR has all the functionality of sage_eval(), e.g. supporting arrays.

[flawrence]

I've uploaded a patch that has a thorough rewrite of MathematicaElement?._sage_() to get the functionality from #3587 while keeping the functionality from before it (lists, complex numbers, numbers in scientific notation...). I still need to write some documentation for the top of the file (i.e. documentation that makes it into the reference manual) but before I do that and submit this for formal review I'd like wise comments about my approach, e.g. "The way you convert function names is really inefficient and problematic, do it this way...", or "You can efficiently get a list of all sage functions recognised by sage_eval() by ...".

Also if someone could check the doctests on a 32-bit computer and let me know the result that they get instead of [[1.00000000000000, 4], pi, 3.20000000000000*e100, I] that would be grand.

[flawrence]

I've updated the patch file so that it updates the Mathematica module documentation. This needs to be doctested on a 32-bit computer at some point.

[mhansen]

There is dictionary in place from Mathematica to Sage.

sage: sage.symbolic.pynac.symbol_table['mathematica']
{'Log[2]': log2, 'Cos': cos, 'DiracDelta': dirac_delta, 'EulerGamma': euler_gamma, 'Glaisher': glaisher, 'Sqrt': <function sqrt at 0x2c20f50>, 'Factorial': factorial, 'Khinchin': khinchin, 'Catalan': catalan, '(1+Sqrt[5])/2': golden_ratio, 'Binomial': binomial, 'PolyGamma': psi, 'HeavisideTheta': heaviside, 'KroneckerDelta': kronecker_delta, 'Pi': pi, 'UnitStep': unit_step, 'Sin': sin, 'Gamma': gamma, 'Sign': sgn}

This is constructed at runtime and is filled in by the init methods of the functions and constants.

[whuss]

Replying to flawrence:

I've uploaded a patch that has a thorough rewrite of MathematicaElement?._sage_() to get the functionality from #3587 while keeping the functionality from before it (lists, complex numbers, numbers in scientific notation...). I still need to write some documentation for the top of the file (i.e. documentation that makes it into the reference manual) but before I do that and submit this for formal review I'd like wise comments about my approach, e.g. "The way you convert function names is really inefficient and problematic, do it this way...", or "You can efficiently get a list of all sage functions recognised by sage_eval() by ...". Also if someone could check the doctests on a 32-bit computer and let me know the result that they get instead of [[1.00000000000000, 4], pi, 3.20000000000000*e100, I] that would be grand.

On 32-bit Debian I get the same output. There is only one doctest failure:

./sage -t  -only-optional=mathematica "devel/sage/sage/interfaces/mathematica.py"
sage -t -only-optional=mathematica "devel/sage/sage/interfaces/mathematica.py"
**********************************************************************
File "./sage-4.4.4/devel/sage/sage/interfaces/mathematica.py", line 281:
    sage: math_bessel_K(2,I)                      # optional - mathematica
Expected:
    0.180489972066962*I - 2.592886175491197
Got:
    -2.59288617549119697816765132253822887 + 0.180489972066962026629620880838378650*I
**********************************************************************

But this is probably unrelated to this patch, since also without this patch applied I get things like:

sage: mathematica('N[Pi, 1]')
3.1415926535897932385
sage: mathematica('N[Pi, 10]')
3.1415926535897932385
sage: mathematica('N[Pi, 11]')
3.1415926535897932384626433836

[flawrence]

Replying to mhansen:

There is dictionary in place from Mathematica to Sage.

sage: sage.symbolic.pynac.symbol_table['mathematica']
{'Log[2]': log2, 'Cos': cos, 'DiracDelta': dirac_delta, 'EulerGamma': euler_gamma, 'Glaisher': glaisher, 'Sqrt': <function sqrt at 0x2c20f50>, 'Factorial': factorial, 'Khinchin': khinchin, 'Catalan': catalan, '(1+Sqrt[5])/2': golden_ratio, 'Binomial': binomial, 'PolyGamma': psi, 'HeavisideTheta': heaviside, 'KroneckerDelta': kronecker_delta, 'Pi': pi, 'UnitStep': unit_step, 'Sin': sin, 'Gamma': gamma, 'Sign': sgn}

Excellent! I've updated the patch so that it uses that dictionary. I also added the ability to pass a locals dictionary to _sage_, which complements and/or overrides the symbol_tablemathematica? dictionary.

The documentation for this function won't be very visible, since it starts with an underscore, so I was contemplating setting up a mathematica-specific .sage function that accepts a locals dictionary and has a copy of this documentation. In the end I didn't do this because I don't understand the consequences (or why there are separate _sage_ and sage functions at all). Opinions?

Replying to whuss:

On 32-bit Debian I get the same output. There is only one doctest failure:

But this is probably unrelated to this patch, since also without this patch applied I get things like:

Yes, I'm not sure it's related to the patch either. For the record I get the correct behaviour with the patch:

sage: mathematica('N[Pi, 1]')
3.1
sage: mathematica('N[Pi, 10]')
3.1415926536
sage: mathematica('N[Pi, 11]')
3.14159265359