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: sage-9.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/gh-mjungmath/24523 (Commits, GitHub, GitLab) Commit: 7f7d902bfdfd7f6f76052d525b62ddea8bd86256
Dependencies: Stopgaps:

Status badges

Description (last modified by gh-mjungmath)

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

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.

Change History (58)

comment:1 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:2 Changed 3 years ago by vdelecroix

  • Dependencies set to #24511

comment:3 Changed 3 years ago by rws

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.

comment:4 Changed 3 years ago by rws

  • Branch set to u/rws/24523

comment:5 Changed 3 years ago by rws

  • Authors changed from Vincent Delecroix to Vincent Delecroix, Ralf Stephan
  • Commit set to 137c4b86a53540d5f4b35e855d0ce2f259c58bcb
  • Status changed from new to needs_review

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


New commits:

a78229624511: Move create_RealField to real_field.py
977f62d24511 deprecation
137c4b824523: Change string representation of RealField

comment:6 follow-up: Changed 3 years ago by 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?

comment:7 Changed 3 years ago by vdelecroix

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

comment:8 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by 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 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".

comment:9 Changed 3 years ago by rws

  • Status changed from needs_review to needs_work

This already accumulates merge conflicts en masse.

comment:10 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:11 Changed 3 years ago by vdelecroix

  • Branch changed from u/rws/24523 to u/vdelecroix/24523
  • Commit changed from 137c4b86a53540d5f4b35e855d0ce2f259c58bcb to 4ab32e260c336708eea59d4fa5f7e7c508dd859c
  • Milestone changed from sage-8.2 to sage-8.3
  • Status changed from needs_work to needs_review

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


New commits:

4ab32e224523: "Real Field" -> "Real Floating-point Field"

comment:12 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:13 Changed 3 years ago by vdelecroix

  • Dependencies #24511 deleted

comment:14 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:15 Changed 3 years ago by git

  • Commit changed from 4ab32e260c336708eea59d4fa5f7e7c508dd859c to e3a54e68ec9cfa986176f89b57affb2fec3a3dfe

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

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

comment:16 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:17 Changed 3 years ago by vdelecroix

  • 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 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!

comment:18 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:19 Changed 3 years ago by vdelecroix

  • Description modified (diff)

comment:20 Changed 3 years ago by git

  • Commit changed from e3a54e68ec9cfa986176f89b57affb2fec3a3dfe to cf8cd1182337ff695c0b351bbeb36e27eed32798

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

f006ea124523: "Real Field" -> "Real Floating-point Field"
cf8cd1124523: fix multiline doctests

comment:21 Changed 3 years ago by vdelecroix

  • Status changed from needs_work to needs_review

an other patchbot round...

comment:22 Changed 3 years ago by vklein

  • Status changed from needs_review to positive_review
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).

comment:23 Changed 3 years ago by vklein

  • Status changed from positive_review to needs_work

comment:24 Changed 3 years ago by vklein

  • Reviewers set to Vincent Klein

comment:25 Changed 3 years ago by vdelecroix

  • Milestone changed from sage-8.3 to sage-8.4

update milestone 8.3 -> 8.4

comment:26 Changed 7 months ago by gh-mjungmath

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

comment:27 in reply to: ↑ 8 ; follow-up: Changed 7 months ago by gh-mjungmath

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 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.

comment:28 in reply to: ↑ 27 Changed 7 months ago by vdelecroix

Replying to gh-mjungmath:

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 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.

comment:29 Changed 7 months ago by vdelecroix

  • Description modified (diff)
  • Milestone changed from sage-8.4 to sage-9.3

comment:30 Changed 7 months ago by gh-mjungmath

  • Branch changed from u/vdelecroix/24523 to u/gh-mjungmath/24523

comment:31 Changed 7 months ago by gh-mjungmath

  • Authors changed from Vincent Delecroix, Ralf Stephan to Vincent Delecroix, Ralf Stephan, Michael Jung
  • Commit changed from cf8cd1182337ff695c0b351bbeb36e27eed32798 to f98454667fe2f5029f3091bbac807b2adabc760c
  • Status changed from needs_work to needs_review

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


New commits:

b673b5aTrac #24523: py3 string formatting + "Real Field" -> "Real Floating-point Field"
f984546Trac #24523: py3 print foormat

