Conversion of scientific notation floats/RDF,etc... incorrect in Mathematica interface

[charpent]

Exploration of a problem reported in an ​ask.sagemath question.

The conversion of large or small floating point constants (needing scientific notation) to mathematica is incorrect:

# Reference
sage: 3.5.log().n()
1.25276296849537
# This works
sage: mathematica.N(mathematica.Log(3.5)).sage()
1.252762968495368
# Scale up works in Sage:
sage: 3.5e6.log().n()
15.0682735264596
# Doesn't work when translated to to mathematica
sage: mathematica.N(mathematica.Log(3.5e6)).sage()
log(3.5*e6)
# Possible cause : confusion with SR
sage: mathematica.N(mathematica.Log(3.5e6)).sage().parent()
Symbolic Ring
# Ditto for small values. OK in Sage
sage: sin(1e-8).n()
1.00000000000000e-8
# Fails when converted to mathematica:
sage: mathematica.N(mathematica.Sin(1e-8)).sage()
-1.0*sin(-1.0*e + 8.0)
# Same possible cause
sage: mathematica.N(mathematica.Sin(1e-8)).sage().parent()
Symbolic Ring

The reverse conversion (Mathematica --> Sage) works...

sage: mathematica.N(mathematica.Exp(500))
1.4035922178528375*^217
sage: mathematica.N(mathematica.Exp(500)).sage()
1.4035922178528375e+217
sage: mathematica.N(mathematica.Exp(-500))
7.124576406741286*^-218
sage: mathematica.N(mathematica.Exp(-500)).sage()
7.124576406741286e-218

...as long as Sage is able to express it:

sage: mathematica.N(mathematica.Exp(1000))
1.970071114017*^434
sage: mathematica.N(mathematica.Exp(1000)).sage()
+infinity
sage: mathematica.N(mathematica.Exp(-1000))
5.0759588975495*^-435
sage: mathematica.N(mathematica.Exp(-1000)).sage()
0.0

The latter quantities over/underflow the default Sage floating point systems...

[gh-mwageringel]

Another workaround to avoid scientific notation:

sage: mathematica.Log(3.5e6.str(no_sci=2)).sage()
15.068273526459642

The overflows might be difficult to avoid since that is a problem of SR, and the symbolic ring is the closest thing in Sage that Mathematica expressions can convert to.

[charpent]

The Mathematica interface is standard (as is Maple's). What is optional is having Mathematica (or Maple) installed...

[charpent]

Sorry, I must have inavertently assigned this ticket to "was".

[charpent]

Replying to gh-mwageringel:

Another workaround to avoid scientific notation:

sage: mathematica.Log(3.5e6.str(no_sci=2)).sage()
15.068273526459642

Thanks ! I was unaware of this one...

The overflows might be difficult to avoid since that is a problem of SR, and the symbolic ring is the closest thing in Sage that Mathematica expressions can convert to.

Indeed. That's a consequence of ​IEE 754. Do we need Mathematica's large-absolute-magnitude floats ?

[gh-mwageringel]

Replying to charpent:

The overflows might be difficult to avoid since that is a problem of SR, and the symbolic ring is the closest thing in Sage that Mathematica expressions can convert to.

Indeed. That's a consequence of ​IEE 754. Do we need Mathematica's large-absolute-magnitude floats ?

Actually I was wrong about SR – it does support arbitrary precision floating point numbers. The conversion from Mathematica to Sage treats them as elements of RDF before embedding them in SR, though. Here is a branch where they are converted to elements of RealField instead which automatically chooses a suitable precision.

Moreover, I implemented the conversions from Sage to Mathematica for elements of RDF, CDF, RealField and ComplexField in order to handle the scientific notation.

---

These changes have the potential for some numerical noise. The function symbolic_expression_from_string is also used by SR to create expressions from strings, so floating point numbers parsed from strings are now backed by RealField elements instead of RDF. This is also why some tests in sandpiles fail with the current branch.

sage: SR('.3333333333333333333333333333333333333')  # before: internally an element of RDF
0.3333333333333333
sage: SR('.3333333333333333333333333333333333333')  # after: now internally an element of RealField
0.333333333333333333333333333333333333
sage: SR(.3333333333333333333333333333333333333)    # unaffected by these changes
0.333333333333333333333333333333333333

Is it ok to change this? It seems desirable to preserve the precision here, but I am not sure if this might have other negative consequences.

---

New commits:

​af20e1f

28814: fix Mathematica-conversion of floating-point numbers

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​6e82b76	28814: fix Mathematica-conversion of floating-point numbers
​0c2b269	28814: fix mathematica doctests in sandpiles

[gh-mwageringel]

I have fixed the remaining doctest failures, so this could be reviewed.

[mkoeppe]

Moving tickets to milestone sage-9.2 based on a review of last modification date, branch status, and severity.

[dimpase]

Tested with Mathematica 12 that comes free on Raspberry Pi 4. There the equivalent of math command is wolfram, so I created a symbolic link named math in my PATH to point to wolfram. :-)

$ uname -a
Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux
$ ls -l `which math`
lrwxrwxrwx 1 pi pi 16 Sep  8 11:22 /home/pi/bin/math -> /usr/bin/wolfram

[git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

​b6cd28b	28814: Merge tag '9.2.beta12' into #28814
​37c5e19	28814: fix libgiac doctest

[gh-mwageringel]

Sorry, there was a failing doctest in the file src/sage/libs/giac/giac.pyx which has recently been added. The failure was due to the fact that, after this ticket, SR('1.3') is equivalent to SR(RR('1.3')) rather than SR(RDF('1.3')).

Nice to see that this work with a Raspberry Pi. On Linux, the math and wolfram scripts appear to be equal. I cannot find any documentation about math, so perhaps we should just replace it by wolfram – though, I am not sure about the situation on other platforms.

[mkoeppe]

Replying to dimpase:

Tested with Mathematica 12 that comes free on Raspberry Pi 4. There the equivalent of math command is wolfram, so I created a symbolic link named math in my PATH to point to wolfram. :-)

$ uname -a
Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux
$ ls -l `which math`
lrwxrwxrwx 1 pi pi 16 Sep  8 11:22 /home/pi/bin/math -> /usr/bin/wolfram

Imagine a Beowulf cluster of these!

[dimpase]

Replying to gh-mwageringel:

Sorry, there was a failing doctest in the file src/sage/libs/giac/giac.pyx which has recently been added. The failure was due to the fact that, after this ticket, SR('1.3') is equivalent to SR(RR('1.3')) rather than SR(RDF('1.3')).

Nice to see that this work with a Raspberry Pi. On Linux, the math and wolfram scripts appear to be equal. I cannot find any documentation about math, so perhaps we should just replace it by wolfram – though, I am not sure about the situation on other platforms.

math was the name until some versions ago, then in version 11 (or maybe earlier) one got both wolfram and math.

Perhaps, add a runtime check for the correct name?

[mkoeppe]

On macOS, neither is provided; one needs to use /Applications/Mathematica.app/Contents//MacOS/WolframKernel

[dimpase]

Replying to gh-mwageringel:

Sorry, there was a failing doctest in the file src/sage/libs/giac/giac.pyx which has recently been added. The failure was due to the fact that, after this ticket, SR('1.3') is equivalent to SR(RR('1.3')) rather than SR(RDF('1.3')).

OK, this works.

[gh-mwageringel]

Thank you.