Re: [sage-devel] imag(CC(infinity)) is 0?

[Travis Scrimshaw]

> 2013/10/8 John Cremona >
>
>> Now a mathematician would argue that the last one should raise some
>> kind of error since we are apparently asking for the equality of
>> objects in incomparable domains.  But Python requires (I believe) that
>> == should always return True or False, so that is not an option.
>>
>
> I can't find such a restriction here:
>
> http://docs.python.org/3/reference/datamodel.html#object.__eq__
>
> Returning any value (explicitly including NotImplemented) is allowed, 
> nothing is said about raising exceptions.
>
>
   It is a convention that the rich comparisons (and "in") should never 
raise an (uncaught) exception.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Marco Streng]

2013/10/8 John Cremona 

> Now a mathematician would argue that the last one should raise some
> kind of error since we are apparently asking for the equality of
> objects in incomparable domains.  But Python requires (I believe) that
> == should always return True or False, so that is not an option.
>

I can't find such a restriction here:

http://docs.python.org/3/reference/datamodel.html#object.__eq__

Returning any value (explicitly including NotImplemented) is allowed,
nothing is said about raising exceptions.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

> I may be misunderstanding where you're going with this, but are you 
> proposing that 
>
> sage: Mod(1,5) == 1 
> False   # your proposal? -- since ZZ-->GF(5) is not injective 
>

No, my criterion is that *at least one* of the maps from the two rings to 
the push-out is injective.  Here it is the map from GF(5) to the push-out 
(also GF(5)) which is injective.

On the other hand, Mod(1, 5) in ZZ would be False in my proposal because 
here it is specifically the map ZZ -> GF(5) that should be injective for 
the result to be True.

This would be inconsistent with what is done in several other math 
> software packages: 
>
> PARI: 
> ? Mod(2,5) == 2 
> %1 = 1 
>
> Magma: 
> > GF(5)!2 eq 2; 
> true 
>
>
> Consistency with the choices of other systems for basic things like 
> this has some relevance... 
>
 
I absolutely agree.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[William Stein]

On Tue, Oct 8, 2013 at 1:08 PM, Peter Bruin  wrote:
> Hello,
>
>
>> > So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is
>> > Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an
>> > error.
>> >
>> > This looks like a rather inconsistent choice to me.
>>
>> I agree, and anyone who knows enough to ever type "pushout" will
>> certainly not be happy.
>
>
> I agree too; I don't know why "pushout" raises an error if m, n are coprime
> instead of returning the zero ring (just to make Mod(1, m) == Mod(1, n)
> evaluate to False?), but it is inconsistent and hopefully unnecessary.  The
> code gives no good reason, just the following comment:
>
> # quotient by gcd would result in the trivial ring/group/...
> # Rather than create the zero ring, we claim they can't be
> merged
>
>> On the otherhand, will anyone be happy if for
>> coprime m and n, every comparison Mod(a,m)==Mod(b,n) is True since the
>> only place they can be compared is the trivial ring?
>
>
> It is already a bit dubious to require that two ring elements be equal if
> there is _some_ common non-zero ring that both of them can be coerced into;
> I don't see why Mod(a,m) == Mod(b,n) should be True just because a and b
> happen to be equal mod gcd(m,n) when that gcd is smaller than both m and n.
>
> I don't know if Sage uses exactly the same rules to find a common parent for
> comparison as it does for arithmetic operations, but it certainly looks like
> that is the case.  I could imagine stricter rules for finding such a parent
> for comparison.  An algorithm that at least makes my list of examples work
> is the following:
>
> 1) to evaluate "a == b": if A (resp. B) is the parent of a (resp. b) and P
> is the push-out of A and B (tensor product in the case of rings), then "a ==
> b" yields True if and only if the images of a, b in P are equal *and* at
> least one of A, B maps injectively to P

I may be misunderstanding where you're going with this, but are you
proposing that

sage: Mod(1,5) == 1
False   # your proposal? -- since ZZ-->GF(5) is not injective

This would be inconsistent with what is done in several other math
software packages:

PARI:
? Mod(2,5) == 2
%1 = 1

Magma:
> GF(5)!2 eq 2;
true


Consistency with the choices of other systems for basic things like
this has some relevance...

-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

> 2) to evaluate "a in B": if A is the parent of a, and P is the push-out of 
> A and B, then "a in B" yields True if and only if the following hold:
> -- a can be converted into an element of B, say b = B(a);
> -- the images of a, b in P are equal *and* B maps injectively into P 
> (similar to rule 1 above, but asymmetric w.r.t. A, B).
>

Somewhat coincidentally, this algorithm also makes "Infinity in RR" 
evaluate to False: in this situation a = Infinity, A = InfinityRing, B = 
RR, P = InfinityRing, and the coercion map B -> P is not injective, so the 
result is False.  On the other hand, applying rule 1 to RR(Infinity) == 
Infinity still yields True.

The coercion map RR -> InfinityRing does not currently know that it is not 
injective, but this should be easy to fix.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hello,

> So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is 
> > Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an 
> error. 
> > 
> > This looks like a rather inconsistent choice to me. 
>
> I agree, and anyone who knows enough to ever type "pushout" will 
> certainly not be happy.


I agree too; I don't know why "pushout" raises an error if m, n are coprime 
instead of returning the zero ring (just to make Mod(1, m) == Mod(1, n) 
evaluate to False?), but it is inconsistent and hopefully unnecessary.  The 
code gives no good reason, just the following comment:

# quotient by gcd would result in the trivial ring/group/...
# Rather than create the zero ring, we claim they can't be 
merged

On the otherhand, will anyone be happy if for 
> coprime m and n, every comparison Mod(a,m)==Mod(b,n) is True since the 
> only place they can be compared is the trivial ring?
>

It is already a bit dubious to require that two ring elements be equal if 
there is _some_ common non-zero ring that both of them can be coerced into; 
I don't see why Mod(a,m) == Mod(b,n) should be True just because a and b 
happen to be equal mod gcd(m,n) when that gcd is smaller than both m and n.

I don't know if Sage uses exactly the same rules to find a common parent 
for comparison as it does for arithmetic operations, but it certainly looks 
like that is the case.  I could imagine stricter rules for finding such a 
parent for comparison.  An algorithm that at least makes my list of 
examples work is the following:

1) to evaluate "a == b": if A (resp. B) is the parent of a (resp. b) and P 
is the push-out of A and B (tensor product in the case of rings), then "a 
== b" yields True if and only if the images of a, b in P are equal *and* at 
least one of A, B maps injectively to P

