#17713: implement GoodRealField with help of continued fractions
---------------------------------+-----------------------------
Reporter: rws | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-wishlist
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
---------------------------------+-----------------------------
Comment (by tmonteil):
Replying to [comment:4 mmezzarobba]:
> * I still don't really understand the difference you are envisioninig
between `RLF` and your `GRR`. Why not just improve `RLF`?
Mainly because there are some non-lazy representations of real numbers.
Here "lazy" is related to a representation of real numbers as iterators,
and the current implementation deals about that facet, i do not see the
point in thinking of the real number `1/3` as `0.3333333...` by default. I
have nothing against improving `RLF` though, but i think we have to give a
separate name to an abstraction of the genuine real field as a
mathematical object (that could also carry some categorial information,
the fact that is indeed a field, and so on), if only to make the notion of
representation clear.
> Also, what would be the benefits of storing multiple representatives of
a real number?
I am not sure about this point, this is only a proposal! Somehow, the
existing repesentations of real numbers do not form a linear order for the
coercion, so when a real number can be reresented in two such
representations, there is a loss to choose one of them or to use the
common parent. Probably only practice would decide whether this is a good
idea, this should be experimented.
> Same question with `RCF`.
The field of effective numbers is well defined, i am not specialist, but
there are both some theoretical results about this and even some
implementations, so, if someone feel to put this in Sage, i do not see the
problem. Actually, i write say `RRF` for "real recursive field".
> * I also don't see what this all has to do with continued fractions.
As for me, nothing. I did not chose the title of this ticket, but i guess
this is because some discussion happen in a continued fraction ticket.
> * As far as I understand the intention of `SR` (well, not ''all'' of
`SR`, but things like elementary and special functions, limits, etc.) is
to sort-of-model complex variable calculus, and the problems with branch
cuts of analytic functions are bugs.
Indeed! Unfortunately numbers like `sqrt(pi)` belong to this big object,
and are interesting as real numbers. The idea is to extract such variable-
free expressions to a smaller class of "real symbolic numbers" (with
trivial inclusion in both `GRR` and `SR`).
Condidering branch problems as bugs (i agree!) does not provide an
estimate on the time to fix them, especially since we rely on external
libraries for this.
> * There seems to be a weak consensus that an algebraic structure name
”Foo“ in Sage (esp. in parent and category names) means ”Effective Foo”.
None of your real fields (even the exact ones) are ”Fields“ in this sense,
since the zero test is undecidable.
Indeed. I agree that such property should be made explicit in each
representation (similar to `is_exact`). However, as long as some not
effective (in your sense) representations are useful, i do not see the
point not to consider them.
> * Regarding names, I think I like `FPR` (or `RFP`) for floating-point
numbers and `IR` for intervals better than what you suggest.
I agree with that (i wrote "An improved version of this item could be to
even replace the word "Field" by "Numbers" (`RDN`, `RIN`, `RBN`, `RLN`,
`RFN`, ...) or "Approximation" (`RDA`, `RIA`, `RBA`, `RLA`, `RFA`,
...)."). Changing only `RR` to `RFF` was a less disruptive proposal, i am
not sure until which point we can reach a consensus (i am not even
convinced that there will eventually be a consensus to rename `RR` to be
consistent with its actual nature).
> * Using `in RR` to test if something ”is real“ still wouldn't be a good
idea in many cases, since there certainly would still be parents with some
”real“ elements that wouldn't coerce into `RR`.
This is one reason to isolate `RSF` from `SR`, because the coercion order
will be RSF > RR > SR.
> * The problem with `InfinityRing(NaN)` could simply be solved by adding
a `NaN` element to `InfinityRing`. This makes sense with the current
model. Defining a compactification mechanism may also be a good idea, but
then I guess compactifications should be generic constructions that take
any suitable parent and extend it with one or two points at infinity.
Yes.
> In other words, I doubt we need an `RRbar`, just a
`TwoPointCompactification(RR)` and a corresponding functor that the
coercion system could apply to decide that the universe of `[RR(1),
-infinity]` is `TwoPointCompactification(RR)`.
Well, this is nothing but a shortcut, as well as `RDF` is a shortcut of
`RealDoubleField()`. I have no strong opinion on whether it should be
included into the namespace.
--
Ticket URL: <http://trac.sagemath.org/ticket/17713#comment:6>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