comment:32 Changed 7 months ago by git

  • Commit changed from f98454667fe2f5029f3091bbac807b2adabc760c to df1cd07d4def5bf79b46442614bda07cca0a6fa6

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

df1cd07Trac #24523: py3 print format for real interval field

comment:33 Changed 7 months ago by git

  • Commit changed from df1cd07d4def5bf79b46442614bda07cca0a6fa6 to 1bc1b61c003420a7f2028da9f14d677bcbf6ce5b

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

9481d77Trac 24523: "Real Field" -> "Real Floating-point Field"
1bc1b61Trac 24523: doctests adapted

comment:34 Changed 7 months ago by vdelecroix

  • Description modified (diff)

comment:35 Changed 7 months ago by gh-mjungmath

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

comment:36 Changed 7 months ago by vdelecroix

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.

comment:37 Changed 7 months ago by gh-mjungmath

  • Description modified (diff)

comment:38 Changed 7 months ago by gh-mjungmath

  • Description modified (diff)

comment:39 Changed 7 months ago by vdelecroix

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

comment:40 Changed 7 months ago by gh-mjungmath

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. :)

Last edited 7 months ago by gh-mjungmath (previous) (diff)

comment:41 Changed 7 months ago by vdelecroix

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 gh-mjungmath

I'll change it soon with a forced push.

comment:43 Changed 7 months ago by vdelecroix

Good. If you update the ticket description as well it will even be better.

comment:44 Changed 7 months ago by git

  • Commit changed from 1bc1b61c003420a7f2028da9f14d677bcbf6ce5b to e4a1d7564df5f062b3e3a3842c75add1d5d6b264

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

ca51262Trac 24523: "Real Field" -> "Real Floating-Point Field" + new formatting style
e4a1d75Trac #24523: doctests adapted

comment:45 Changed 7 months ago by gh-mjungmath

  • Description modified (diff)

comment:46 Changed 7 months ago by gh-mjungmath

There we go.

comment:47 Changed 7 months ago by vdelecroix

  • 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 follow-up: Changed 7 months ago by dimpase

Do we have a followup for Complex Field? Because it has the same problem.

comment:49 Changed 6 months ago by dimpase

rebase please

comment:50 in reply to: ↑ description Changed 4 months ago by slabbe

It was asked on the sage-devel discussion whether people have an opinion.

Replying to ticket description:

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

+1 from me

comment:51 Changed 4 months ago by git

  • Commit changed from e4a1d7564df5f062b3e3a3842c75add1d5d6b264 to 93cb1a2d43f4e6380a17b54c5e608795ebb4d000

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

1fa235cTrac 24523: py3 format style + "Real Field" -> "Real Floating-Point Field"
93cb1a2Trac #24523: change string repr "Real Field" -> "Real Floating-Point Field"

comment:52 Changed 4 months ago by git

  • Commit changed from 93cb1a2d43f4e6380a17b54c5e608795ebb4d000 to 050aa3d2b20ba742d59510c92a0328c5150f1061

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

e654661Trac 24523: "Real Field" -> "Real Floating-Point Field" + new formatting style
050aa3dTrac #24523: change string repr "Real Field" -> "Real Floating-Point Field"

comment:53 Changed 4 months ago by git

  • Commit changed from 050aa3d2b20ba742d59510c92a0328c5150f1061 to 7f7d902bfdfd7f6f76052d525b62ddea8bd86256

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

8c89c3fTrac #24523: "Real Field" -> "Real Floating-Point Field" + new formatting style
7f7d902Trac #24523: change string repr "Real Field" -> "Real Floating-Point Field"

comment:54 in reply to: ↑ 48 Changed 4 months ago by gh-mjungmath

Replying to dimpase:

Do we have a followup for Complex Field? Because it has the same problem.

Yes. See #24489.

Replying to dimpase:

rebase please

Done.

comment:55 follow-up: Changed 4 months ago by gh-mjungmath

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 slabbe

Replying to gh-mjungmath:

I wonder a bit about the changes in src/sage/tests/books/. Is that how it should be?

Yes

comment:57 Changed 3 months ago by mkoeppe

  • Status changed from needs_review to needs_work

rebase

comment:58 Changed 8 weeks ago by mkoeppe

  • Milestone changed from sage-9.3 to sage-9.4

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

Note: See TracTickets for help on using tickets.