>> sage: Mod(1, 3) == ZZ(1) 
> >> True  # with P = Zmod(3)
> >> sage: Mod(1, 3) == QQ(1) 
> >> False  # P is the zero ring
> >> sage: Mod(1, 3) == Mod(1, 4) 
> >> False  # P is the zero ring
> >> sage: Mod(1,3) == Mod(1, 6) 
> >> True  # P = Zmod(3)
> >> sage: Mod(2, 6)==Mod(4, 8) 
> >> False  # P = Zmod(2)
> >> sage: 2/1 in ZZ 
> >> True  # P = QQ
>

2) to evaluate "a in B": if A is the parent of a, and P is the push-out of 
A and B, then "a in B" yields True if and only if the following hold:
-- a can be converted into an element of B, say b = B(a);
-- the images of a, b in P are equal *and* B maps injectively into P 
(similar to rule 1 above, but asymmetric w.r.t. A, B).

>> sage: Mod(3, 5) in ZZ 
> >> False  # P = Zmod(5)
> >> sage: Mod(1,3) in Zmod(6) 
> >> False  # P = Zmod(3)
> >> sage: Mod(2,4) in Zmod(6) 
> >> False  # P = Zmod(2)
>

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[John Cremona]

On 8 October 2013 20:21, Marco Streng  wrote:
>
>
>
> 2013/10/8 Peter Bruin 
>>
>> sage: Mod(2,6)==Mod(4,8)
>>
>> True
>
>
>>
>> sage: Mod(1,3)==Mod(2,4)
>> False
>
>
> Wow, that's because the first two are compared in the common quotient
> Zmod(2) of Zmod(6) and Zmod(8), but a special case was made to disallow
> using the common quotient Zmod(1) of Zmod(3) and Zmod(4):
>
> sage: (Mod(2,6)-Mod(4,8)).parent() # This is a mathematically reasonable
> answer, and explains the "True" above.
> Ring of integers modulo 2
> sage: sage.categories.pushout.pushout(Zmod(8), Zmod(6))
> Ring of integers modulo 2
> sage: (Mod(1,3)-Mod(2,4)).parent() # And here is the reason for the "False"
> above.
> TypeError: unsupported operand parent(s) for '-': 'Ring of integers modulo
> 3' and 'Ring of integers modulo 4'
> sage: sage.categories.pushout.pushout(Zmod(4), Zmod(3)) # And here is the
> reason for the TypeError above:
> CoercionException: Trivial quotient intersection.
>
> So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is
> Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an error.
>
> This looks like a rather inconsistent choice to me.

I agree, and anyone who knows enough to ever type "pushout" will
certainly not be happy.  On the otherhand, will anyone be happy if for
coprime m and n, every comparison Mod(a,m)==Mod(b,n) is True since the
only place they can be compared is the trivial ring?

John

>
>
>>
>>
>> Unfortunately it is hard to think of a simple rule that gives the desired
>> behaviour in all of the following cases:
>>
>> sage: Mod(1, 3) == ZZ(1)
>> True  # current behaviour; certainly OK
>> sage: Mod(1, 3) == QQ(1)
>> False  # current behaviour; probably OK, but True wouldn't be completely
>> wrong
>> sage: Mod(1, 3) == Mod(1, 4)
>> False  # current behaviour; certainly OK
>> sage: Mod(1,3) == Mod(1, 6)
>> True  # current behaviour; probably OK, but False wouldn't be completely
>> wrong
>> sage: Mod(2, 6)==Mod(4, 8)
>> False  # currently yields True
>> sage: 2/1 in ZZ
>> True
>> sage: Mod(3, 5) in ZZ
>> False  # currently yields True
>> sage: Mod(1,3) in Zmod(6)
>> False  # currently yields True
>> sage: Mod(2,4) in Zmod(6)
>> False  # currently yields True
>>
>> Peter
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Marco Streng]

2013/10/8 Peter Bruin 

> sage: Mod(2,6)==Mod(4,8)
>
True
>


> sage: Mod(1,3)==Mod(2,4)
> False
>

Wow, that's because the first two are compared in the common quotient
Zmod(2) of Zmod(6) and Zmod(8), but a special case was made to disallow
using the common quotient Zmod(1) of Zmod(3) and Zmod(4):

sage: (Mod(2,6)-Mod(4,8)).parent() # This is a mathematically reasonable
answer, and explains the "True" above.
Ring of integers modulo 2
sage: sage.categories.pushout.pushout(Zmod(8), Zmod(6))
Ring of integers modulo 2
sage: (Mod(1,3)-Mod(2,4)).parent() # And here is the reason for the "False"
above.
TypeError: unsupported operand parent(s) for '-': 'Ring of integers modulo
3' and 'Ring of integers modulo 4'
sage: sage.categories.pushout.pushout(Zmod(4), Zmod(3)) # And here is the
reason for the TypeError above:
CoercionException: Trivial quotient intersection.

So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is
Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an error.

This looks like a rather inconsistent choice to me.



>
> Unfortunately it is hard to think of a simple rule that gives the desired
> behaviour in all of the following cases:
>
> sage: Mod(1, 3) == ZZ(1)
> True  # current behaviour; certainly OK
> sage: Mod(1, 3) == QQ(1)
> False  # current behaviour; probably OK, but True wouldn't be completely
> wrong
> sage: Mod(1, 3) == Mod(1, 4)
> False  # current behaviour; certainly OK
> sage: Mod(1,3) == Mod(1, 6)
> True  # current behaviour; probably OK, but False wouldn't be completely
> wrong
> sage: Mod(2, 6)==Mod(4, 8)
> False  # currently yields True
> sage: 2/1 in ZZ
> True
> sage: Mod(3, 5) in ZZ
> False  # currently yields True
> sage: Mod(1,3) in Zmod(6)
> False  # currently yields True
> sage: Mod(2,4) in Zmod(6)
> False  # currently yields True
>
> Peter
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[John Cremona]

Nowhere does Sage ever claim that the operator == yields True iff the
operands are "the same mathematical object".  This is incompatible
with the demands Python makes on how this operator behaves.
Instead,== yields True if there is some structure into which both
operands can be coerced, in which the results are equal.  This does
not mean that the original operands are in any normal sense equal.

A side-effect of this which has been much commented on here in the
past is that the == operator is (therefore) *not* transitive.  For
example,

