Re: Zero divided by a number...
- To: mathgroup at smc.vnet.net
- Subject: [mg52030] Re: Zero divided by a number...
- From: "David W. Cantrell" <DWCantrell at sigmaxi.org>
- Date: Sun, 7 Nov 2004 01:04:48 -0500 (EST)
- References: <20041103190554.052$Ay@newsreader.com> <cmcn2q$ihh$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
DrBob <drbob at bigfoot.com> wrote:
> >> If x = 0, then x/0 is Indeterminate, rather than ComplexInfinity.
>
> You got me on that one, but it's a non-difference unless you can show me
> a use for ComplexInfinity that doesn't apply just as well to
> Indeterminate.
A simple example:
1/Indeterminate is again Indeterminate, while 1/ComplexInfinity yields 0.
This is as it should be: Reciprocation is an involution on C* (the
one-point extension of C), that is, we have 1/(1/z) = z for _all_ z in C*.
In case the usefulness of that isn't immediately obvious, and since you
mentioned the Gamma function later, let me mention two related
"applications". Using C* as the codomain of Gamma, so that Gamma[z] is
ComplexInfinity whenever z is a nonpositive integer, the important
identities
Gamma[z] = Gamma[z + 1]/z
and
Gamma[z] Gamma[1 - z] = Pi/Sin[Pi z]
now hold _throughout_ the complex plane. (Of course, that would not be the
case if just C were used for the codomain of Gamma.)
> Besides, if x/0 is Indeterminate
It's Indeterminate if x=0; it isn't Indeterminate in general.
> but 1/0 is ComplexInfinity, what if x =
> 1? That doesn't seem very consistent,
I don't see any inconsistency.
> and in fact it leads to problems
> like a recent poster's issue with a Sum of Binomials.
There were bugs revealed in that thread, yes. But it is not clear that they
had anything to do with how ComplexInfinity is treated in Mathematica.
> > But Mathematica's result of ComplexInfinity _is_ correct mathematically
> > (in the extended complex number system, of course).
>
> Not "of course".
Of course "of course"! I was just being explicit about the context. But the
parenthetical comment should not have been needed. After all, do you know
any _other_ number system having ComplexInfinity as an element?
> ComplexInfinity isn't a number if you can't do
> arithmetic with it,
But you can do arithmetic with it.
> and the documentation doesn't explain what we should
> expect from the concept.
You can't expect Mathematica's documentation to teach such things. We're
not actually talking about something peculiar to Mathematica; we're talking
about something which should have been covered in a beginning course in
complex analysis.
> > Not a good argument. By precisely that same reasoning, 0 shouldn't be
> > "a full-fledged member of the algebraic system" either
>
> 0 is the only thing in a Field that has no multiplicative inverse (it's
> part of the DEFINITION of a field -- not an exception to the rules).
Right, it's not an exception to the rules. But that's merely because the
exception for zero is written _into_ the rules.
> If ComplexInfinity also has no inverse, your extended complex number
> system isn't a field,
Nobody ever said it's a field.
> Defining Gamma so that 1/Gamma[z] is entire would be useful, but
> Mathematica doesn't accomplish that.
Why not?
> I'm not sure why Plot doesn't hiccup
> on this, for instance:
>
> Plot[Evaluate@D[1/Gamma[x], x], {x, -3, -1}]
>
> since evaluating the first argument at either endpoint gets us an error
> message.
I wouldn't have expected Plot to hiccup, and I'm quite glad it doesn't.
Similarly
Plot[Sin[x]/x, {x, 0, 5}]
causes no hiccup, despite the fact that Sin[x]/x is Indeterminate at x=0.
> D[1/Gamma[x],x] /. x -> -3.
>
> (error message)
> Indeterminate
Unfortunately, that derivative is not expressible in a "nice" way in
Mathematica. For an analogous case, consider the derivative of
SinIntegral[x]. That derivative is just the sine cardinal function
sinc(x) = 1 if x = 0,
sin(x)/x otherwise.
But Mathematica doesn't implement sinc(x) at present, and so it says
In[3]:= D[SinIntegral[x], x]
Out[3]= Sin[x]/x
Taken literally (as computers are wont to do), that's not right at x=0. The
derivative should have the value 1 there, rather than being Indeterminate.
(Of course, Mathematica _could_ have given a correct answer for the
derivative if sinc(x) had been implementing or, in lieu of that, by
expressing the answer piecewise. But the latter is perhaps considered to be
too messy for practicality.) For the derivative of 1/Gamma[x], things are
messier in that there is no "standard" function -- at least, none known to
me -- like sinc, which could be implemented so as to make the derivative
expressible neatly.
Experienced users should be aware that, in such situations, we need to look
at the limit:
In[4]:= Limit[D[SinIntegral[x], x], x -> 0]
Out[4]= 1
In[5]:= Limit[D[1/Gamma[x], x] , x -> -3]
Out[5]= -6
Of course, I agree that it's unfortunate that we need to look at the limit,
rather than just at the value at the point. But there may not be any
alternative which meets the demand of practicality for a CAS.
> That happens because Gamma is ComplexInfinity at the -3 and
> 0*ComplexInfinity == Indeterminate (use Trace). So again, using Gamma[-3]
> = ComplexInfinity doesn't help us
Right. Here, it doesn't help us. But it's not the source of the "trouble"
either.
> >> In fact, defining Gamma[-5] in that way _does_ remove the
> >> discontinuity. [As z -> -5, regardless of the path in the complex
> >> plane, |Gamma[z]| increases without bound.]
>
> True enough, if "increases without bound" is all it takes,
That's all it takes.
> and the
> definition makes Gamma act like a continuous function in some useful
> sense. But it doesn't.
IMO, it does. (What's "useful" is a matter of opinion.)
> 1/Gamma[z] should be entire in the extended plane,
> but in Mathematica, it isn't.
Again, why not?
> The only usage I've found that works the way we might expect seems to be
> x / ComplexInfinity (with undefined x), which evaluates to 0 -- but
> that's not actually right,
Just as you say, that's not actually right.
> since:
>
> ComplexInfinity/ComplexInfinity
>
> (error message)
> Indeterminate
>
> Hence x / ComplexInfinity (with undefined x) should be left unevaluated
> or replaced with Indeterminate.
From a purely mathematical standpoint (thinking of C*, the one-point
compactification of C), it would be better to have x/ComplexInfinity
simplify to If[x==ComplexInfinity, Indeterminate, 0]. But whether
Mathematica or any CAS _should_ do something like that is questionable due
to matters of practicality.
As a similar example, you might consider simplifying x/x. Mathematica just
gives 1, without any caveats. But in C*, it would be better to have x/x
simplify to If[x==0 || x==ComplexInfinity, Indeterminate, 1]. But again,
whether Mathematica or any CAS _should_ do something like that is
questionable due to matters of practicality.
> So... ComplexInfinity may be a "member" of the extended complex plane,
> but it dosn't walk or quack like a NUMBER.
Well, I suppose I could just toss off that comment by saying that I've
never seen or heard any number walk or quack, but that would clearly be
ducking the issue. <bah-dah-BING>
Seriously, both 0 and ComplexInfinity are quite peculiar, no doubt. And if
you don't want to call ComplexInfinity a number, that's just fine. But
it's essentially irrelevant whether we call it a "number" or not. It's an
element of C*, and what's important is knowing what you can (and can't) do
with it.
BTW, concerning whether an improper element of an extended number system
should be called a "number" or not, it might be noted that: Floating-point
arithmetic is surely the most widely used number system in the world, in
terms of the number of computations performed per day. There is an
internationally accepted standard for that arithmetic. The standard clearly
distinguishes between those floating-point objects which are numbers and
those which aren't (the NaNs). According to the standard, -Infinity and
+Infinity are numbers (while things such as 0*Infinity yield NaN).
> Whenever I see ComplexInfinity, I'll read it as Indeterminate and lose
> absolutely nothing. But it's still there in the background, mucking
> things up.
I disagree. The designers of floating-point arithmetic (W. Kahan, in
particular, comes to mind) didn't implement arithmetic with infinities for
"absolutely nothing". The same can be said for symbolic implementations of
infinity arithmetic in CAS.
David W. Cantrell
- Follow-Ups:
- Re: Re: Zero divided by a number...
- From: Andrzej Kozlowski <akoz@mimuw.edu.pl>
- Re: Re: Zero divided by a number...