Opened 15 years ago
Closed 14 years ago
#1915 closed defect (fixed)
[with new patch, positive review] infinity doesn't behave well
Reported by: | burcin | Owned by: | cwitty |
---|---|---|---|
Priority: | critical | Milestone: | sage-3.1.2 |
Component: | misc | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
The default model for handling infinity in Sage is not very user friendly.
Here is an example from Mathematica:
mathematica: Gamma[0] ComplexInfinity mathematica: 1/Gamma[0] 0 mathematica: 1 + 1/Gamma[0] 1
And an example from sage:
sage: 1/Infinity Zero sage: 1 + 1/Infinity A positive finite number
In Sage 1/Infinity
should be 0
in some numeric domain. Returning Zero
in The Infinity Ring
results in everything coercing to The Infinity Ring
.
Attachments (1)
Change History (6)
comment:1 Changed 14 years ago by
Summary: | infinity doesn't behave well → [with patch, needs review] infinity doesn't behave well |
---|
comment:2 Changed 14 years ago by
Summary: | [with patch, needs review] infinity doesn't behave well → [with patch, needs some work] infinity doesn't behave well |
---|
Overall, I like this. However, and this is not entirely the fault of your patch, I have an issue here. First, in the docs at the top of the file infinity.py, oo is defined to be UnsignedInfinityRing.0
, and then later it is defined to be InfinityRing.0
; however, oo is already defined (in sage.all). It seems bad to define it (since it's already defined), and it also makes the documentation really hard to read, since as it currently stands, sometimes oo means (unsigned) infinity, and sometimes it means +Infinity. If you're doing a quick skim (as I just was), you can get really confused.
Furthermore, in a fresh copy of sage:
sage: InfinityRing.0 == oo True sage: UnsignedInfinityRing.0 == oo True sage: 1 / (UnsignedInfinityRing.0) A number less than infinity sage: 1 / oo 0
I don't like the fact that although these various infinities are ==, they don't behave the same when they are denominators.
Perhaps this could be fixed by:
- having your patch return 0 for quotients like
1 / (UnsignedInfinityRing.0)
(or did you have a reason for not making1 / (UnsignedInfinityRing.0)
return 0?), and
- not defining oo in the documentation, but instead verify in the examples that
oo == UnsignedInfinityRing.0
andoo == InfinityRing.0
both return True. (Or if the generatorUnsignedInfinityRing.0
really needs a name in the docs, give it a different one. Same forInfinityRing.0
, so the two elements can be easily distinguished when reading the docs.)
Changed 14 years ago by
Attachment: | 1915-infinity.patch added |
---|
comment:3 Changed 14 years ago by
Summary: | [with patch, needs some work] infinity doesn't behave well → [with new patch, needs review] infinity doesn't behave well |
---|
Thanks for catching the bug involving unsigned infinity. I have replaced the patch with one that hopefully addresses the (very justified!) objections. I chose to explain how oo relates to InfinityRing?.0 and to UnsignedInfinity?.0, and to replace oo by unsigned_oo in the docstrings related to the unsigned infinity ring.
comment:4 Changed 14 years ago by
Summary: | [with new patch, needs review] infinity doesn't behave well → [with new patch, positive review] infinity doesn't behave well |
---|
Looks good to me. I like the new comparisons using == and is
at the top, too.
comment:5 Changed 14 years ago by
Milestone: | sage-3.1.3 → sage-3.1.2 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Merged in Sage 3.1.2.rc4
See the attached patch. I am making 1/Infinity return the integer 0, since that should coerce without problems into any place one wants to do arithmetic.