sage: Mod(3,2)==1
True
sage: 1==Mod(4,3)
True
sage: Mod(3,2)==Mod(4,3)
False

Now a mathematician would argue that the last one should raise some
kind of error since we are apparently asking for the equality of
objects in incomparable domains.  But Python requires (I believe) that
== should always return True or False, so that is not an option.

John

On 8 October 2013 19:22, Greg Laun  wrote:
>
>
>> Sage's "in" is not a mathematical "\in", Sage's "RR" is not the field of
>> real numbers. Peter is arguing to make them behave more like they are.
>> Others are arguing not to change these things for various reasons. (And I
>> will not get myself tangled up in that, since I don't know enough about
>> floating point standards, nor do I know the reasons behind Sage's definition
>> of "in".)
>>
>
> As a user of Sage who is also trying to convert others to Sage, I would
> advocate making the "in" keyword behave like "\in" and having RR and other
> fields behave like their mathematical counterparts.  As a matter of
> programming, this can possibly be achieved by having the programer-friendly
> implementation of RR etc be the primary implementations and then writing
> user-friendly wrappers to these that behave intuitively.  This could be
> something like Peter is advocating with exceptions = True.
>
> My reading of this thread is that the problem extends beyond the infinity
> ring, and that comparisons in general may not behave in an intuitive
> mathematical way.  For example:
> sage: GF(2)(1) == 1
> True
> sage: GF(2)(3) == 1
> True
>
> I see why these work on an implementation level, but this is strange:
>
> sage: A = matrix(GF(2), 2, [2,0,0,1])
> sage: B = matrix(2, [2,0,0,1])
> sage: A == B
> True
> sage: A.rank()
> 1
> sage: B.rank()
> 2
>
> So we have a non-invertible matrix equal to an invertible matrix.  I think
> for most users, if two objects evaluate as equal, they should behave the
> same under operations like * and +.  This example breaks that assumption.
>
> Also strange:
>
> sage: C = matrix(GF(2), 2, [1, 0, 0, 1])
> sage: C in GL(2,RR)
> True
>
> I think we'd benefit generally from thinking about use cases involving
> novice Sage users and modifying the coercion framework (or whichever
> component is involved here) to deal with these use cases.
>
> -Greg
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Greg Laun]

Sage's "in" is not a mathematical "\in", Sage's "RR" is not the field of 
> real numbers. Peter is arguing to make them behave more like they are. 
> Others are arguing not to change these things for various reasons. (And I 
> will not get myself tangled up in that, since I don't know enough about 
> floating point standards, nor do I know the reasons behind Sage's 
> definition of "in".)
>
>
As a user of Sage who is also trying to convert others to Sage, I would 
advocate making the "in" keyword behave like "\in" and having RR and other 
fields behave like their mathematical counterparts.  As a matter of 
programming, this can possibly be achieved by having the programer-friendly 
implementation of RR etc be the primary implementations and then writing 
user-friendly wrappers to these that behave intuitively.  This could be 
something like Peter is advocating with exceptions = True.

My reading of this thread is that the problem extends beyond the infinity 
ring, and that comparisons in general may not behave in an intuitive 
mathematical way.  For example:
sage: GF(2)(1) == 1
True
sage: GF(2)(3) == 1
True

I see why these work on an implementation level, but this is strange:

sage: A = matrix(GF(2), 2, [2,0,0,1])
sage: B = matrix(2, [2,0,0,1])
sage: A == B
True
sage: A.rank()
1
sage: B.rank()
2

So we have a non-invertible matrix equal to an invertible matrix.  I think 
for most users, if two objects evaluate as equal, they should behave the 
same under operations like * and +.  This example breaks that assumption.  

Also strange:

sage: C = matrix(GF(2), 2, [1, 0, 0, 1])
sage: C in GL(2,RR)
True

I think we'd benefit generally from thinking about use cases involving 
novice Sage users and modifying the coercion framework (or whichever 
component is involved here) to deal with these use cases.

-Greg


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hi Marco,

- making the "in" keyword treat infinity as a special case.
>>
>
> Either Sage's RR has an infinity element or it does not. And in this case 
> the coercion framework correctly recognizes this and gives the output 
> accordingly.
>

I think it is more subtle than that.  The current RR does have _an_ 
infinity element, and this should of course map to Infinity in the 
InfinityRing under the canonical coercion map.  What is not so clear to me 
is why the +infinity element of RR should compare _equal_ to Infinity (i.e. 
whether the fact that RR(oo) == oo yields True, as William noted, is a good 
thing).

Actually, I'm starting to think that once you allow RR(oo) as a valid 
construction, you should indeed let the coercion framework evaluate RR(oo) 
== oo to True, *but* that the user should be able to construct a variant of 
RR that forbids RR(oo).  I'm thinking of something like the following:

sage: R = RealField(prec=53, exceptions=True)
sage: R(oo)
TypeError: unable to coerce +Infinity () to a real number
sage: RR(oo)
+infinity
sage: oo in R
False
sage: oo in RR
True
sage: R(NaN)
TypeError: unable to coerce  to 
a real number
sage: RR(NaN)
NaN
sage: 1/R(0.)
ZeroDivisionError
sage: 1/RR(0.)
+infinity

If you are to introduce special cases, then some things are much worse:
>
> sage: Zmod(5)(3) in ZZ
> True
>

Hmm.  This would almost be an argument for more restrictive equality and 
containment testing.  I just discovered this:

sage: Mod(2,6)==Mod(4,8)
True

On the other hand, the following extremely similar example gives the 
opposite (and in my opinion more correct) result:

sage: Mod(1,3)==Mod(2,4)
False

Unfortunately it is hard to think of a simple rule that gives the desired 
behaviour in all of the following cases:

sage: Mod(1, 3) == ZZ(1)
True  # current behaviour; certainly OK
sage: Mod(1, 3) == QQ(1)
False  # current behaviour; probably OK, but True wouldn't be completely 
wrong
sage: Mod(1, 3) == Mod(1, 4)
False  # current behaviour; certainly OK
sage: Mod(1,3) == Mod(1, 6)
True  # current behaviour; probably OK, but False wouldn't be completely 
wrong
sage: Mod(2, 6)==Mod(4, 8)
False  # currently yields True
sage: 2/1 in ZZ
True
sage: Mod(3, 5) in ZZ
False  # currently yields True
sage: Mod(1,3) in Zmod(6)
False  # currently yields True
sage: Mod(2,4) in Zmod(6)
False  # currently yields True

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hi Nils,

