Change string representation of RealField

[videlec]

We change the string representation of RealField(XXX) from

Real Field with XX bits of precision

to

Real Floating-Point Field with XX bits of precision

The reason for this change is that "Real Field" is not precise enough. Beyond floating-point, "Real Field" could equivalently be used for fixed-point, intervals and balls. The standard terms in the literature are "floating-point arithmetic", "fixed-point arithmetic", "ball arithmetic" and "interval arithmetic", see eg

• ​https://en.wikipedia.org/wiki/Floating-point_arithmetic
• ​https://en.wikipedia.org/wiki/Interval_arithmetic
• ​https://hal.archives-ouvertes.fr/hal-00432152v3/

This ticket is part of a the refactorization #24457 that intends to clean computations involving the different kinds of real numbers.

The git branch was obtained by running the following command in $SAGE_ROOT/src

for file in $(grep -l "Real Field with" $(find . -name "*pyx" -o -name "*py" -o -name "*pxd" -o -name "*rst" -type f))
  do sed -i "s/Real Field with/Real Floating-Point Field with/g" $file
done

Tests work fine except for doctests that involves an output with a linebreak such as

sage: x = polygen(RR); r = (1 + x)/(1 - x^2); r.parent()
Fraction Field of Univariate Polynomial Ring in x over Real
Field with 53 bits of precision

(from src/sage/tests/french_book/polynomes.py line 218). These can also be handled using multiline sed replacement

for file in $(find . -name "*pyx" -o -name "*py" -o -name "*pxd" -o -name "*rst" -type f)
do
  sed -Ei '{N; s/Real(\s+)Field(\s+)with/Real\1Floating-Point Field\2with/; ty; P; D; :y}' $file
done

As part of this ticket, the printf percentage syntax has been changed to the newer Python 3 standard format syntax (see comment:22) in all real field representations.

---

Related discussion on sage-devel.

Component: basic arithmetic

Author: Vincent Delecroix, Ralf Stephan, Michael Jung

Branch/Commit: u/gh-mjungmath/24523 @ 7f7d902

Reviewer: Vincent Klein, Vincent Delecroix

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

[videlec]

Description changed:

--- 
+++ 
@@ -8,3 +8,11 @@

Real Floating-point Field with XX bits of precision

+
+Easy one
+
+```
+for file in $(find . -name "*pyx" -o -name "*py" -o -name "*rst");
+  do sed -i "s/Real Field with \([0-9]\+\) bits of precision/Real Floating-point Field with \1 bits of precision/" $file;
+done
+```

[videlec]

Dependencies: #24511

[rwst]

comment:3

