#22894 closed enhancement (fixed)

Symbolic expression.is_exact()

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

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 22 months ago by mforets

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 22 months ago by rws

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 22 months ago by mforets

  • Cc tmonteil 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 22 months ago by tmonteil

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 22 months ago by tmonteil

See #22960.

comment:6 Changed 21 months ago by mforets

  • Authors set to Marcelo Forets
  • Branch set to u/mforets/22894
  • Commit set to c011cfada9c95d0ded5057c8e88b1b1cfd9d7d31
  • Status changed from new to needs_review

@Thierry: that is indeed a comprehensive list :0

comment:7 Changed 21 months ago by git

  • Commit changed from c011cfada9c95d0ded5057c8e88b1b1cfd9d7d31 to adf17b5dd863867e4bf578b5053fbd5898080d15

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

adf17b5add is_exact method to SR

comment:8 Changed 21 months ago by rws

  • Reviewers set to Ralf Stephan
  • Status changed from needs_review to positive_review

LGTM.

comment:9 Changed 21 months ago by vbraun

  • Branch changed from u/mforets/22894 to adf17b5dd863867e4bf578b5053fbd5898080d15
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.