In my experience it often seems like it often seems desirable to have a 
> "field" R that tries to behave a little closer to being a field, but upon 
> closer inspection, the nasty implementation details of floating point 
> numbers will require for any somewhat serious application a special 
> treatment anyway.
>
> Thus, before embarking on the laborious task of trying to program such a 
> field, I recommend you first try to find a non-trivial scenario that would 
> genuinely benefit from this work.
>

Perhaps the constructor of RR should accept a flag specifying whether 
overflow, division by zero, etc. should raise exceptions or silently return 
+/- infinity or NaN.  I think it wouldn't really be that much work (see 
Paul Zimmermann's comment about MPFR internally raising exceptions), 
although I said "a case could be made" and not "I want to implement this".

Anyway, I do think there are realistic possibilities for needless confusion 
when using Sage as a tool to teach people about calculus.  Say I am a 
student who wants to experiment with integration.  It is easy to write some 
Sage code to approximate \int_0^1 f(x) dx using the trapezium rule.  Then 
if I apply this unsuspectingly to f(x) = x^(-1/2), the outcome will be 
infinity (for any step width) since f(0) = infinity.  Since no zero 
division error occurs, I could be led to believe that the value of the 
integral is infinity instead of 2, and I could even "explain" this to 
myself by noticing that f(x) takes the value infinity somewhere.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Marco Streng]

2013/10/8 Peter Bruin 

>
> The only two options that seem acceptable to me are
> - disallowing RR(oo) (if RR is taken to represent the field of real
> numbers as opposed to the extended real line);
>

Sage's "in" is not a mathematical "\in", Sage's "RR" is not the field of
real numbers. Peter is arguing to make them behave more like they are.
Others are arguing not to change these things for various reasons. (And I
will not get myself tangled up in that, since I don't know enough about
floating point standards, nor do I know the reasons behind Sage's
definition of "in".)

But in any case, the current tutorial makes people think that "in" and "RR"
mean exactly what they mean in mathematics. Their first occurrence in the
tutorial is in http://www.sagemath.org/doc/tutorial/tour_rings.html and I
quote:

"the real numbers, called RR in Sage"

"... Of course, this is not a rational number::
sage: i  # square root of -1
I
sage: i in QQ
False
"

So the tutorial says "RR is the ring of real numbers", and "in QQ" tests
whether something is a rational number. Extending this, the tutorial says
"oo in RR" tests whether infinity is a real number!

This tutorial would be a logical place to say that Sage's "in" and "RR" do
not always mean what mathematicians think they do. The following examples /
warnings would be in place when introducing "in" and "RR" to new users.

sage: oo in RR
True
sage: Zmod(5)(3) in ZZ
True

Shall I open a ticket to add these caveats to the end of
http://www.sagemath.org/doc/tutorial/tour_rings.html ?

And is there a way to make one of the following work (and give some
explanation as to how "in" is implemented and what it means):

sage: in?
Object `in` not found.
sage: ?in
Object `in` not found.


> - making the "in" keyword treat infinity as a special case.
>

Either Sage's RR has an infinity element or it does not. And in this case
the coercion framework correctly recognizes this and gives the output
accordingly.

If you are to introduce special cases, then some things are much worse:

sage: Zmod(5)(3) in ZZ
True

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Zimmermann Paul]

   Peter,

> I think a case could be made for having two versions of the current RR: one 
> like the current one (more like a model of the extended real line) and one 
> where overflow or division by zero raises an exception instead of returning 
> +/- infinity (more like a model of the usual real numbers).  I can think of 
> at least two reasons for having the latter:

note that MPFR internally raises exceptions, and it would be easy to provide
Sage functions to query/set/clear the exception flags.

Paul

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Nils Bruin]

On Monday, October 7, 2013 3:37:22 PM UTC-7, Peter Bruin wrote:
>
>
> I think a case could be made for having two versions of the current RR: 
> one like the current one (more like a model of the extended real line) and 
> one where overflow or division by zero raises an exception instead of 
> returning +/- infinity (more like a model of the usual real numbers).  I 
> can think of at least two reasons for having the latter:
>
> (1) it has a better field-like behaviour; this will always be imperfect 
> due to rounding errors, but not having infinity avoids many violations of 
> the field axioms;
>
> (2) it interacts better with the complex numbers; R embeds into C and this 
> extends to an identification of R + R*i with C, but the current 
> implementation acts as if this is true with R replaced by the extended real 
> line.  This leads to the undesirable fact that Sage's CC now contains many 
> different infinities (namely, all a + b*i where at least one of a, b is 
> infinite; note that this is completely different from e.g. having all 
> r*exp(i*t) with r = Infinity and t in [0, 2*pi), as well as from the fact 
> that in the usual compactification of C (the Riemann sphere) there is only 
> one point at infinity).  The question that Greg originally posed (why 
> imag(CC(infinity)) = 0 instead of undefined) stems from this.
>
> In my experience it often seems like it often seems desirable to have a 
"field" R that tries to behave a little closer to being a field, but upon 
closer inspection, the nasty implementation details of floating point 
numbers will require for any somewhat serious application a special 
treatment anyway.

Thus, before embarking on the laborious task of trying to program such a 
field, I recommend you first try to find a non-trivial scenario that would 
genuinely benefit from this work.

I suspect that when someone stumbles into this unexpected infinity problem, 
then removal of this problem would just let the person stumble into a more 
fundamental difference between RR and the real numbers before getting any 
worthwhile results.

Doing a lot of work just for cosmetics might not be worth the investment.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hi Marco,

I read that comment, but it looks like the coercion framework does what it 
> should. RR(oo) == oo is evaluated by coercion to InfinityRing, where 
> positive infinity equals positive infinity:
>
> sage: oo
> +Infinity
> sage: oo.parent() is InfinityRing
> True
> sage: InfinityRing.has_coerce_map_from(RR)
> True
>

Right, from that perspective it is hard to argue that there is a bug.
 

> As far as I can see, to make RR(oo) == oo evaluate to False (or give an 
> error), while staying consistent with the coercion framework, one would 
> need to either
> - disallow the explicit conversion RR(oo), or
> - remove the automatic coercion from RR to InfinityRing, or
> - make InfinityRing(RR(oo)) finite.
>

