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: Re: Counting Runs**

**Re: Re: MathGroup /: Descriptive headings**

**Re: Zero divided by a number...**

**Re: Re: Zero divided by a number...**