Opened 5 years ago

Closed 5 years ago

#22894 closed enhancement (fixed)

Symbolic expression.is_exact()

Reported by: Ralf Stephan Owned by:
Priority: major Milestone: sage-8.0
Component: symbolics Keywords:
Cc: Thierry Monteil Merged in:
Authors: Marcelo Forets Reviewers: Ralf Stephan
Report Upstream: N/A Work issues:
Branch: adf17b5 (Commits, GitHub, GitLab) Commit: adf17b5dd863867e4bf578b5053fbd5898080d15
Dependencies: Stopgaps:

Status badges

Description

Expressions can contain inexact elements which makes themselves inexact. This status could be made queriable e.g. to prevent integration attempts.

Change History (9)

comment:1 Changed 5 years ago by Marcelo Forets

how do you approach this problem? since numeric coefficients are cast into SR which is inexact, one has:

sage: f1 = x - 1
sage: [op.base_ring().is_exact() for op in f1.operands()]
[False, False]

sage: f2 = x - 1.0
sage: [op.base_ring().is_exact() for op in f2.operands()]
[False, False]

comment:2 Changed 5 years ago by Ralf Stephan

Apparently ring exactness can be tainted if it can possibly contain inexact elements. So we would not check the exactness of symbols/functions etc. which leaves those Python objects that are wrapped by SR (into Expression) and called "numeric". We can get the pure object via Expression.pyobject(), e.g.

sage: f1 = x - 1
sage: [op.is_numeric() and not op.pyobject().base_ring().is_exact() for op in f1
....: .operands()]
[False, False]
sage: f2 = x - 1.0
sage: [op.is_numeric() and not op.pyobject().base_ring().is_exact() for op in f2
....: .operands()]
[False, True]

But maybe not every of these rings has an is_exact member?

comment:3 Changed 5 years ago by Marcelo Forets

Cc: Thierry Monteil added

@rws : nice. and one can consider more complicated expressions (fractions, etc) by recursively applying the operands() method to each piece (until you get []).

But maybe not every of these rings has an is_exact member?

I know the basic ones: (QQ, QQbar, ZZ) have is_exact=True while (RDF, RR, CC) give is_exact=False.. But Thierry has a comprehensive list so I'm CC'ing him!

comment:4 Changed 5 years ago by Thierry Monteil

Regarding real and complex numbers only, basically, numerical representations are inexact:

RealDoubleField()
RealField(prec)
RealIntervalField(prec)
RealBallField(prec)
ComplexDoubleField()
ComplexField(prec)
ComplexIntervalField(prec)
ComplexBallField(prec)

Algebraic representations are exact:

AlgebraicRealField()
NumberField(poly)
QuadraticField(n)
RationalField()
AlgebraicField()
UniversalCyclotomicField()
CyclotomicField(n)

Symbolic ring is a mixture, so it is inexact.

The main problem are RealLazyField() and ComplexLazyField() which claim to be exact, but they are not:

sage: a = RLF(0.1)
sage: a
0.10000000000000001?
sage: a._value
0.100000000000000
sage: a._value.parent()
Real Field with 53 bits of precision
sage: RLF.is_exact()
True

Perhaps should we fix this.

comment:5 Changed 5 years ago by Thierry Monteil

See #22960.

comment:6 Changed 5 years ago by Marcelo Forets

Authors: Marcelo Forets
Branch: u/mforets/22894
Commit: c011cfada9c95d0ded5057c8e88b1b1cfd9d7d31
Status: newneeds_review

@Thierry: that is indeed a comprehensive list :0

comment:7 Changed 5 years ago by git

Commit: c011cfada9c95d0ded5057c8e88b1b1cfd9d7d31adf17b5dd863867e4bf578b5053fbd5898080d15

Branch pushed to git repo; I updated commit sha1. New commits:

adf17b5add is_exact method to SR

comment:8 Changed 5 years ago by Ralf Stephan

Reviewers: Ralf Stephan
Status: needs_reviewpositive_review

LGTM.

comment:9 Changed 5 years ago by Volker Braun

Branch: u/mforets/22894adf17b5dd863867e4bf578b5053fbd5898080d15
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.