The only two options that seem acceptable to me are
- disallowing RR(oo) (if RR is taken to represent the field of real numbers 
as opposed to the extended real line);
- making the "in" keyword treat infinity as a special case.  This could be 
defended by saying that representing infinity in RR or CC is possible for 
convenience, but should not be viewed as an instance of set-theoretical 
containment.  I think this is similar to saying that +0.0 and -0.0 are 
represented differently in our implementation of floating-point arithmetic, 
but should be regarded as equal by comparison operators.

The following all make sense and look useful:
>
> sage: UnsignedInfinityRing.has_coerce_map_from(RR) # natural map RR --> 
> {finite, infinite}
> True
> sage: UnsignedInfinityRing.has_coerce_map_from(CC) # natural map CC --> 
> {finite, infinite}
> True
> sage: InfinityRing.has_coerce_map_from(RR) # natural map RR --> { -oo, 
> negative, 0, positive, +oo}
> True
> sage: InfinityRing.has_coerce_map_from(CC) # no natural map CC --> { -oo, 
> negative, 0, positive, +oo}
> False
>

Yes, I cannot think of any reason to change this.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hello,

> The implementation of RR and CC in Sage are a very direct wrapping of 
> > MPFR, which is the most well-thought out efficient implementation of 
> > floating point real numbers I've ever seen.  It is worth visiting 
> > http://www.mpfr.org/mpfr-current/mpfr.html and searching for 
> > "infinity". 
>
> thank you for the pointer. However for questions whether Inf should be in 
> RR 
> or not, the MPFR documentation does not say much. About this topic, I 
> recommend to look at the discussions around the P1788 standard for 
> interval 
> arithmetic : . 
>
 
I did not have time to look at any of this material yet, but I think it is 
good to point out that there are different questions here.  I think it is 
not very controversial that a system for floating-point arithmetic includes 
+/- infinity and NaN as special values.  However, one can argue to what 
extent these should be regarded as valid numbers, e.g. which operations on 
"finite real numbers" should be extended to these special values.  Of 
course, it is true that numerical analysts and programmers have thought 
deeply about this; however, Sage users coming from other fields of 
mathematics will not expect this behaviour (which is why I was baffled by 
"Infinity in RR").  In other words, the fact that RR is a fairly thin 
wrapper around MPFR has good and bad sides.

As for NaN, this can hardly be viewed as anything else than a kind of error 
code.  It is still treated as an element of RR, though:

sage: NaN in RR
True
sage: parent(NaN)
Symbolic Ring
sage: n = RR(NaN)
sage: n
NaN

For +/- infinity, it at least looks reasonable to treat these as 
"pseudo-numbers" on which most operations still make sense.  This is what 
Sage's RR does; it is actually closer to the extended real line (the union 
of {-infinity}, the reals and {+infinity} with the expected topology) than 
to the reals alone.

At the same time +/- infinity do also play the role of error codes, namely 
for overflow and underflow:

sage: 2.^(2.^(2.^10))
+infinity

If one views RR as a model of the extended real line, then one could say 
that this +infinity is not really an error code, but just another instance 
of rounding.

I think a case could be made for having two versions of the current RR: one 
like the current one (more like a model of the extended real line) and one 
where overflow or division by zero raises an exception instead of returning 
+/- infinity (more like a model of the usual real numbers).  I can think of 
at least two reasons for having the latter:

(1) it has a better field-like behaviour; this will always be imperfect due 
to rounding errors, but not having infinity avoids many violations of the 
field axioms;

(2) it interacts better with the complex numbers; R embeds into C and this 
extends to an identification of R + R*i with C, but the current 
implementation acts as if this is true with R replaced by the extended real 
line.  This leads to the undesirable fact that Sage's CC now contains many 
different infinities (namely, all a + b*i where at least one of a, b is 
infinite; note that this is completely different from e.g. having all 
r*exp(i*t) with r = Infinity and t in [0, 2*pi), as well as from the fact 
that in the usual compactification of C (the Riemann sphere) there is only 
one point at infinity).  The question that Greg originally posed (why 
imag(CC(infinity)) = 0 instead of undefined) stems from this.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[William Stein]

On Mon, Oct 7, 2013 at 12:43 PM, Marco Streng  wrote:
>
>
>
> 2013/10/5 William Stein 
>>
>> On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun  wrote:
>> > Thanks Peter.  I agree that infinity in RR is a big problem.  For those
>> > following the discussion, Peter updated Trac ticket #11506 to reflect
>> > this
>> > concern and it is now marked as a critical bug.
>>
>> I've added a long comment there
>> (http://trac.sagemath.org/ticket/11506#comment:8).   The issue we're
>> discussing is a side-effect of the *bug* that RR(oo) == oo evaluates
>> to True, but it should evaluate to False.  Somebody (me?) just messed
>
>
>
> I read that comment, but it looks like the coercion framework does what it
> should. RR(oo) == oo is evaluated by coercion to InfinityRing, where
> positive infinity equals positive infinity:
>
> sage: oo
> +Infinity
> sage: oo.parent() is InfinityRing
> True
> sage: InfinityRing.has_coerce_map_from(RR)
> True
>
> As far as I can see, to make RR(oo) == oo evaluate to False (or give an
> error), while staying consistent with the coercion framework, one would need
> to either
> - disallow the explicit conversion RR(oo), or
> - remove the automatic coercion from RR to InfinityRing, or
> - make InfinityRing(RR(oo)) finite.
>
> Are you arguing for one of these?

No, I'm not.  I hadn't checked exactly why "RR(oo) == oo" evaluates to
True -- since it does by coercion to InfinityRing, it makes sense in
the context of the current model.  Thanks for the clarification.

> The following all make sense and look useful:
>
> sage: UnsignedInfinityRing.has_coerce_map_from(RR) # natural map RR -->
> {finite, infinite}
> True
> sage: UnsignedInfinityRing.has_coerce_map_from(CC) # natural map CC -->
> {finite, infinite}
> True
> sage: InfinityRing.has_coerce_map_from(RR) # natural map RR --> { -oo,
> negative, 0, positive, +oo}
> True
> sage: InfinityRing.has_coerce_map_from(CC) # no natural map CC --> { -oo,
> negative, 0, positive, +oo}
> False
>
>
>>
>> that up when implementing RR long ago.  Somebody else (me?) got the
>> same thing for CC right though.
>>
>> The implementation of RR and CC in Sage are a very direct wrapping of
>> MPFR, which is the most well-thought out efficient implementation of
>> floating point real numbers I've ever seen.  It is worth visiting
>> http://www.mpfr.org/mpfr-current/mpfr.html and searching for
>> "infinity".
>>
>>  -- William
>>
>> >
>> > On Thursday, October 3, 2013 5:31:06 PM UTC-4, Peter Bruin wrote:
>> >>
>> >> Hello,
>> >>
>> >>> from the perspective of the Riemann sphere it's a bit odd since
>> >>> CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all
>> >>> distinct
>> >>> in sage, giving us 3 different complex infinities.
>> >>
>> >>
>> >> Here is another case of unexpected behaviour:
>> >>
>> >> sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
>> >> False
>> >> sage: CC(I+Infinity)==CC(2*I+Infinity)
>> >> True
>> >>
>> >> See Trac tickets #14088, #11506 and #14857 for other reported problems
>> >> with various infinities.
>> >>
>> >> Peter
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to sage-devel+unsubscr...@googlegroups.com.
>> > To post to this group, send email to sage-devel@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> William Stein
>> Professor of Mathematics
>> University of Washington
>> http://wstein.org
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/gr

