Opened 3 years ago
Closed 22 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: | sage-9.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(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...
Change History (20)
comment:1 follow-up: ↓ 4 Changed 3 years 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 3 years 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 3 years ago by
- Owner changed from was to (none)
Sorry, I must have inavertently assigned this ticket to "was".
comment:4 in reply to: ↑ 1 ; follow-up: ↓ 5 Changed 3 years ago by
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 ?
comment:5 in reply to: ↑ 4 Changed 3 years 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 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
|
comment:6 Changed 3 years ago by
- Milestone changed from sage-9.0 to sage-9.1
comment:7 Changed 2 years ago by
- Commit changed from af20e1f8b94d3fdfc8943260e93934fe8bea21c1 to 0c2b2696fe173db5fdb9a3110ead0b95c200859f
comment:8 Changed 2 years 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 2 years ago by
comment:10 Changed 2 years ago by
- Milestone changed from sage-9.1 to sage-9.2
Moving tickets to milestone sage-9.2 based on a review of last modification date, branch status, and severity.
comment:11 Changed 2 years ago by
- Cc yzh added
comment:12 follow-up: ↓ 15 Changed 22 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.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
comment:13 Changed 22 months ago by
- Commit changed from 0c2b2696fe173db5fdb9a3110ead0b95c200859f to 37c5e193d9229517fd24be077f2e6cf2fc82b9b2
- Status changed from positive_review to needs_review
comment:14 follow-ups: ↓ 16 ↓ 18 Changed 22 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 22 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.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!
comment:16 in reply to: ↑ 14 Changed 22 months ago by
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 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 22 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 22 months ago by
- Status changed from needs_review to positive_review
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 toSR(RR('1.3'))
rather thanSR(RDF('1.3'))
.
OK, this works.
comment:19 Changed 22 months ago by
Thank you.
comment:20 Changed 22 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.