Opened 3 years ago
Last modified 8 weeks ago
#24523 needs_work enhancement
Change string representation of RealField
Reported by:  vdelecroix  Owned by:  

Priority:  major  Milestone:  sage9.4 
Component:  basic arithmetic  Keywords:  
Cc:  Merged in:  
Authors:  Vincent Delecroix, Ralf Stephan, Michael Jung  Reviewers:  Vincent Klein, Vincent Delecroix 
Report Upstream:  N/A  Work issues:  
Branch:  u/ghmjungmath/24523 (Commits, GitHub, GitLab)  Commit:  7f7d902bfdfd7f6f76052d525b62ddea8bd86256 
Dependencies:  Stopgaps: 
Description (last modified by )
We change the string representation of RealField(XXX)
from
Real Field with XX bits of precision
to
Real FloatingPoint Field with XX bits of precision
The reason for this change is that "Real Field" is not precise enough. Beyond floatingpoint, "Real Field" could equivalently be used for fixedpoint, intervals and balls. The standard terms in the literature are "floatingpoint arithmetic", "fixedpoint arithmetic", "ball arithmetic" and "interval arithmetic", see eg
 https://en.wikipedia.org/wiki/Floatingpoint_arithmetic
 https://en.wikipedia.org/wiki/Interval_arithmetic
 https://hal.archivesouvertes.fr/hal00432152v3/
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 FloatingPoint 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\1FloatingPoint 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 sagedevel.
Change History (58)
comment:1 Changed 3 years ago by
 Description modified (diff)
comment:2 Changed 3 years ago by
 Dependencies set to #24511
comment:3 Changed 3 years ago by
comment:4 Changed 3 years ago by
 Branch set to u/rws/24523
comment:5 Changed 3 years ago by
 Commit set to 137c4b86a53540d5f4b35e855d0ce2f259c58bcb
 Status changed from new to needs_review
comment:6 followup: ↓ 8 Changed 3 years ago by
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 floatingpoint, so do you plan to use Real Floatingpoint Interval Field
and Real Floatingpoint Ball Field
too?
comment:7 Changed 3 years ago by
And anyway, this kind of things has to be agreed on on sagedevel.
comment:8 in reply to: ↑ 6 ; followup: ↓ 27 Changed 3 years ago by
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 floatingpoint, so do you plan to use
Real Floatingpoint Interval Field
andReal Floatingpoint 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 "floatingpoint arithmetic", "ball arithmetic" and "interval arithmetic".
comment:9 Changed 3 years ago by
 Status changed from needs_review to needs_work
This already accumulates merge conflicts en masse.
comment:10 Changed 3 years ago by
 Description modified (diff)
comment:11 Changed 3 years ago by
 Branch changed from u/rws/24523 to u/vdelecroix/24523
 Commit changed from 137c4b86a53540d5f4b35e855d0ce2f259c58bcb to 4ab32e260c336708eea59d4fa5f7e7c508dd859c
 Milestone changed from sage8.2 to sage8.3
 Status changed from needs_work to needs_review
NOT to be merged: just testing what patchbots have to say...
New commits:
4ab32e2  24523: "Real Field" > "Real Floatingpoint Field"

comment:12 Changed 3 years ago by
 Description modified (diff)
comment:13 Changed 3 years ago by
 Dependencies #24511 deleted
comment:14 Changed 3 years ago by
 Description modified (diff)
comment:15 Changed 3 years ago by
 Commit changed from 4ab32e260c336708eea59d4fa5f7e7c508dd859c to e3a54e68ec9cfa986176f89b57affb2fec3a3dfe
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
e3a54e6  24523: "Real Field" > "Real Floatingpoint Field"

comment:16 Changed 3 years ago by
 Description modified (diff)
comment:17 Changed 3 years ago by
 Status changed from needs_review to needs_work
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 2dimensional 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 2dimensional differentiable manifold M in Category of smooth manifolds over Real Floatingpoint 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 2dimensional 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 2dimensional differentiable manifold M in Join of Category of subobjects of sets and Category of smooth manifolds over Real Floatingpoint 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 Floatingpoint 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 2dimensional topological manifold R^2 to 2dimensional 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 2dimensional topological manifold R^2 to 2dimensional topological manifold R^2 in Join of Category of subobjects of sets and Category of manifolds over Real Floatingpoint 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 2space 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 2space over Real Floatingpoint 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 Floatingpoint 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 Floatingpoint 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!
comment:18 Changed 3 years ago by
 Description modified (diff)
comment:19 Changed 3 years ago by
 Description modified (diff)
comment:20 Changed 3 years ago by
 Commit changed from e3a54e68ec9cfa986176f89b57affb2fec3a3dfe to cf8cd1182337ff695c0b351bbeb36e27eed32798
comment:21 Changed 3 years ago by
 Status changed from needs_work to needs_review
an other patchbot round...
comment:22 Changed 3 years ago by
 Status changed from needs_review to positive_review
s = "Real Floatingpoint 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#printfstylestringformatting).
comment:23 Changed 3 years ago by
 Status changed from positive_review to needs_work
comment:24 Changed 3 years ago by
 Reviewers set to Vincent Klein