Re: [sage-devel] imag(CC(infinity)) is 0?

[Marco Streng]

2013/10/5 William Stein 

> On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun  wrote:
> > Thanks Peter.  I agree that infinity in RR is a big problem.  For those
> > following the discussion, Peter updated Trac ticket #11506 to reflect
> this
> > concern and it is now marked as a critical bug.
>
> I've added a long comment there
> (http://trac.sagemath.org/ticket/11506#comment:8).   The issue we're
> discussing is a side-effect of the *bug* that RR(oo) == oo evaluates
> to True, but it should evaluate to False.  Somebody (me?) just messed
>


I read that comment, but it looks like the coercion framework does what it
should. RR(oo) == oo is evaluated by coercion to InfinityRing, where
positive infinity equals positive infinity:

sage: oo
+Infinity
sage: oo.parent() is InfinityRing
True
sage: InfinityRing.has_coerce_map_from(RR)
True

As far as I can see, to make RR(oo) == oo evaluate to False (or give an
error), while staying consistent with the coercion framework, one would
need to either
- disallow the explicit conversion RR(oo), or
- remove the automatic coercion from RR to InfinityRing, or
- make InfinityRing(RR(oo)) finite.

Are you arguing for one of these?

The following all make sense and look useful:

sage: UnsignedInfinityRing.has_coerce_map_from(RR) # natural map RR -->
{finite, infinite}
True
sage: UnsignedInfinityRing.has_coerce_map_from(CC) # natural map CC -->
{finite, infinite}
True
sage: InfinityRing.has_coerce_map_from(RR) # natural map RR --> { -oo,
negative, 0, positive, +oo}
True
sage: InfinityRing.has_coerce_map_from(CC) # no natural map CC --> { -oo,
negative, 0, positive, +oo}
False



> that up when implementing RR long ago.  Somebody else (me?) got the
> same thing for CC right though.
>
> The implementation of RR and CC in Sage are a very direct wrapping of
> MPFR, which is the most well-thought out efficient implementation of
> floating point real numbers I've ever seen.  It is worth visiting
> http://www.mpfr.org/mpfr-current/mpfr.html and searching for
> "infinity".
>
>  -- William
>
> >
> > On Thursday, October 3, 2013 5:31:06 PM UTC-4, Peter Bruin wrote:
> >>
> >> Hello,
> >>
> >>> from the perspective of the Riemann sphere it's a bit odd since
> >>> CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all
> distinct
> >>> in sage, giving us 3 different complex infinities.
> >>
> >>
> >> Here is another case of unexpected behaviour:
> >>
> >> sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
> >> False
> >> sage: CC(I+Infinity)==CC(2*I+Infinity)
> >> True
> >>
> >> See Trac tickets #14088, #11506 and #14857 for other reported problems
> >> with various infinities.
> >>
> >> Peter
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Fwd: Re: [sage-devel] imag(CC(infinity)) is 0?

[William Stein]

-- Forwarded message --
From: "Zimmermann Paul" 
Date: Oct 4, 2013 10:53 PM
Subject: Re: [sage-devel] imag(CC(infinity)) is 0?
To: "William Stein" 
Cc: 

   William,

[please forward to sage-devel since I'm not sure I'm allowed to post there]

> The implementation of RR and CC in Sage are a very direct wrapping of
> MPFR, which is the most well-thought out efficient implementation of
> floating point real numbers I've ever seen.  It is worth visiting
> http://www.mpfr.org/mpfr-current/mpfr.html and searching for
> "infinity".

thank you for the pointer. However for questions whether Inf should be in RR
or not, the MPFR documentation does not say much. About this topic, I
recommend to look at the discussions around the P1788 standard for interval
arithmetic : <http://grouper.ieee.org/groups/1788/>.

Best regards,
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Zimmermann Paul]

   William,

[please forward to sage-devel since I'm not sure I'm allowed to post there]

> The implementation of RR and CC in Sage are a very direct wrapping of
> MPFR, which is the most well-thought out efficient implementation of
> floating point real numbers I've ever seen.  It is worth visiting
> http://www.mpfr.org/mpfr-current/mpfr.html and searching for
> "infinity".

thank you for the pointer. However for questions whether Inf should be in RR
or not, the MPFR documentation does not say much. About this topic, I
recommend to look at the discussions around the P1788 standard for interval
arithmetic : .

Best regards,
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[William Stein]

On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun  wrote:
> Thanks Peter.  I agree that infinity in RR is a big problem.  For those
> following the discussion, Peter updated Trac ticket #11506 to reflect this
> concern and it is now marked as a critical bug.

I've added a long comment there
(http://trac.sagemath.org/ticket/11506#comment:8).   The issue we're
discussing is a side-effect of the *bug* that RR(oo) == oo evaluates
to True, but it should evaluate to False.  Somebody (me?) just messed
that up when implementing RR long ago.  Somebody else (me?) got the
same thing for CC right though.

The implementation of RR and CC in Sage are a very direct wrapping of
MPFR, which is the most well-thought out efficient implementation of
floating point real numbers I've ever seen.  It is worth visiting
http://www.mpfr.org/mpfr-current/mpfr.html and searching for
"infinity".

 -- William

>
> On Thursday, October 3, 2013 5:31:06 PM UTC-4, Peter Bruin wrote:
>>
>> Hello,
>>
>>> from the perspective of the Riemann sphere it's a bit odd since
>>> CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all distinct
>>> in sage, giving us 3 different complex infinities.
>>
>>
>> Here is another case of unexpected behaviour:
>>
>> sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
>> False
>> sage: CC(I+Infinity)==CC(2*I+Infinity)
>> True
>>
>> See Trac tickets #14088, #11506 and #14857 for other reported problems
>> with various infinities.
>>
>> Peter
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Greg Laun]

