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:

Status badges

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)

1915-infinity.patch (7.6 KB) - added by AlexGhitza 14 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 14 years ago by AlexGhitza

Summary: infinity doesn't behave well[with patch, needs review] infinity doesn't behave well

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.

comment:2 Changed 14 years ago by jhpalmieri

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:

  1. having your patch return 0 for quotients like 1 / (UnsignedInfinityRing.0) (or did you have a reason for not making 1 / (UnsignedInfinityRing.0) return 0?), and
  1. not defining oo in the documentation, but instead verify in the examples that oo == UnsignedInfinityRing.0 and oo == InfinityRing.0 both return True. (Or if the generator UnsignedInfinityRing.0 really needs a name in the docs, give it a different one. Same for InfinityRing.0, so the two elements can be easily distinguished when reading the docs.)

Changed 14 years ago by AlexGhitza

Attachment: 1915-infinity.patch added

comment:3 Changed 14 years ago by AlexGhitza

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 jhpalmieri

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 mabshoff

Milestone: sage-3.1.3sage-3.1.2
Resolution: fixed
Status: newclosed

Merged in Sage 3.1.2.rc4

Note: See TracTickets for help on using tickets.