#11506: Fix the infinity ring.
----------------------------+--------------------------
Reporter: vbraun | Owner: AlexGhitza
Type: defect | Status: new
Priority: critical | Milestone: sage-5.13
Component: algebra | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
----------------------------+--------------------------
Comment (by was):
> Besides, it contradicts the documentation of the infinity "ring", the
parent of Infinity, which states that the infinity "ring" does not have a
coercion map to any actual rings.
Let me argue for the same thing as you, but more precisely and technically
based on the internal design decisions in Sage.
First note that there is no implicit coercion map from {{{InfinityRing}}}
to RR, where coercion is as defined
http://www.sagemath.org/doc/tutorial/tour_coercion.html.
{{{
sage: RR.has_coerce_map_from(InfinityRing)
False
sage: InfinityRing.has_coerce_map_from(RR)
True
}}}
However, there is a *conversion* map:
{{{
sage: f = RR.convert_map_from(InfinityRing); f
Conversion map:
From: The Infinity Ring
To: Real Field with 53 bits of precision
sage: f(oo)
+infinity
sage: oo.parent()
The Infinity Ring
}}}
Conversion (not coercion) paired with equality testing (see below) is what
is used for "in" testing systematically throughout Sage. For example, the
following uses conversion:
{{{
sage: 2/1 in ZZ
True
}}}
The above would be false if it used only automatic coercion, since there
is no automatic coercion from the rationals (parent of 2/1) to ZZ. "In"
works by applying the conversion map, then testing *equality* between the
original object and the converted object, e.g., :
{{{
sage: ZZ(2/1) == 2/1
True
}}}
However, this equality test does use implicit coercion.
In the case of "+infinity":
{{{
sage: RR(oo) # fine
+infinity
sage: RR(oo) == oo # that this is true is what is really wrong....
True
}}}
That {{{RR(oo) == oo}}} evaluates to True is the real bug, since == is
supposed to mean *equal* under an implicit coercion map, e.g.:
{{{
sage: 2/1 == 2 # coerce both to QQ
True
sage: 2 == Mod(2,7) # coerce both to Z/7Z
True
sage: 2/1 == Mod(2,7) # FALSE! As it should be -- no *implicit*
coercion to a common parent, so they can't be equal
False
}}}
With CC things work right: {{{CC(oo) != oo}}}:
{{{
sage: CC(oo)
+infinity
sage: f = CC.convert_map_from(InfinityRing); f
Conversion map:
From: The Infinity Ring
To: Complex Field with 53 bits of precision
sage: f(oo)
+infinity
sage: f(oo) == oo
False
sage: CC(oo) == oo # good
False
}}}
> This is mathematical nonsense.
For the record, I'm a little uncomfortable with this way of arguing, since
we're talking about numerical analysis and numerical computation here, in
actual software, which is something that numerical analysts, IEEE
committees, etc., have thought about these issues for a while. They have
very good reasons to represent various infinities as special cases, and
have well defined rules about their behavior.
Nonetheless, I have to agree with your conclusion. I think the fix is to
make it so {{{RR(oo) == oo}}} returns False. When that is sorted out,
then {{{oo in RR}}} should return False as well, as explained above. One
can *explicitly* construct {{{a = RR(oo)}}} if needed, and for this
infinity, {{{a in RR}}} will be true.
--
Ticket URL: <http://trac.sagemath.org/ticket/11506#comment:8>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