Thanks Peter.  I agree that infinity in RR is a big problem.  For those 
following the discussion, Peter updated Trac ticket #11506 to reflect this 
concern and it is now marked as a critical bug.  

On Thursday, October 3, 2013 5:31:06 PM UTC-4, Peter Bruin wrote:
>
> Hello,
>
> from the perspective of the Riemann sphere it's a bit odd since  
>> CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all distinct 
>> in sage, giving us 3 different complex infinities.
>>
>
> Here is another case of unexpected behaviour:
>
> sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
> False
> sage: CC(I+Infinity)==CC(2*I+Infinity)
> True
>
> See Trac tickets #14088, #11506 and #14857 for other reported problems 
> with various infinities.
>
> Peter
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hello,

from the perspective of the Riemann sphere it's a bit odd since  
> CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all distinct 
> in sage, giving us 3 different complex infinities.
>

Here is another case of unexpected behaviour:

sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
False
sage: CC(I+Infinity)==CC(2*I+Infinity)
True

See Trac tickets #14088, #11506 and #14857 for other reported problems with 
various infinities.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hello,

RR isn't named "Real numbers"; it is named "real field with 53 bits 
> precision" 
>

And, fair enough, the docstring of RR starts as follows:

   An approximation to the field of real numbers using floating point
   numbers with any specified precision. Answers derived from
   calculations in this approximation may differ from what they would
   be if those calculations were performed in the true field of real
   numbers. This is due to the rounding errors inherent to finite
   precision calculations.

Maybe this paragraph should also mention that plus/minus infinity are 
representable in RR, even though they are not real numbers?  After all, 
allowing plus/minus infinity in RR is a choice that is by no means forced 
upon us by working with finite precision.

I'm used to PARI, where multiprecision reals do not include infinity; for 
example, minus infinity as an endpoint for numerical integration has to be 
specified as the 1-element vector [-1].

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

>
> > So I would say that the current behaviour of Sage (Infinity in RR giving 
> > True and any similar suggestion that infinity is a real number) is 
> > mathematically wrong and must be changed.  It also contradicts the 
> > documentation of the infinity "ring" (in which Sage's "Infinity" object 
> > lives), which says that the infinity "ring" does not canonically coerce 
> > into any other ring. 
>
> I do not agree. RR and CC are *badly* named in Sage.


Actually, that is more or less what I mean.  I expressed it a bit 
polemically, though, because I think it is a serious problem.

As Peter said, 
> they are sets of floating point numbers. In particular, I found 
> completely valid that Infinity is an element of RR (since it is *not* 
> the set of real numbers).
>

But you know more about computer floating point arithmetic than most 
people.  Of course many of us realise perfectly how far RR is from the 
field of real numbers, because we have lots of experience with it.  
However, given that Sage will be used more and more for teaching calculus, 
for example, I think "Infinity in RR --> True" is dangerously misleading.  
The fact that there is an explanation why this behaviour arises (namely, 
that RR is badly named) does not make the problem vanish.

In case this sounds like I would the meaning of RR to change: of course 
this would be practically impossible.  But as I wrote before, "Infinity in 
RR --> True" also appears to contradict the documentation of the infinity 
"ring", since that is not supposed to coerce into other rings.  What I 
would like is that Infinity (the globally named object, which lives in the 
infinity "ring") should not designate an element of RR without explicit 
conversion.  While RR (as an implementation of floating point arithmetic) 
should have some elements representing plus/minus infinity and NaN, the 
current behaviour seems too potentially confusing for less experienced 
mathematicians.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[William Stein]

On Thu, Oct 3, 2013 at 1:26 PM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>>> I guess my follow up question would be do we want infinity to be real in
>>> this sense or is that just a byproduct of its implementation?  I don't
>>> know
>>> all the uses for infinity that other sage users have, but certainly from
>>> the perspective of the Riemann sphere it's a bit odd since
>>> CC(infinity,0),
>>> CC(0, infinity) and CC(infinity, infinity) are all distinct in sage,
>>> giving
>>> us 3 different complex infinities.  I'm not particularly picking on CC,
>>> since infinity*I and infinity are also not equal.
>>>
>>
>> If you ask me, neither RR nor CC should contain any kind of infinity.  As a
>> piece of mathematical software, Sage must be mathematically correct and not
>> pretend that infinity is in RR (or CC).
>>
>> There is a set of floating point objects and a set of real numbers; they
>> have a large intersection, but both of them contain elements that the other
>>
>> doesn't.  Plus or minus infinity and "not a number" are not real numbers;
>> conversely, most real numbers, like pi, cannot be represented (only
>> approximated) by floating point numbers.
>>
>> Of course, it is also true that floating point objects can represent
>> infinity, and for a good reason.  For example, if you evaluate a
>> meromorphic function at a pole, then it is legitimate to say that the
>> result is infinity.  It is just not an element of the complex numbers, but
>> of the Riemann sphere (the projective line over CC).
>>
>> For the real numbers, there are two separate completions: first, the
>> projective line over RR, which has only one point at infinity and is a
>> subset of the Riemann sphere; second, the "extended real line" containing
>> plus infinity and minus infinity.  It depends on the context which one is
>> more useful, but both of them are definitely different from RR, because RR
>> does not contain any infinite element at all.
>>
>> So I would say that the current behaviour of Sage (Infinity in RR giving
>> True and any similar suggestion that infinity is a real number) is
>> mathematically wrong and must be changed.  It also contradicts the
>> documentation of the infinity "ring" (in which Sage's "Infinity" object
>> lives), which says that the infinity "ring" does not canonically coerce
>> into any other ring.
>
> I do not agree. RR and CC are *badly* named in Sage. As Peter said,

RR isn't named "Real numbers"; it is named "real field with 53 bits precision"

sage: RealField(53)
Real Field with 53 bits of precision

That said, of course, it is not a "field", so it is misleadingly
named.   I was just following Magma in these conventions:

wstein@pixel:~/Downloads$ magma
Magma V2.18-5 Thu Oct  3 2013 13:44:16 ...
> RealField();
Real field of precision 30


> they are sets of floating point numbers. In particular, I found
> completely valid that Infinity is an element of RR (since it is *not*
> the set of real numbers).
>
> Vincent
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Vincent Delecroix]

