classes for the fields of complex and real numbers

[videlec]

We create (mostly abstract) classes to model the set of complex and real numbers as sage.rings.complex_field.ComplexField and sage.rings.real_field.RealField.

See also task ticket #17713.

Use cases for this new "real field" object:

1. As some placeholder object to denote the field of real numbers, for example as output of QQ.completion(oo), for domain/codomain of symbolic functions, in manifolds, etc. This implies that it should be a unique object.

2. As a Sage analogy to PEP 3141: it should provide a way to ask "is x a real number" or "is X a substructure of the reals" or maybe "does parent X represent the real numbers". Also, we should be able to ask "is x an exact or approximate real number". Note that Sage already has partial support for PEP 3141 but only for elements (not parents).

3. As a class factory for all concrete real fields (e.g. the create_RealField function that is currently used for non-exact approximations).

Depends on #24464
Depends on #24465
Depends on #24483
Depends on #24457

CC: @rwst @tscrim @egourgoulhon @mjungmath

Component: basic arithmetic

Work Issues: merge conflict

Author: Vincent Delecroix

Branch/Commit: u/rws/24456 @ febfe35

Issue created by migration from https://trac.sagemath.org/ticket/24456

[tscrim]

comment:2

+1

[videlec]

comment:3

:-) pushing in a minute...

[videlec]

Author: Vincent Delecroix

[videlec]

Commit: 78f677e

[videlec]

New commits:

78f677e

24456: class for the field of real numbers

[videlec]

Branch: u/vdelecroix/24456

[sagetrac-git]

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

62d2d21

24456: class for the field of real numbers

[sagetrac-git]

Changed commit from 78f677e to 62d2d21

[rwst]

comment:10

For me this looks fine (I can now create the object and use it in formal expressions) and patchbot is green. If you think this is not enough for a review then please set back to "needs review".

[rwst]

comment:12

Thanks. I also had a question turning up while working on #24457. The code here does not support RealField(prec) anymore---the init method only has self argument, is this intended? Since real_mpfr.RealField() will be renamed should create_RealField(prec) be used everywhere instead?

[videlec]

comment:13

Replying to @rwst:

Thanks. I also had a question turning up while working on #24457. The code here does not support RealField(prec) anymore---the init method only has self argument, is this intended?

It is intended: the field of real number is the field of real number (see e.g. wikipedia). The code provided in the branch u/vdelecroix/24456 is new, so it never used to support anything.

Since real_mpfr.RealField() will be renamed should create_RealField(prec) be used everywhere instead?

No. create_RealField is a convenience to handle options for the completion functor. There is no reason to use it directly.

The real_field.RealField in this branch has (almost) nothing to do with real_mpfr.RealField.

[tscrim]

comment:14

Some comments:

• I think the completion of ZZ should be in a separate ticket for better granularity.
• Similarly for changing the output of CompletionFunctor to have prec.
• Should be "field of real numbers".
• Why the check for façade sets in those tests? Are tests failing otherwise? I don't think they should be necessary...
• It would be nice if RealField could be a common ABC for all classes that model R, but that is not possible because it inherits from Singleton (IMO, is a shortcoming of that class, but that is a different issue).

[jdemeyer]

comment:15

I don't quite understand the purpose of this new RealField. Maybe it would be good to elaborate on that.

Why is this thing a Parent? Given that it doesn't have Elements (in the Sage sense), it probably should be a CategoryObject and not a Parent.

[videlec]

comment:39

Replying to @jdemeyer:

Maybe we should start by thinking about possible use cases for this "real field":

1. As some placeholder object to denote the field of real numbers, for example as output of QQ.completion(oo). This implies that it should be a unique object.

Agreed.

2. As a Sage analogy to PEP 3141: it should provide a way to ask "is x a real number" or "is X a substructure of the reals" or maybe "does parent X represent the real numbers". Note that Sage already has partial support for PEP 3141 but only for elements (not parents).

I want to be able distinguish between exact subrings and non-exact approximations. This is for coercion reasons: each exact subring coerces into all non-exact approximations. This is also why I claimed that 0.1 in R should be False.

Let me add

3. As a way to check for is x an exact real number? and is x a non-exact real number?. We should specify clearly that isinstance(x, numbers.Real) means exact real or non-exact real (I take that as given because both issubclass(int, numbers.Real) and issubclass(float, numbers.Real) are True).

4. As a pointers to all real field implementations (exact subrings and non-exact approximations). In particular it should contain a class factory for all concrete real fields (e.g. the create_RealField function that is currently used for non-exact approximations).

[tscrim]

comment:40

If you want to ask about exact reals, you should have a 2', where you have a subclass of generic all reals class for the exact reals.

[videlec]

comment:41