comment:25 Changed 3 years ago by
 Milestone changed from sage8.3 to sage8.4
update milestone 8.3 > 8.4
comment:26 Changed 7 months ago by
What was wrong with the first approach? Just the remark in comment:22?
comment:27 in reply to: ↑ 8 ; followup: ↓ 28 Changed 7 months ago by
Replying to vdelecroix:
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 floatingpoint, so do you plan to use
Real Floatingpoint Interval Field
andReal Floatingpoint 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 "floatingpoint 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.
comment:28 in reply to: ↑ 27 Changed 7 months ago by
Replying to ghmjungmath:
Replying to vdelecroix:
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 floatingpoint, so do you plan to use
Real Floatingpoint Interval Field
andReal Floatingpoint 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 "floatingpoint 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.
comment:29 Changed 7 months ago by
 Description modified (diff)
 Milestone changed from sage8.4 to sage9.3
comment:30 Changed 7 months ago by
 Branch changed from u/vdelecroix/24523 to u/ghmjungmath/24523
comment:31 Changed 7 months ago by
 Commit changed from cf8cd1182337ff695c0b351bbeb36e27eed32798 to f98454667fe2f5029f3091bbac807b2adabc760c
 Status changed from needs_work to needs_review
comment:32 Changed 7 months ago by
 Commit changed from f98454667fe2f5029f3091bbac807b2adabc760c to df1cd07d4def5bf79b46442614bda07cca0a6fa6
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

comment:33 Changed 7 months ago by
 Commit changed from df1cd07d4def5bf79b46442614bda07cca0a6fa6 to 1bc1b61c003420a7f2028da9f14d677bcbf6ce5b
comment:34 Changed 7 months ago by
 Description modified (diff)
comment:35 Changed 7 months ago by
pyflakes errors seem unrelated. Apart from that, patchbot is green.
comment:36 Changed 7 months ago by
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 sagedevel.
comment:37 Changed 7 months ago by
 Description modified (diff)
comment:38 Changed 7 months ago by
 Description modified (diff)
comment:39 Changed 7 months ago by
What is best "Floatingpoint" or "FloatingPoint"?
comment:40 Changed 7 months ago by
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.
Besides, full capitalization looks better imho. :)
comment:41 Changed 7 months ago by
This is great since I would like to use the shortcut RFPF
(in place of RR
) which fits better the capitalization.
comment:42 Changed 7 months ago by
I'll change it soon with a forced push.
comment:43 Changed 7 months ago by
Good. If you update the ticket description as well it will even be better.
comment:44 Changed 7 months ago by
 Commit changed from 1bc1b61c003420a7f2028da9f14d677bcbf6ce5b to e4a1d7564df5f062b3e3a3842c75add1d5d6b264
comment:45 Changed 7 months ago by
 Description modified (diff)
comment:46 Changed 7 months ago by
There we go.
comment:47 Changed 7 months ago by
 Reviewers changed from Vincent Klein to Vincent Klein, Vincent Delecroix
Thanks. If neither patchbot nor developers complain I will set a positive review.
comment:48 followup: ↓ 54 Changed 7 months ago by
Do we have a followup for Complex Field
? Because it has the same problem.
comment:49 Changed 6 months ago by
rebase please
comment:50 in reply to: ↑ description Changed 4 months ago by
It was asked on the sagedevel discussion whether people have an opinion.
Replying to ticket description:
We change the string representation of
RealField(XXX)
fromReal Field with XX bits of precisionto
Real FloatingPoint Field with XX bits of precision
+1 from me
comment:51 Changed 4 months ago by
 Commit changed from e4a1d7564df5f062b3e3a3842c75add1d5d6b264 to 93cb1a2d43f4e6380a17b54c5e608795ebb4d000
comment:52 Changed 4 months ago by
 Commit changed from 93cb1a2d43f4e6380a17b54c5e608795ebb4d000 to 050aa3d2b20ba742d59510c92a0328c5150f1061
comment:53 Changed 4 months ago by
 Commit changed from 050aa3d2b20ba742d59510c92a0328c5150f1061 to 7f7d902bfdfd7f6f76052d525b62ddea8bd86256
comment:54 in reply to: ↑ 48 Changed 4 months ago by
comment:55 followup: ↓ 56 Changed 4 months ago by
I wonder a bit about the changes in src/sage/tests/books/
. Is that how it should be?
comment:56 in reply to: ↑ 55 Changed 4 months ago by
Replying to ghmjungmath:
I wonder a bit about the changes in
src/sage/tests/books/
. Is that how it should be?
Yes
comment:58 Changed 8 weeks ago by
 Milestone changed from sage9.3 to sage9.4
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
I first changed
find .
tofind src
because I was in thesage
top directory. Then I addedg
after/
to replace multiple occurences of the pattern in one line. When applying the script there were several things that needed manual adaptation: intests/french_book/nonlinear_doctest.py
the print command of a doctest had to be changed to ensure aesthetic results. Also the script picks upconf.py
files undersrc/doc
and for some reasons git thinks it has to delete them and create them new, so I git checked out the originals of allsrc/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.