Unexpected NANs in complex arithmetic

[Dan Sommers]

On Wed, 22 Jun 2016 16:30:49 +1000, Chris Angelico wrote:

> On Wed, Jun 22, 2016 at 4:17 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Wednesday 22 June 2016 13:54, Dan Sommers wrote:
>>
>>> By the time Python returns a result for inf+3j, you're already in
>>> trouble (or perhaps Python is already in trouble).
>>
>> I don't see why. It is possible to do perfectly sensible arithmetic on INFs.
> 
> Technically, arithmetic on INF is a short-hand for a limit. What is
> inf+1? Well, it's the limit of x+1 as x tends toward +∞, which is ∞.
> So inf+1 evaluates to inf.
> 
>>>> inf = float("inf")
>>>> inf+1
> inf
> 
> What's 5-inf? Same again - the limit of 5-x as x tends toward +∞.
> That's tending in the opposite direction, so we get infinity the other
> way:
> 
>>>> 5-inf
> -inf
> 
> So it's not really "doing arithmetic on infinity", as such. That said,
> I'm not entirely sure why "inf+3j" means we're already in trouble -
> Dan, can you elaborate? ISTM you should be able to do limit-based
> arithmetic, just the same.

What does (or can) inf+3j mean, and how can that be meaningfully
different from inf+4j, or 3+infj?  My mental model for math's ℂ and
Python's complex() is the points on a plane plus a single infinity.¹

The quantity inf+3j is not a point on the plane, nor is it that single
infinity.  To support inf+3j and 4+infj, Python's complex() would have
to be the points on a plane plus four "lines of infinity" plus something
to handle the intersections of the lines.  Maybe it's me, but that model
creates more problems than it solves.

¹ Yes, I understand that math's ℂ and Python's complex() are different.