Concerning approximations (like floating point numbers), there are often the three special values NaN, +inf and -inf which are not real numbers (in the mathematical sense). For -inf and +inf one can still argue that they approximate very negative and very positive reals. But NaN is not an approximation of anything. This is one more argument for having RealField() to mean exact real numbers.

On the other hand, Python numbers.Real means both floating and exact. Having different semantic for RealField() and numbers.Real might be disturbing.

[jdemeyer]

comment:42

Replying to @videlec:

This is also why I claimed that 0.1 in R should be False.

I still don't get this. Please elaborate...

[jdemeyer]

comment:44

Replying to @videlec:

4. As a pointers to all real field implementations (exact subrings and non-exact approximations). In particular it should contain a class factory for all concrete real fields (e.g. the create_RealField function that is currently used for non-exact approximations).

What is the it in this last sentence?

[videlec]

comment:45

Replying to @jdemeyer:

Replying to @videlec:

This is also why I claimed that 0.1 in R should be False.

I still don't get this. Please elaborate...

For me RealField means the field of real numbers in the mathematical sense together with its exact operations +, -, log, exp, etc. Floating-point numbers do not respect exactness of operations and for me do not qualify as being real numbers. I agree that you can think of a floating point number in two ways. As an approximation of a real number "m ± 2^-e" or as a diadic number "p 2^-n". The latter is the actual datastructure but it is mostly useless to think of it this way when doing mathematics. This is moreover how it works in Sage: QQ coerces into RealField(prec) and not the contrary even though RealField(prec) is formally a subset of QQ.

[videlec]

comment:46

Replying to @jdemeyer:

Replying to @videlec:

4. As a pointers to all real field implementations (exact subrings and non-exact approximations). In particular it should contain a class factory for all concrete real fields (e.g. the create_RealField function that is currently used for non-exact approximations).

What is the it in this last sentence?

I meant the genuine real field that we are trying to design.

[jdemeyer]

comment:47

Replying to @videlec:

I meant the genuine real field that we are trying to design.

OK, so what would it mean for a Python object (representing the real field) to "contain a class factory"? Do you want something like

sage: R = RealField()
sage: R.create(prec=53, implementation="mpfr")
Real Floating-point field with 53 bits of precision

or maybe

sage: R = RealField()
sage: R(prec=53, implementation="mpfr")
Real Floating-point field with 53 bits of precision

[jdemeyer]

comment:48

Replying to @videlec:

For me RealField means the field of real numbers in the mathematical sense together with its exact operations +, -, log, exp, etc. Floating-point numbers do not respect exactness of operations and for me do not qualify as being real numbers.

That point of view is technically mathematically true but also completely useless. Clearly, the real floating-point field is meant to model the real numbers. For technical reasons, the operations are not exact. But that is an implementation detail and not a mathematical property. For practical purposes, it behaves as a field.

I do agree that it makes sense to differentiate between exact real fields and approximate real fields, but both are real fields.

[videlec]

comment:49

Replying to @jdemeyer:

Replying to @videlec:

For me RealField means the field of real numbers in the mathematical sense together with its exact operations +, -, log, exp, etc. Floating-point numbers do not respect exactness of operations and for me do not qualify as being real numbers.

That point of view is technically mathematically true but also completely useless. Clearly, the real floating-point field is meant to model the real numbers.

Indeed!

For technical reasons, the operations are not exact. But that is an implementation detail and not a mathematical property. For practical purposes, it behaves as a field.

It is not associative! Equality dramatically fails! This is not a detail.

I do agree that it makes sense to differentiate between exact real fields and approximate real fields, but both are real fields.

I also agree and IMHO, for consistency with numbers.Real, the genuine RealField should be both used for approximate (= projection) and exact (= subset). And this should be very clearly stated.

[rwst]

Changed branch from u/vdelecroix/24456 to u/rws/24456

[rwst]

comment:52

Rebased on the dependency.

---

New commits:

875c231	24483: merge complex_number/complex_field into complex_mpfr
f3ed18c	24483: fix interpreters
14c9753	24483: fix imports and doctests
1fdb61c	Merge branch 'develop' into t/24483/24483
aefb4df	24483: fix import
febfe35	Merge branch 'u/vdelecroix/24456' of git://trac.sagemath.org/sage into tmp18

[rwst]

Changed commit from 62d2d21 to febfe35

[dkrenn]

Work Issues: merge conflict

[dkrenn]

comment:53

Does not apply anymore.

[mjungmath]

comment:54

I think, this is a splendid idea. What can be done to stress this forward? Can I help?

[videlec]

comment:56

Replying to @mjungmath:

I think, this is a splendid idea. What can be done to stress this forward? Can I help?

Indeed, it was a terrible design from the start. The main obstruction to change it is backward compatibility... You can work on any of #24483, #24489 and #24457 that are prerequisite for this ticket.