Opened 18 months ago
Closed 8 months ago
#28814 closed defect (fixed)
Conversion of scientific notation floats/RDF,etc... incorrect in Mathematica interface
Reported by:  charpent  Owned by:  

Priority:  major  Milestone:  sage9.2 
Component:  interfaces  Keywords:  mathematica conversions 
Cc:  yzh  Merged in:  
Authors:  Markus Wageringel  Reviewers:  Dima Pasechnik 
Report Upstream:  N/A  Work issues:  
Branch:  37c5e19 (Commits, GitHub, GitLab)  Commit:  37c5e193d9229517fd24be077f2e6cf2fc82b9b2 
Dependencies:  Stopgaps: 
Description
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(1e8).n() 1.00000000000000e8 # Fails when converted to mathematica: sage: mathematica.N(mathematica.Sin(1e8)).sage() 1.0*sin(1.0*e + 8.0) # Same possible cause sage: mathematica.N(mathematica.Sin(1e8)).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.124576406741286e218
...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...
Change History (20)
comment:1 followup: ↓ 4 Changed 18 months ago by
 Component changed from interfaces to interfaces: optional
 Summary changed from Conversion of scientific notation floats/RDF,etc... incorrect to Conversion of scientific notation floats/RDF,etc... incorrect in Mathematica interface
comment:2 Changed 18 months ago by
 Component changed from interfaces: optional to interfaces
 Owner changed from (none) to was
The Mathematica interface is standard (as is Maple's). What is optional is having Mathematica (or Maple) installed...
comment:3 Changed 18 months ago by
 Owner changed from was to (none)
Sorry, I must have inavertently assigned this ticket to "was".
comment:4 in reply to: ↑ 1 ; followup: ↓ 5 Changed 18 months ago by
Replying to ghmwageringel:
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 largeabsolutemagnitude floats ?
comment:5 in reply to: ↑ 4 Changed 17 months ago by
 Branch set to public/28814
 Commit set to af20e1f8b94d3fdfc8943260e93934fe8bea21c1
 Status changed from new to needs_info
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 largeabsolutemagnitude 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 Mathematicaconversion of floatingpoint numbers

comment:6 Changed 17 months ago by
 Milestone changed from sage9.0 to sage9.1
comment:7 Changed 15 months ago by
 Commit changed from af20e1f8b94d3fdfc8943260e93934fe8bea21c1 to 0c2b2696fe173db5fdb9a3110ead0b95c200859f
comment:8 Changed 15 months ago by
 Status changed from needs_info to needs_review
I have fixed the remaining doctest failures, so this could be reviewed.
comment:9 Changed 15 months ago by
comment:10 Changed 13 months ago by
 Milestone changed from sage9.1 to sage9.2
Moving tickets to milestone sage9.2 based on a review of last modification date, branch status, and severity.
comment:11 Changed 10 months ago by
 Cc yzh added
comment:12 followup: ↓ 15 Changed 8 months ago by
 Reviewers set to Dima Pasechnik
 Status changed from needs_review to positive_review
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.51v7l+ #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
comment:13 Changed 8 months ago by
 Commit changed from 0c2b2696fe173db5fdb9a3110ead0b95c200859f to 37c5e193d9229517fd24be077f2e6cf2fc82b9b2
 Status changed from positive_review to needs_review
comment:14 followups: ↓ 16 ↓ 18 Changed 8 months ago by
 Stopgaps Cast those inconvenient quantities to rationals deleted
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.
comment:15 in reply to: ↑ 12 Changed 8 months ago by
Replying to dimpase:
Tested with Mathematica 12 that comes free on Raspberry Pi 4. There the equivalent of
math
command iswolfram
, so I created a symbolic link namedmath
in my PATH to point towolfram
. :)$ uname a Linux raspberrypi 5.4.51v7l+ #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!
comment:16 in reply to: ↑ 14 Changed 8 months ago by
Replying to ghmwageringel:
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 toSR(RR('1.3'))
rather thanSR(RDF('1.3'))
.Nice to see that this work with a Raspberry Pi. On Linux, the
math
andwolfram
scripts appear to be equal. I cannot find any documentation aboutmath
, so perhaps we should just replace it bywolfram
– 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?
comment:17 Changed 8 months ago by
On macOS, neither is provided; one needs to use /Applications/Mathematica.app/Contents//MacOS/WolframKernel
comment:18 in reply to: ↑ 14 Changed 8 months ago by
 Status changed from needs_review to positive_review
Replying to ghmwageringel:
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 toSR(RR('1.3'))
rather thanSR(RDF('1.3'))
.
OK, this works.
comment:19 Changed 8 months ago by
Thank you.
comment:20 Changed 8 months ago by
 Branch changed from public/28814 to 37c5e193d9229517fd24be077f2e6cf2fc82b9b2
 Resolution set to fixed
 Status changed from positive_review to closed
Another workaround to avoid scientific notation:
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.