Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: Re: Re: )


On 16 May 2006, at 12:49, Maxim wrote:

> On Sun, 14 May 2006 07:14:55 +0000 (UTC), Andrzej Kozlowski
> <akoz at mimuw.edu.pl> wrote:
>>
>> First note that you are talking about Limits, while the original
>> discussion was about something a bit different (as I discuss below).
>> While I think your principle for Limits would be better than what
>> Mathematica does now, it is still, in my opinion, a sub-species of
>> the following one: given an input for which several interpretations
>> are possible choose the one for which the most "useful" answer can be
>> given. This principle was used a lot in early versions of
>> Mathematica, for example in definite integration, where Mathematica
>> would often by itself interpret input in such a way (often requiring
>> unstated assumptions) that it enable it to provide an (often
>> arguably) sensible answer.  The problems with this approach have
>> often been discussed (in particular by yourself) so there is no need
>> to repeat this again here.
>> Beginning with version 4 WRI has been gradually replacing this
>> approach with conditional output and the Assumptions mechanism.  I
>> think when at all feasible the second approach is much preferable.
>> For  a start the user would be able to work in the mathematical
>> context that he wishes to: if he wants to work on the extended real
>> line or on the Riemann sphere he should be able to decide this
>> himself rather than have Mathematica choose for him what it finds
>> suitable.
>>
>> However, there is a different issue involved here: the one Ted Ersek
>> originally asked about. This is to do with the way Mathematica
>> extends arithmetical operations to various infinite quantities it
>> uses. The answers that it returns often disagree with the answer
>> Limit gives, and this difference cannot be explained, I think, by the
>> fact that Limit assumes a default direction (I suspect, this fact
>> also would coexist somewhat uneasily with your principle). We have
>> already seen that:
>>
>>
>> Infinity^Infinity
>>
>> ComplexInfinity
>>
>> but note that actually:
>>
>> Limit[z^z, z -> Infinity]
>>
>> Infinity
>>
>> The choice of direction does not make any difference here:
>>
>>
>> Limit[z^z, z -> Infinity, Direction -> I]
>>
>> Infinity
>>
>> Moreover:
>>
>>
>> Limit[z^z, z -> ComplexInfinity]
>>
>> Infinity
>>
>> (I don't get this one)
>>
>> while
>>
>> ComplexInfinity^ComplexInfinity
>>
>> returns Indeterminate.
>>
>> Here Limit and "direct substitution" agree:
>>
>>
>> Limit[z^2, z ->ComplexInfinity]
>>
>> ComplexInfinity
>>
>>
>> ComplexInfinity^2
>>
>>
>> ComplexInfinity
>>
>>
>> on the other hand this:
>>
>> Limit[2^z, z ->
>>     ComplexInfinity]
>>
>> is left unevaluated, rather than returning Indeterminate, as this  
>> does:
>>
>> 2^ComplexInfinity
>>
>> Here is another example where the behaviour of Limit and "direct
>> substitution" differ.
>>
>>
>> p = (1 + z)/(1 + z^2)
>>
>> p /. z -> ComplexInfinity
>>
>> Indeterminate expression 0 *ComplexInfinity encountered.
>> Indeterminate
>>
>> This is rather unpleasant if you were expecting that your principle
>> (or the Riemann sphere model) would be used here. Fortunately this
>> works:
>>
>>
>> Limit[p, z -> ComplexInfinity]
>>
>> 0
>>
>>
>>
>> So the question that Ted asked seems quite to the point: what are the
>> rules governing direct algebraic manipulation of Infinities? it seems
>> to me that that there are almost none: basically any answer that
>> seemed sensible to whoever programmed  this part of Mathematica is
>> returned in a seemingly haphazard way. It seems that neither a
>> topological model nor a formal principle like the one you have stated
>> is being used, or at least if there is one I can't work it out.
>>
>> Andrzej Kozlowski
>> Tokyo, Japan
>>
>
> Well, it's not quite as hopeless. We can use limits to define the  
> values
> of functions at DirectedInfinity. The important point is that the  
> limit is
> taken along an arbitrary path. If we consider only straight lines  
> from the
> origin, then we'll have to set E^Infinity == Limit[E^x, x ->  
> Infinity] ==
> Infinity (Limit in the Mathematica sense, along the real line) and  
> then
> we'll be forced to accept results such as E^(Infinity + I*Pi) !=
> E^Infinity*E^(I*Pi) and so probably won't be able to construct any  
> useful
> arithmetic.
>
> However, if we consider all possible paths in the complex plane  
> such that
> the absolute value of z converges to Infinity and the argument  
> converges
> to the given value, then it will follow that E^Infinity ==
> ComplexInfinity. Then certain useful identities such as E^(Infinity
> + I*Pi) == E^Infinity*E^(I*Pi) == ComplexInfinity will still hold (as
> ComplexInfinity == -ComplexInfinity).
>
> This doesn't contradict results such as Limit[E^x, x -> Infinity] ==
> Infinity, because in that case we choose only one fixed path to  
> Infinity.
>
> Then it appears that the identity x^y == E^(y*Log[x]) will hold for  
> all
> varieties of infinite quantities as well:
>
> 0^-3 == ComplexInfinity ==
>    E^(-3*Log[0]) == E^Infinity == ComplexInfinity
>
> Here Log[0] == -Infinity also because this is true for all paths to 0.
>
> (-2)^DirectedInfinity[2 + I] == 0 ==
>    E^(DirectedInfinity[2 + I]*Log[-2]) == 0
>
> Here (-2)^DirectedInfinity[2 + I] == 0, contrary to what  
> Mathematica says,
> again because for any path to DirectedInfinity[2 + I] the absolute  
> value
> goes to 0.
>
> Maxim Rytin
> m.r at inbox.ru
>