I first changed find . to find src because I was in the sage top directory. Then I added g after / to replace multiple occurences of the pattern in one line. When applying the script there were several things that needed manual adaptation: in tests/french_book/nonlinear_doctest.py the print command of a doctest had to be changed to ensure aesthetic results. Also the script picks up conf.py files under src/doc and for some reasons git thinks it has to delete them and create them new, so I git checked out the originals of all src/doc/en/reference/*/conf.py files. The remaining doctest fails appear to be instances of split lines and, according to recent comments by Jeroen which I agree with, that if the output is one line the doctest output should be too, I joined those lines and replaced the pattern.

[rwst]

Branch: u/rws/24523

[rwst]

Commit: 137c4b8

[rwst]

comment:5

Also there was one doctest change in a pxd file. 127 files were changed.

---

New commits:

a782296	24511: Move create_RealField to real_field.py
977f62d	24511 deprecation
137c4b8	24523: Change string representation of RealField

[rwst]

Changed author from Vincent Delecroix to Vincent Delecroix, Ralf Stephan

[jdemeyer]

comment:6

Sorry to spoil the party, but what is wrong with "Real Field with XX bits of precision"? Doesn't the "XX bits of precision" imply already that it's floating point? I think that the shorter name Real Field is sufficient.

Note that also balls and intervals are floating-point, so do you plan to use Real Floating-point Interval Field and Real Floating-point Ball Field too?

[videlec]

comment:7

And anyway, this kind of things has to be agreed on on sage-devel.

[videlec]

comment:8

Replying to @jdemeyer:

Sorry to spoil the party, but what is wrong with "Real Field with XX bits of precision"? Doesn't the "XX bits of precision" imply already that it's floating point? I think that the shorter name Real Field is sufficient.

Note that also balls and intervals are floating-point, so do you plan to use Real Floating-point Interval Field and Real Floating-point Ball Field too?

The rationale is: not precise enough. The "Real Field with XX bits of precision" could equivalently be used for intervals and balls. The standard terms in the literature are "floating-point arithmetic", "ball arithmetic" and "interval arithmetic".

[rwst]

comment:9

This already accumulates merge conflicts en masse.

[videlec]

Description changed:

--- 
+++ 
@@ -12,7 +12,7 @@
 Easy one

-for file in $(find . -name "pyx" -o -name "py" -o -name "rst"); +for file in $(grep -l "Real Field" $(find . -name "pyx" -o -name "py" -o -name "rst")) do sed -i "s/Real Field with ([0-9]+) bits of precision/Real Floating-point Field with \1 bits of precision/" $file; done

[videlec]

comment:11

NOT to be merged: just testing what patchbots have to say...

---

New commits:

4ab32e2

24523: "Real Field" -> "Real Floating-point Field"

[videlec]

Changed commit from 137c4b8 to 4ab32e2

[videlec]

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

[videlec]

Description changed:

--- 
+++ 
@@ -9,7 +9,9 @@
 Real Floating-point Field with XX bits of precision

-Easy one +Beyond #24457, the reason for this change is that "Real Field" is not precise enough. It could equivalently be used for intervals and balls. The standard terms in the literature are "floating-point arithmetic", "ball arithmetic" and "interval arithmetic". + +The git branch was obtained by running the following command in $SAGE_ROOT/src

 for file in $(grep -l "Real Field" $(find . -name "*pyx" -o -name "*py" -o -name "*rst"))

[videlec]

Changed dependencies from #24511 to none

[videlec]

Description changed:

--- 
+++ 
@@ -15,6 +15,6 @@

for file in $(grep -l "Real Field" $(find . -name "pyx" -o -name "py" -o -name "*rst"))

• do sed -i "s/Real Field with ([0-9]+) bits of precision/Real Floating-point Field with \1 bits of precision/" $file;
• do sed -i "s/Real Field with ([0-9]+) bits of precision/Real Floating-point Field with \1 bits of precision/g" $file; done

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

e3a54e6

24523: "Real Field" -> "Real Floating-point Field"

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 4ab32e2 to e3a54e6

[videlec]

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-As a subtask of #24457 we change the string representation of `RealField(XXX)` from
+We change the string representation of `RealField(XXX)` from

Real Field with XX bits of precision @@ -9,12 +9,14 @@ Real Floating-point Field with XX bits of precision

-Beyond #24457, the reason for this change is that "Real Field" is not precise enough. It could equivalently be used for intervals and balls. The standard terms in the literature are "floating-point arithmetic", "ball arithmetic" and "interval arithmetic". 
+The reason for this change is that "Real Field" is not precise enough. Beyond floating-point, "Real Field" could equivalently be used for fixed-point, intervals and balls. The standard terms in the literature are "floating-point arithmetic", "fixed-point arithmetic", "ball arithmetic" and "interval arithmetic".
+
+This ticket is part of a the refactorization #24457 that intends to clean  computations involving the different kinds of real numbers.

 The git branch was obtained by running the following command in `$SAGE_ROOT/src`

-for file in $(grep -l "Real Field" $(find . -name "pyx" -o -name "py" -o -name "*rst"))

• do sed -i "s/Real Field with ([0-9]+) bits of precision/Real Floating-point Field with \1 bits of precision/g" $file; +for file in $(grep -l "Real Field with" $(find . -name "pyx" -o -name "py" -o -name "pxd" -o -name "rst" -type f))
• do sed -i "s/Real Field with/Real Floating-point Field with/g" $file done

[videlec]

comment:17

At least

sage -t --long src/sage/manifolds/differentiable/manifold_homset.py
**********************************************************************
File "src/sage/manifolds/differentiable/manifold_homset.py", line 258, in sage.manifolds.differentiable.manifold_homset.DifferentiableCurveSet
Failed example:
    H = Hom(R, M) ; H
Expected:
    Set of Morphisms from Real number line R to 2-dimensional
     differentiable manifold M in Category of smooth manifolds over Real
     Field with 53 bits of precision
Got:
    Set of Morphisms from Real number line R to 2-dimensional differentiable manifold M in Category of smooth manifolds over Real Floating-point Field with 53 bits of precision
**********************************************************************
File "src/sage/manifolds/differentiable/manifold_homset.py", line 290, in sage.manifolds.differentiable.manifold_homset.DifferentiableCurveSet
Failed example:
    H = Hom(I, U) ; H
Expected:
    Set of Morphisms from Real interval (0, 1) to Open subset U of the
     2-dimensional differentiable manifold M in Join of Category of
     subobjects of sets and Category of smooth manifolds over Real Field
     with 53 bits of precision
Got:
    Set of Morphisms from Real interval (0, 1) to Open subset U of the 2-dimensional differentiable manifold M in Join of Category of subobjects of sets and Category of smooth manifolds over Real Floating-point Field with 53 bits of precision
**********************************************************************
1 item had failures:
   2 of  35 in sage.manifolds.differentiable.manifold_homset.DifferentiableCurveSet
    [344 tests, 2 failures, 19.00 s]

sage -t --long src/sage/schemes/generic/algebraic_scheme.py
**********************************************************************
File "src/sage/schemes/generic/algebraic_scheme.py", line 1802, in sage.schemes.generic.algebraic_scheme.AlgebraicScheme_subscheme.change_ring
Failed example:
    X.change_ring(RR)
Expected:
    Closed subscheme of Projective Space of dimension 1 over Real Field
    with 53 bits of precision defined by:
      x - 1.73205080756888*y
Got:
    Closed subscheme of Projective Space of dimension 1 over Real Floating-point Field with 53 bits of precision defined by:
      x - 1.73205080756888*y
**********************************************************************
1 item had failures:
   1 of  46 in sage.schemes.generic.algebraic_scheme.AlgebraicScheme_subscheme.change_ring
    [397 tests, 1 failure, 2.45 s]

sage -t --long src/sage/manifolds/continuous_map.py
**********************************************************************
File "src/sage/manifolds/continuous_map.py", line 254, in sage.manifolds.continuous_map.ContinuousMap
Failed example:
    Phi.parent()
Expected:
    Set of Morphisms from Open subset D of the 2-dimensional topological
     manifold R^2 to 2-dimensional topological manifold R^2 in Join of
     Category of subobjects of sets and Category of manifolds over Real
     Field with 53 bits of precision
Got:
    Set of Morphisms from Open subset D of the 2-dimensional topological manifold R^2 to 2-dimensional topological manifold R^2 in Join of Category of subobjects of sets and Category of manifolds over Real Floating-point Field with 53 bits of precision
**********************************************************************
1 item had failures:
   1 of  79 in sage.manifolds.continuous_map.ContinuousMap
    [359 tests, 1 failure, 18.44 s]

sage -t --long src/sage/geometry/voronoi_diagram.py
**********************************************************************
File "src/sage/geometry/voronoi_diagram.py", line 167, in sage.geometry.voronoi_diagram.VoronoiDiagram.points
Failed example:
    V = VoronoiDiagram([[.5, 3], [2, 5], [4, 5], [4, -1]]); V.points()
Expected:
    A point configuration in affine 2-space over Real Field
    with 53 bits of precision consisting of 4 points.
    The triangulations of this point configuration are
    assumed to be connected, not necessarily fine,
    not necessarily regular.
Got:
    A point configuration in affine 2-space over Real Floating-point Field with 53 bits of precision consisting of 4 points. The triangulations of this point configuration are assumed to be connected, not necessarily fine, not necessarily regular.
**********************************************************************
1 item had failures:
   1 of   2 in sage.geometry.voronoi_diagram.VoronoiDiagram.points
    [32 tests, 1 failure, 2.53 s]

sage -t --long src/sage/tests/french_book/polynomes.py
**********************************************************************
File "src/sage/tests/french_book/polynomes.py", line 218, in sage.tests.french_book.polynomes
Failed example:
    x = polygen(RR); r = (1 + x)/(1 - x^2); r.parent()
Expected:
    Fraction Field of Univariate Polynomial Ring in x over Real
    Field with 53 bits of precision
Got:
    Fraction Field of Univariate Polynomial Ring in x over Real Floating-point Field with 53 bits of precision
**********************************************************************
1 item had failures:
   1 of 108 in sage.tests.french_book.polynomes
    [107 tests, 1 failure, 1.73 s]
sage -t --long src/sage/schemes/generic/scheme.py
**********************************************************************
File "src/sage/schemes/generic/scheme.py", line 223, in sage.schemes.generic.scheme.Scheme.__call__
Failed example:
    A(RR)
Expected:
    Set of rational points of Affine Space of dimension 2 over Real Field
    with 53 bits of precision
Got:
    Set of rational points of Affine Space of dimension 2 over Real Floating-point Field with 53 bits of precision
**********************************************************************
1 item had failures:
   1 of  12 in sage.schemes.generic.scheme.Scheme.__call__
    [182 tests, 1 failure, 0.98 s]

.. so not so many!

[videlec]

Description changed:

--- 
+++ 
@@ -20,3 +20,18 @@
   do sed -i "s/Real Field with/Real Floating-point Field with/g" $file
 done

+Tests work fine except for doctests that involves an output with a linebreak such as + + +sage: x = polygen(RR); r = (1 + x)/(1 - x^2); r.parent() +Fraction Field of Univariate Polynomial Ring in x over Real +Field with 53 bits of precision + +(from src/sage/tests/french_book/polynomes.py line 218). These can also be handled using multiline sed replacement + +``` +for file in $(find . -name "pyx" -o -name "py" -o -name "pxd" -o -name "rst" -type f) +do

• sed -Ei '{N; s/Real(\s+)Field(\s+)with/Real\1Floating-Point Field\2with/; ty; P; D; :y}' $file +done +```

[videlec]

Description changed:

--- 
+++ 
@@ -32,6 +32,6 @@

for file in $(find . -name "pyx" -o -name "py" -o -name "pxd" -o -name "rst" -type f) do

• sed -Ei '{N; s/Real(\s+)Field(\s+)with/Real\1Floating-Point Field\2with/; ty; P; D; :y}' $file
• sed -Ei '{N; s/Real(\s+)Field(\s+)with/Real\1Floating-point Field\2with/; ty; P; D; :y}' $file done

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

f006ea1	24523: "Real Field" -> "Real Floating-point Field"
cf8cd11	24523: fix multiline doctests

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from e3a54e6 to cf8cd11

[videlec]

comment:21

an other patchbot round...

[4a781b2b-eada-4ae4-9b46-f6cbb63459b9]

comment:22

s = "Real Floating-point Field with %s bits of precision"%self.__prec

Maybe we should use format instead of printf syntax(percent) as it seems to be the standard way to do it in python 3 (stdtypes.html#printf-style-string-formatting).

[4a781b2b-eada-4ae4-9b46-f6cbb63459b9]

Reviewer: Vincent Klein

[videlec]

comment:25

update milestone 8.3 -> 8.4

[mjungmath]

comment:26

What was wrong with the first approach? Just the remark in comment:22?

[mjungmath]

comment:27

Replying to @videlec:

Replying to @jdemeyer:

Sorry to spoil the party, but what is wrong with "Real Field with XX bits of precision"? Doesn't the "XX bits of precision" imply already that it's floating point? I think that the shorter name Real Field is sufficient.

Note that also balls and intervals are floating-point, so do you plan to use Real Floating-point Interval Field and Real Floating-point Ball Field too?

The rationale is: not precise enough. The "Real Field with XX bits of precision" could equivalently be used for intervals and balls. The standard terms in the literature are "floating-point arithmetic", "ball arithmetic" and "interval arithmetic".

Can you give a reference? Maybe also in the description? Then the reasoning could more comprehensible. I don't know the details here neither.

[videlec]

comment:28

Replying to @mjungmath:

Replying to @videlec:

Replying to @jdemeyer:

Sorry to spoil the party, but what is wrong with "Real Field with XX bits of precision"? Doesn't the "XX bits of precision" imply already that it's floating point? I think that the shorter name Real Field is sufficient.

Note that also balls and intervals are floating-point, so do you plan to use Real Floating-point Interval Field and Real Floating-point Ball Field too?

The rationale is: not precise enough. The "Real Field with XX bits of precision" could equivalently be used for intervals and balls. The standard terms in the literature are "floating-point arithmetic", "ball arithmetic" and "interval arithmetic".

Can you give a reference? Maybe also in the description? Then the reasoning could more comprehensible. I don't know the details here neither.

• https://en.wikipedia.org/wiki/Floating-point_arithmetic
• https://en.wikipedia.org/wiki/Interval_arithmetic
• https://hal.archives-ouvertes.fr/hal-00432152v3/

[videlec]

Description changed:

--- 
+++ 
@@ -9,7 +9,11 @@
 Real Floating-point Field with XX bits of precision

-The reason for this change is that "Real Field" is not precise enough. Beyond floating-point, "Real Field" could equivalently be used for fixed-point, intervals and balls. The standard terms in the literature are "floating-point arithmetic", "fixed-point arithmetic", "ball arithmetic" and "interval arithmetic". +The reason for this change is that "Real Field" is not precise enough. Beyond floating-point, "Real Field" could equivalently be used for fixed-point, intervals and balls. The standard terms in the literature are "floating-point arithmetic", "fixed-point arithmetic", "ball arithmetic" and "interval arithmetic", see eg

• +- ​https://en.wikipedia.org/wiki/Floating-point_arithmetic +- ​https://en.wikipedia.org/wiki/Interval_arithmetic +- ​https://hal.archives-ouvertes.fr/hal-00432152v3/

  This ticket is part of a the refactorization #24457 that intends to clean computations involving the different kinds of real numbers.

[mjungmath]

Changed branch from u/vdelecroix/24523 to u/gh-mjungmath/24523

[mjungmath]

Changed commit from cf8cd11 to f984546

[mjungmath]

comment:31

I used the former approach and applied it to the recent version of Sage. Furthermore, I replaced the printf syntax.

---

New commits:

b673b5a	Trac #24523: py3 string formatting + "Real Field" -> "Real Floating-point Field"
f984546	Trac #24523: py3 print foormat

[mjungmath]

Changed author from Vincent Delecroix, Ralf Stephan to Vincent Delecroix, Ralf Stephan, Michael Jung

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

df1cd07

Trac #24523: py3 print format for real interval field

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from f984546 to df1cd07

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

9481d77	Trac 24523: "Real Field" -> "Real Floating-point Field"
1bc1b61	Trac 24523: doctests adapted

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from df1cd07 to 1bc1b61

[videlec]

Description changed:

--- 
+++ 
@@ -39,3 +39,5 @@
   sed -Ei '{N; s/Real(\s+)Field(\s+)with/Real\1Floating-point Field\2with/; ty; P; D; :y}' $file
 done

+ +Related discussion on sage-devel.

[mjungmath]

comment:35

pyflakes errors seem unrelated. Apart from that, patchbot is green.

[videlec]

comment:36

It is definitely a positive review on my side. However, I would like to wait a bit because of the message I posted this morning on sage-devel.

[mjungmath]

Description changed:

--- 
+++ 
@@ -40,4 +40,4 @@
 done

-Related discussion on sage-devel. +Related discussion on sage-devel.

[mjungmath]

Description changed:

--- 
+++ 
@@ -40,4 +40,8 @@
 done

+As part of this ticket, the printf percentage syntax has been changed to the Python 3 standard format syntax (see comment:22) in all real field representations. + +--- + Related discussion on sage-devel.

[videlec]

comment:39

What is best "Floating-point" or "Floating-Point"?

[mjungmath]

comment:40

I googled it. I think, common sense in titles is a capitalization of the subsequent hyphen elements if they are e.g. nouns, which is the case here.

https://www.accu-assist.com/grammar-tips-archive/GrammarTip_capitalization-titles-headings-hyphenated-words.htm

Besides, full capitalization looks better imho. :)

[videlec]

comment:41

This is great since I would like to use the shortcut RFPF (in place of RR) which fits better the capitalization.