mathnet-symbolics icon indicating copy to clipboard operation
mathnet-symbolics copied to clipboard

Issues with infinite and undefined values

Open frabert opened this issue 8 years ago • 8 comments

The way MathNet.Symbolics handles division with infinite and undefined values is a bit incorrect in my opinion: 1/0 evaluates to ComplexInfinity, when I would really expect it to be PositiveInfinity, or even better Undefined, as it does not exist. The way this kind of cases are handled currently is like a half-assed limit, which is not really ideal. IMO, we should have a separate Limit module which handles the computation of limits (including situations like infinities), while the expressions alone simplify into Undefined values.

frabert avatar Aug 17 '17 15:08 frabert

The concept of ComplexInfinity in Symbolics tries to be in line with Mathematica, where it is defined as "represents a quantity with infinite magnitude, but undetermined complex phase.".

In my point of view (which I'm happy to change), the expression 1/0 fits this definition nicely. That's why it is currently implemented that way in Symbolics. PositiveInfinity would be worse, since it indicates a sign where the sign is actually undefined/undetermined. Undefined would imo be less useful (information loss) but also acceptable (and matching "schoolbook" math).

Note that Mathematica also returns ComplexInfinity for 1/0, although accompanied with a warning message.

Is the current behavior causing problems?

cdrnet avatar Aug 17 '17 15:08 cdrnet

NB: A proper Limit module would be great!

cdrnet avatar Aug 17 '17 16:08 cdrnet

Yeah, the troubles arose because I was thinking about implementing a proper Limit module but I wanted to stay as close as possible to the current behavior of Symbolics. Thus it seemed strange to me that sometimes infinite quantities were treated like proper values and sometimes not ^^

Anyway, if it is a compatibility issue I guess we can keep it this way. BUT: as I am also implementing a way for trigonometric functions to return for example 1/2 when sin(pi/6) is evaluated, what would the output of tan(pi/2) be? Should it be ComplexInfinity? Or more nicely (in my opinion) PositiveInfinity?

frabert avatar Aug 17 '17 16:08 frabert

For what's worth, this is what Mathematica does for tan(pi/2). But we do not necessarily have to behave the same way as Mathematica:

2017-08-17 21_45_00- unnamed - wolfram mathematica online

cdrnet avatar Aug 17 '17 19:08 cdrnet

Well, I'd say to stick with one way for consistency, and seeing how tan(π/2) = 1/0, I'd make it ComplexInfinity and keep the other options for the Limit module.

frabert avatar Aug 17 '17 19:08 frabert

One difference we currently have to Mathematica is that the latter distinguishes between Undefined and Indeterminate (e.g. 0/0, or Re[ComplexInfinity]). We do not yet have this distinction in Symbolics. See Mathematical Constants and Indeterminate and Infinite Results. Indeterminate and ComplexInfinity are closely related conceptually.

cdrnet avatar Aug 17 '17 20:08 cdrnet

So could we use ComplexInfinity as an equivalent to Mathematica's Indeterminate expressions and reserve Undefined for invalid limits and solutions to impossible equations (in case a solver is implemented)?

frabert avatar Aug 18 '17 08:08 frabert

Since Infinity is not a Number, the mathematical debate on Wolfram's "ComplexInfinity vs. Undefined vs. Indeterminated" may be not over. If we accept Wolfram's concept practically, we can define ComplexInfinity as a complex number with Infinity magnitude and unknown or undefined phase. Until the Limit module is added, Undefined can be used as a concept covering Indeterminated.

Some of Infinity related tests were compared to WolframAlpha's results as follows. It is clear some of them need to be fixed. For example, 0/0 is Undefined (exactly Indeterminated) because it can have multiple values ​​depending on the way of Limits: Limit[(1/n)/(1/n), n->Infinity] = 1, and Limit[(1/n)/(2/n), n->Infinity] = 1/2.

image

diluculo avatar Nov 03 '17 11:11 diluculo