Re: Re: Re: Re: )

*To*: mathgroup at smc.vnet.net*Subject*: [mg66491] Re: [mg66480] Re: Re: Re: )*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Wed, 17 May 2006 03:29:18 -0400 (EDT)*References*: <200605050902.FAA28575@smc.vnet.net> <e3hf84$m1h$1@smc.vnet.net> <200605090635.CAA18518@smc.vnet.net> <e3sh4a$luu$1@smc.vnet.net> <200605120603.CAA17394@smc.vnet.net> <e46ldf$466$1@smc.vnet.net> <200605160349.XAA01079@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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

**References**:**When is x^y = != E^(y*Log[x])***From:*ted.ersek@tqci.net

**Re: )***From:*Maxim <m.r@inbox.ru>

**Re: Re: )***From:*Maxim <m.r@inbox.ru>

**Re: Re: Re: )***From:*Maxim <m.r@inbox.ru>

**Re: compound symmetrical primes**

**Re: compound symmetrical primes**

**Re: Re: Re: )**

**Re: Selecting Many Things Rather Than Selecting One Thi ng From Many**