>> I guess my follow up question would be do we want infinity to be real in
>> this sense or is that just a byproduct of its implementation?  I don't
>> know
>> all the uses for infinity that other sage users have, but certainly from
>> the perspective of the Riemann sphere it's a bit odd since
>> CC(infinity,0),
>> CC(0, infinity) and CC(infinity, infinity) are all distinct in sage,
>> giving
>> us 3 different complex infinities.  I'm not particularly picking on CC,
>> since infinity*I and infinity are also not equal.
>>
>
> If you ask me, neither RR nor CC should contain any kind of infinity.  As a
> piece of mathematical software, Sage must be mathematically correct and not
> pretend that infinity is in RR (or CC).
>
> There is a set of floating point objects and a set of real numbers; they
> have a large intersection, but both of them contain elements that the other
>
> doesn't.  Plus or minus infinity and "not a number" are not real numbers;
> conversely, most real numbers, like pi, cannot be represented (only
> approximated) by floating point numbers.
>
> Of course, it is also true that floating point objects can represent
> infinity, and for a good reason.  For example, if you evaluate a
> meromorphic function at a pole, then it is legitimate to say that the
> result is infinity.  It is just not an element of the complex numbers, but
> of the Riemann sphere (the projective line over CC).
>
> For the real numbers, there are two separate completions: first, the
> projective line over RR, which has only one point at infinity and is a
> subset of the Riemann sphere; second, the "extended real line" containing
> plus infinity and minus infinity.  It depends on the context which one is
> more useful, but both of them are definitely different from RR, because RR
> does not contain any infinite element at all.
>
> So I would say that the current behaviour of Sage (Infinity in RR giving
> True and any similar suggestion that infinity is a real number) is
> mathematically wrong and must be changed.  It also contradicts the
> documentation of the infinity "ring" (in which Sage's "Infinity" object
> lives), which says that the infinity "ring" does not canonically coerce
> into any other ring.

I do not agree. RR and CC are *badly* named in Sage. As Peter said,
they are sets of floating point numbers. In particular, I found
completely valid that Infinity is an element of RR (since it is *not*
the set of real numbers).

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Peter Bruin]

Hello,
 

> I guess my follow up question would be do we want infinity to be real in 
> this sense or is that just a byproduct of its implementation?  I don't know 
> all the uses for infinity that other sage users have, but certainly from 
> the perspective of the Riemann sphere it's a bit odd since  CC(infinity,0), 
> CC(0, infinity) and CC(infinity, infinity) are all distinct in sage, giving 
> us 3 different complex infinities.  I'm not particularly picking on CC, 
> since infinity*I and infinity are also not equal.   
>

If you ask me, neither RR nor CC should contain any kind of infinity.  As a 
piece of mathematical software, Sage must be mathematically correct and not 
pretend that infinity is in RR (or CC).

There is a set of floating point objects and a set of real numbers; they 
have a large intersection, but both of them contain elements that the other 
doesn't.  Plus or minus infinity and "not a number" are not real numbers; 
conversely, most real numbers, like pi, cannot be represented (only 
approximated) by floating point numbers.

Of course, it is also true that floating point objects can represent 
infinity, and for a good reason.  For example, if you evaluate a 
meromorphic function at a pole, then it is legitimate to say that the 
result is infinity.  It is just not an element of the complex numbers, but 
of the Riemann sphere (the projective line over CC).

For the real numbers, there are two separate completions: first, the 
projective line over RR, which has only one point at infinity and is a 
subset of the Riemann sphere; second, the "extended real line" containing 
plus infinity and minus infinity.  It depends on the context which one is 
more useful, but both of them are definitely different from RR, because RR 
does not contain any infinite element at all.

So I would say that the current behaviour of Sage (Infinity in RR giving 
True and any similar suggestion that infinity is a real number) is 
mathematically wrong and must be changed.  It also contradicts the 
documentation of the infinity "ring" (in which Sage's "Infinity" object 
lives), which says that the infinity "ring" does not canonically coerce 
into any other ring.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Greg Laun]

Thanks for this clarification.

I guess my follow up question would be do we want infinity to be real in 
this sense or is that just a byproduct of its implementation?  I don't know 
all the uses for infinity that other sage users have, but certainly from 
the perspective of the Riemann sphere it's a bit odd since  CC(infinity,0), 
CC(0, infinity) and CC(infinity, infinity) are all distinct in sage, giving 
us 3 different complex infinities.  I'm not particularly picking on CC, 
since infinity*I and infinity are also not equal.  



On Thursday, October 3, 2013 2:10:19 PM UTC-4, Michael Orlitzky wrote:
>
> On 10/03/2013 11:54 AM, Greg Laun wrote: 
> > Out of curiosity, I decided to ask sage what it thought the imaginary 
> > part of infinity was.  I'm not quite sure that this should return 0. 
> > Mathematica returns Indeterminate, which seems like a better answer to 
> me. 
> > 
> > Has this been discussed elsewhere? 
> > 
>
>
> The CC constructor takes the real/imaginary parts separately. So if you 
> want (0, infinity) or (infinity, infinity) or something in between, you 
> can do that: 
>
>   sage: imag( CC(Infinity, Infinity) ) 
>   +infinity 
>
> Sage's infinity is essentially real, if for no other reason than, 
>
>   sage: infinity.numerical_approx().base_ring() 
>   Real Field with 53 bits of precision 
>
> The actual semantics are explained in, 
>
>   http://www.sagemath.org/doc/reference/rings/sage/rings/infinity.html 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] imag(CC(infinity)) is 0?

[Michael Orlitzky]

On 10/03/2013 11:54 AM, Greg Laun wrote:
> Out of curiosity, I decided to ask sage what it thought the imaginary
> part of infinity was.  I'm not quite sure that this should return 0. 
> Mathematica returns Indeterminate, which seems like a better answer to me. 
> 
> Has this been discussed elsewhere?
> 


The CC constructor takes the real/imaginary parts separately. So if you
want (0, infinity) or (infinity, infinity) or something in between, you
can do that:

  sage: imag( CC(Infinity, Infinity) )
  +infinity

Sage's infinity is essentially real, if for no other reason than,

  sage: infinity.numerical_approx().base_ring()
  Real Field with 53 bits of precision

The actual semantics are explained in,

  http://www.sagemath.org/doc/reference/rings/sage/rings/infinity.html

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.