I agree as far as your particular examples are concerned. However, I  
still do not think you will be able to do much that is useful with  
these infinities unless you return unevaluated answers and let the  
user applies some sort of Simplify mechanism. Otherwise Mathematica's  
built in evaluator will just follow the usual rules of arithmetic  
that do not apply to these infinite quantities and arrive at  
nonsensical results. So the fact that form time to time one can get a  
sensible answer will be buried under a heap of nonsense.
The following example, while somewhat different from those that  
originated this discussion, illustrates my point well enough:

(1 + ComplexInfinity)/(1 + ComplexInfinity^2)

Indeterminate

We know that  (1+z)/(1+z^2) will go to 0, whatever path z follows to  
ComplexInfinity so the correct answer is certainly 0.   Mathematica  
can indeed confirm this using Limit with various chosen directions, e.g.


Limit[(z + 1)/(z^2 + 1), z -> ComplexInfinity,
   Direction -> I + 1]

0

and you can even Series to check this for all directions:


Series[(z + 1)/(z^2 + 1), {z, ComplexInfinity, 1}]


SeriesData[z, ComplexInfinity, {1}, 1, 2, 1]

But directly substituting CompelexInifnity for z gives the useless  
answer Indeterminate. In fact all the "correct" answers that  
arithmetic with infinities returns can be obtained by using other  
methods and one (usually) does not get the incorrect ones. This, I  
think, is perhaps the most powerful argument against this arithmetic  
with infinities: usually it can't be done predictably and reliably  
enough for the user to trust the answers he gets, so in any case he  
will have to check them using traditional methods (limits, power  
series, etc). So I think, that with one or two exceptions,it would be  
best to return such expressions (with infinities) unevaluated and  
possibly evaluate them after the user applied Simplify, perhaps with  
additional assumptions.  That would allow one to use Limits, and even  
possibly different models of infinities, distinguish real from  
complex cases etc. It would likely be mathematically correct and  
might even be useful.

Andrzej Kozlowski

Tokyo, Japan


  • Prev by Date: Re: compound symmetrical primes
  • Next by Date: Re: compound symmetrical primes
  • Previous by thread: Re: Re: Re: )
  • Next by thread: Re: Selecting Many Things Rather Than Selecting One Thi ng From Many