Mathematica goes Bad
Igor Touzov
version cuts off something good from what mathematica used to be.
Contacting technical support only results in open ticket that never gets
closed.
Here some simple example you can run for youself:
Timing[
Limit[ (a ^2 k ^2 ArcTan[ ( (-a ^2 ) Cot[ [Theta]] - w y
Tan[ [Theta]] ) / (a @ (a ^2 + ((w - y) ) ^2 + y ^2
Tan[ [Theta]] ^2 ) )]
Sin[2 [Theta]] ) / (2 + 2 k ^2 Sin[ [Theta]] ^2 ), [Theta] -> 0]] )
It takes less then 1 ms on version 5.0, while for version 5.2 it will take
forever (40.328 Second).
Timing[
Limit[ArcTan[ (a ((a k - w + y) ) Cot[ [Theta]] + k y ^2 Tan[
[Theta]] ) / (y @ (a ^2 + ((w - y) ) ^2 + y ^2 Tan[ [Theta]] ^2 ) )],
k -> (+ [Infinity] ), Direction -> 1]] )
It takes 76.782 Second is version 5.0, 100.187 Second in version 5.1.1 and
104.015 Second in version 5.2.
Not to mention it gives you some absurd results as well:
In version 5.0 computing following
{Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
{-(Pi/2), Pi/2}
while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
I could continue with list of examples that shows much more. But it only
proofs the fact that whoever makes these changes in old good mathematica
should be discharged. If some day I will get response from technical support
that contains something meaningful I will post an update. Till then I would
advise every body not to trust in results you get.
David Bailey
The reason that symbolic operations such as limits and integrals have
slowed down in later versions of Mathematica is that the software takes
a lot more care to get the right result - wrapping integrals in
conditions where necessary. In a sense, the slowdown hardly matters
because you only need to calculate a symbolic result once.
ArcTan is multi-valued, so Mathematica has simply picked a different
solution in the later version.
David Bailey
http://www.dbaileyconsultancy.co.uk
Murray Eisenberg
--
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
Daniel Lichtblau
> I am using Mathematica second year already, and found that each consequative
> version cuts off something good from what mathematica used to be.
>
> Contacting technical support only results in open ticket that never gets
> closed.
>
> Here some simple example you can run for youself:
> Timing[
> Limit[ (a ^2 k ^2 ArcTan[ ( (-a ^2 ) Cot[ [Theta]] - w y
> Tan[ [Theta]] ) / (a @ (a ^2 + ((w - y) ) ^2 + y ^2
> Tan[ [Theta]] ^2 ) )]
> Sin[2 [Theta]] ) / (2 + 2 k ^2 Sin[ [Theta]] ^2 ), [Theta] -> 0]] )
>
> It takes less then 1 ms on version 5.0, while for version 5.2 it will take
> forever (40.328 Second).
This Limit input will not parse to useful mathematical expression. Do
you have it in Mathematica InputForm?
> Timing[
> Limit[ArcTan[ (a ((a k - w + y) ) Cot[ [Theta]] + k y ^2 Tan[
> [Theta]] ) / (y @ (a ^2 + ((w - y) ) ^2 + y ^2 Tan[ [Theta]] ^2 ) )],
> k -> (+ [Infinity] ), Direction -> 1]] )
>
> It takes 76.782 Second is version 5.0, 100.187 Second in version 5.1.1 and
> 104.015 Second in version 5.2.
>
> Not to mention it gives you some absurd results as well:
>
> In version 5.0 computing following
>
> {Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
> Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
>
> {-(Pi/2), Pi/2}
>
> while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
I think this change was the correct decision. In essence we now override
the Direction when the point we approach is an infinity. This is largely
an acknowledgement that we do not support approaches to infinity except
along directed rays from the origin.
> I could continue with list of examples that shows much more. But it only
> proofs the fact that whoever makes these changes in old good mathematica
> should be discharged.
That would be me.
> If some day I will get response from technical support
> that contains something meaningful I will post an update. Till then I would
> advise every body not to trust in results you get.
I think it is safe to say that symbolic calculus is fraught with
problematic areas where, for example, mistakes involving a combination
of branch cuts and arithmetic with infinities can lead to erroneous
results. I do not see any evidence of this sort of phenomenon in the
example above, though. That was just a design decision. While you may
think it was the wrong thing to do, it is not symptomatic of deep
mathematical flaws.
I will note that by our metrics the number of open bugs in Limit dropped
sharply between versions 4 and 5 of Mathematica (I am not going to
quantify more closely than that).
Daniel Lichtblau
Wolfram Research
stephen layland
> I am using Mathematica second year already, and found that each consequative
> version cuts off something good from what mathematica used to be.
>
> Contacting technical support only results in open ticket that never gets
> closed.
>
> Here some simple example you can run for youself:
> Timing[
> Limit[ (a ^2 k ^2 ArcTan[ ( (-a ^2 ) Cot[ [Theta]] - w y
> Tan[ [Theta]] ) / (a @ (a ^2 + ((w - y) ) ^2 + y ^2
> Tan[ [Theta]] ^2 ) )]
> Sin[2 [Theta]] ) / (2 + 2 k ^2 Sin[ [Theta]] ^2 ), [Theta] -> 0]] )
Perhaps you meant:
(a^2 k^2 ArcTan[(-a^2 Cot[\[Theta]] - w y Tan[\[Theta]])/(
a (a^2 + ((w - y))^2 + y^2 (Tan[\[Theta]])^2))] Sin[2 \[Theta]])/(2 +
2 k^2 (Sin[\[Theta]])^2)
of which the limit _does_ take longer on version 5.1 and 5.2. This
seems to be because the Direction->Automatic is doing something
different. You might try experimenting some:
In[1]:= x=(a^2 k^2 ArcTan[(-a^2 Cot[\[Theta]] - w y Tan[\[Theta]])/(
a (a^2 + ((w - y))^2 + y^2 (Tan[\[Theta]])^2))] Sin[2
\[Theta]])/(2 +
2 k^2 (Sin[\[Theta]])^2);
In[2]:= Limit[x,\[Theta]->0]//Timing
Out[2]= {11.69 Second, 0}
In[3]:= Limit[x,\[Theta]->0,Direction->-1]//Timing
-16
Out[3]= {2.14238 10 Second, 0}
> Timing[
> Limit[ArcTan[ (a ((a k - w + y) ) Cot[ [Theta]] + k y ^2 Tan[
> [Theta]] ) / (y @ (a ^2 + ((w - y) ) ^2 + y ^2 Tan[ [Theta]] ^2 ) )],
> k -> (+ [Infinity] ), Direction -> 1]] )
This is also messed up, i presume due to problems with cut and pasting
inline formatted mathematica frontend text and someone else stripping \
characters. Try resending in InputForm. It's possible that this Limit
can also be fixed with some tweaking, or it's possible that this is a
bug.
> In version 5.0 computing following
>
> {Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
> Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
>
> {-(Pi/2), Pi/2}
> while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
I get Pi/2 (wihtout parens) for both directions:
In[5]:= Limit[ArcTan[k],k->Infinity,Direction->#]&/@{-1,1}
Pi Pi
Out[5]= {--, --}
2 2
At the risk of showing my mathematical weakness, isn't this correct, though?
Taking the limit as k approaches infinity from the right of infinity, should
still converge to Pi/2, no? It's been a while since my epsilon delta proofs,
so i could be wrong. It works for arbitrary q though:
In[6]:= Limit[ArcTan[k],k->q,Direction->#]&/@{-1,1}
Out[6]= {ArcTan[q],ArcTan[q]}
Hardly rigorous, but to my naive mind it would seem like 5.0 was wrong.
> I could continue with list of examples that shows much more. But it only
> proofs the fact that whoever makes these changes in old good mathematica
> should be discharged. If some day I will get response from technical support
> that contains something meaningful I will post an update. Till then I would
> advise every body not to trust in results you get.
That's quite a broad conclusion you're jumping to on minimal evidence.
All programs have bugs, it looks like you might have found one with
Limit. You should know that not _any_ computer algebra software can be
100% right all the time. We're just right more than other people! :)
I would invest more time to working with other aspects of Mathematica
before prematurely concluding:
"each consequative[sic] version cuts off something good from
what mathematica used to be"
and asking that intelligent people be canned, without whom you would
have had no Mathematica to complain about anyway.
--
/*------------------------------*\
| stephen layland |
| Documentation Programmer |
| http://members.wri.com/layland |
\*------------------------------*/
Curtis Osterhoudt
Version 5.1 handy. However, your limit-taking example wasn't typed in
well or something, I'm sure. What I suspect is the corrected version
follows:
{Limit[ArcTan[k], k -> +\[Infinity], Direction -> -1],
Limit[ArcTan[k], k -> -\[Infinity], Direction -> 1]}
Out[25]=
Pi Pi
{--, -(--)}
2 2
Version 5.1 gives you the correct answer, when the input is what (I
suspect) you meant. And I'll bet that 5.2 does, too.
Regards,
Curtis O.
Igor Touzov wrote:
>I am using Mathematica second year already, and found that each consequative
>version cuts off something good from what mathematica used to be.
>
>Contacting technical support only results in open ticket that never gets
>closed.
>
>Here some simple example you can run for youself:
>Timing[
>Limit[ (a ^2 k ^2 ArcTan[ ( (-a ^2 ) Cot[ [Theta]] - w y
>Tan[ [Theta]] ) / (a @ (a ^2 + ((w - y) ) ^2 + y ^2
>Tan[ [Theta]] ^2 ) )]
> Sin[2 [Theta]] ) / (2 + 2 k ^2 Sin[ [Theta]] ^2 ), [Theta] -> 0]] )
>
>It takes less then 1 ms on version 5.0, while for version 5.2 it will take
>forever (40.328 Second).
>
>Timing[
>Limit[ArcTan[ (a ((a k - w + y) ) Cot[ [Theta]] + k y ^2 Tan[
> [Theta]] ) / (y @ (a ^2 + ((w - y) ) ^2 + y ^2 Tan[ [Theta]] ^2 ) )],
>k -> (+ [Infinity] ), Direction -> 1]] )
>
>It takes 76.782 Second is version 5.0, 100.187 Second in version 5.1.1 and
>104.015 Second in version 5.2.
>
>Not to mention it gives you some absurd results as well:
>
>In version 5.0 computing following
>
>{Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
>Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
>
>{-(Pi/2), Pi/2}
>
>while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
>
>I could continue with list of examples that shows much more. But it only
>proofs the fact that whoever makes these changes in old good mathematica
>should be discharged. If some day I will get response from technical support
>that contains something meaningful I will post an update. Till then I would
>advise every body not to trust in results you get.
>
>
>
>
>
>
>
>
--
PGP Key ID: 0x235FDED1
Please avoid sending me Word or PowerPoint attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
Harold
It is well known in software engineering that any large system is never
fully debugged. The maintenance process either introduces more bugs,
or unexpectedly mucks up a larger process which uses code which is
debugged or extended in some "in the small" obvious way.
Dynamically bound code is very laborious to unravel when such
maintenance artifacts suddenly appear. Statically bound code is _much_
easier on maintenance programmers trying to fix such problems.
Does anyone know if Mathematica's "Solve" functions are dynamically
bound or statically bound internally? If they are all dynamically
bound, then unexpected results occurring after debugging or upgrading
are, I'm afraid, the rule of the day. I've never seen a book or paper
which lists more than vague pablums to keep such problems from
happening.
Inputs from anyone else on this subject would certainly be of interest
to me.
- Harold
David W. Cantrell
[snip]
> Not to mention it gives you some absurd results as well:
>
> In version 5.0 computing following
>
> {Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
> Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
>
> {-(Pi/2), Pi/2}
>
> while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
Perhaps you are confusing Infinity with ComplexInfinity. Note that
In[7]:= Limit[ArcTan[k], k -> ComplexInfinity, Direction -> -1]
Out[7]= -(Pi/2)
In[8]:= Limit[ArcTan[k], k -> ComplexInfinity, Direction -> 1]
Out[8]= Pi/2
using version 5.1 . Since ComplexInfinity has no direction associated
with it, we are at liberty to specify Direction when asking for the
limits, and the results are correct. But Infinity _already_ has an
associated direction
In[9]:= FullForm[Infinity]
Out[9]//FullForm= DirectedInfinity[1]
and thus it is at least strange to specify an optional Direction when
asking for a limit as k -> Infinity. Any optional Direction must be either
superfluous or contradictory to Infinity's innate direction. It seems
reasonable that Mathematica would therefore ignore any optional Direction
specification, and so I like the results given by the more recent versions.
However, I suggest that it might be nice, when asked for
Limit[ArcTan[k], k -> Infinity, Direction -> -1], if Mathematica preceded
its result of Pi/2 with a warning. It could say something like
"Optional Direction ignored; direction used is that of the specified
DirectedInfinity."
David
David W. Cantrell
> Igor Touzov wrote:
[snip]
> > Not to mention it gives you some absurd results as well:
> >
> > In version 5.0 computing following
> >
> > {Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
> > Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in
> > accurate
> >
> > {-(Pi/2), Pi/2}
> >
> > while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
>
> I think this change was the correct decision.
I agree.
> In essence we now override
> the Direction when the point we approach is an infinity.
True, if that infinity is a specific DirectedInfinity. But as I noted in my
previous response, the optionally specified Direction is not overridden if
the point we approach is ComplexInfinity. That's just as it should be IMO.
> This is largely
> an acknowledgement that we do not support approaches to infinity except
> along directed rays from the origin.
Best regards,
David Cantrell
Pratik Desai
>Igor Touzov wrote:
>
>
>>I am using Mathematica second year already, and found that each consequative
>>version cuts off something good from what mathematica used to be.
>>
>>Contacting technical support only results in open ticket that never gets
>>closed.
>>
>>Here some simple example you can run for youself:
>>Timing[
>>Limit[ (a ^2 k ^2 ArcTan[ ( (-a ^2 ) Cot[ [Theta]] - w y
>>Tan[ [Theta]] ) / (a @ (a ^2 + ((w - y) ) ^2 + y ^2
>>Tan[ [Theta]] ^2 ) )]
>> Sin[2 [Theta]] ) / (2 + 2 k ^2 Sin[ [Theta]] ^2 ), [Theta] -> 0]] )
>>
>>It takes less then 1 ms on version 5.0, while for version 5.2 it will take
>>forever (40.328 Second).
>>
>>
>
>This Limit input will not parse to useful mathematical expression. Do
>you have it in Mathematica InputForm?
>
>
>
>
>>Timing[
>>Limit[ArcTan[ (a ((a k - w + y) ) Cot[ [Theta]] + k y ^2 Tan[
>> [Theta]] ) / (y @ (a ^2 + ((w - y) ) ^2 + y ^2 Tan[ [Theta]] ^2 ) )],
>>k -> (+ [Infinity] ), Direction -> 1]] )
>>
>>It takes 76.782 Second is version 5.0, 100.187 Second in version 5.1.1 and
>>104.015 Second in version 5.2.
>>
>>Not to mention it gives you some absurd results as well:
>>
>>In version 5.0 computing following
>>
>>{Limit[ArcTan[k ], k -> + [Infinity], Direction -> -1],
>>Limit[ArcTan[k ], k -> + [Infinity], Direction -> 1]} results in accurate
>>
>>{-(Pi/2), Pi/2}
>>
>>while doing the same in version 5.2 gives you absurd {(Pi/2), Pi/2}.
>>
>>
>
>I think this change was the correct decision. In essence we now override
>the Direction when the point we approach is an infinity. This is largely
>an acknowledgement that we do not support approaches to infinity except
>along directed rays from the origin.
>
>
>
>
>>I could continue with list of examples that shows much more. But it only
>>proofs the fact that whoever makes these changes in old good mathematica
>>should be discharged.
>>
>>
>
>That would be me.
>
>
> > If some day I will get response from technical support
>
>
>>that contains something meaningful I will post an update. Till then I would
>>advise every body not to trust in results you get.
>>
>>
>
>I think it is safe to say that symbolic calculus is fraught with
>problematic areas where, for example, mistakes involving a combination
>of branch cuts and arithmetic with infinities can lead to erroneous
>results. I do not see any evidence of this sort of phenomenon in the
>example above, though. That was just a design decision.
>
Daniel ,
Speaking of such Design Descisions, Here is my pet-peeve on a completely
unrelated, I suppose Design Decision, matter with regards to Eigenvalues
and Eigenvectors, why do practically all Eigenvalues (I have seen other
packages to also starting with Math..) solvers sort thier complex
eigenvalue with respect to the real part. I had a hell of a time trying
to sort the eigenvalues (which was relatively easy) but to sort the
eigenvectors to match the eigenvalues was another matter.
I am sorry to jump on the soap box, but for what it is worth, in my
humble opinion, I would not do any mathematics of some complexity
without Mathematica, which I dont know is a good thing or bad.:)
Best Regards
Pratik Desai
> While you may
>think it was the wrong thing to do, it is not symptomatic of deep
>mathematical flaws.
>
>I will note that by our metrics the number of open bugs in Limit dropped
>sharply between versions 4 and 5 of Mathematica (I am not going to
>quantify more closely than that).
>
>
>Daniel Lichtblau
>Wolfram Research
>
>
>
--
Pratik Desai
Graduate Student
UMBC
Department of Mechanical Engineering
Phone: 410 455 8134
Daniel Lichtblau
Solve is implemented essentially entirely in C, which uses lexical
scoping. That said, I am not of the opinion that static vs. dynamic
scoping is such a big issue in regards to debugging, at least so far as
the Mathematica kernel is concerned. But this may be because the vast
majority of the kernel is either lexically scoped C code or Mathematica
code using Module, which (reasonably) effectively emulates classical
lexical scoping.
Daniel Lichtblau
Wolfram Research
Ronald Bruck
<lay...@wolfram.com> wrote:
[content deleted, only .sig reproduced]
> --
> /*------------------------------*\
> | stephen layland |
> | Documentation Programmer |
> | http://members.wri.com/layland |
> \*------------------------------*/
>
Well, this IS interesting. In another thread, someone laments that
the Mathematica programmers should be more involved with the
documentation.
This job title appears to put Stephen Layland square in the middle.
The classical complaint is that when you leave the documentation to the
programmers, it's unintelligible and leaves out lots of stuff; when you
hire a documentation team, they're often ignorant of the functionality
of the program, and leave out lots of stuff.
I'm not quite sure what a "documentation programmer" DOES. Any
elucidation? (Steve's web site is interesting, BTW.)
--Ron Bruck
David Park
It takes both. They have to work together. It certainly takes more than one
because we all have our blind spots. Good content, well presented, means
smart people with smart editors.
David Park
dj...@earthlink.net
http://home.earthlink.net/~djmp/
Maxim
<da...@wolfram.com> wrote:
>
> I think it is safe to say that symbolic calculus is fraught with
> problematic areas where, for example, mistakes involving a combination
> of branch cuts and arithmetic with infinities can lead to erroneous
> results. I do not see any evidence of this sort of phenomenon in the
> example above, though. That was just a design decision. While you may
> think it was the wrong thing to do, it is not symptomatic of deep
> mathematical flaws.
>
> I will note that by our metrics the number of open bugs in Limit dropped
> sharply between versions 4 and 5 of Mathematica (I am not going to
> quantify more closely than that).
>
>
> Daniel Lichtblau
> Wolfram Research
>
Certainly this model of directed infinities has some peculiar properties.
For example, some functional identities don't hold when infinite
quantities are involved:
In[1]:= E^Infinity*E^(I*Pi) == E^(Infinity + I*Pi)
Out[1]= False
So E^(a + b) != E^a*E^b. This also means that Exp is not a continuous
function anymore:
In[2]:= Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
Out[2]= Infinity
This is the result we get if we interchange Exp and Limit operations,
which is equivalent to continuity. However, the correct result is
-Infinity (Arg tends to Pi).
Also I think Mathematica often has problems with examples where the path
along which the limit is taken or the path of integration isn't a straight
line from the origin:
In[3]:= Integrate[(1 - Log[z])/z^2, {z, -1 - I, I*Infinity}]
Out[3]= (-(1/8) - I/8)*(3*Pi + 2*I*Log[2])
NIntegrate understands this as the integral along the line (-1 - I) + t*I
with t running from 0 to Infinity, and Integrate works the same way, as
can be seen from simpler examples. But then Out[3] is incorrect, because
the antiderivative Log[z]/z is discontinuous on the path of integration,
and the result is 2*Pi*I less than the correct value of the integral.
Maxim Rytin
m...@inbox.ru
Andrzej Kozlowski
On 12 Aug 2005, at 09:37, Maxim wrote:
> On Wed, 10 Aug 2005 07:42:08 +0000 (UTC), Daniel Lichtblau
> <da...@wolfram.com> wrote:
>
>
>>
>> I think it is safe to say that symbolic calculus is fraught with
>> problematic areas where, for example, mistakes involving a
>> combination
>> of branch cuts and arithmetic with infinities can lead to erroneous
>> results. I do not see any evidence of this sort of phenomenon in the
>> example above, though. That was just a design decision. While you may
>> think it was the wrong thing to do, it is not symptomatic of deep
>> mathematical flaws.
>>
>> I will note that by our metrics the number of open bugs in Limit
>> dropped
>> sharply between versions 4 and 5 of Mathematica (I am not going to
>> quantify more closely than that).
>>
>>
>> Daniel Lichtblau
>> Wolfram Research
>>
>>
>
> Certainly this model of directed infinities has some peculiar
> properties.
> For example, some functional identities don't hold when infinite
> quantities are involved:
>
> In[1]:= E^Infinity*E^(I*Pi) == E^(Infinity + I*Pi)
>
> Out[1]= False
>
> So E^(a + b) != E^a*E^b. This also means that Exp is not a continuous
> function anymore:
>
> In[2]:= Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
>
> Out[2]= Infinity
>
> This is the result we get if we interchange Exp and Limit operations,
> which is equivalent to continuity. However, the correct result is
> -Infinity (Arg tends to Pi).
This is a good example, which indeed brings up one of the problematic
aspects of Mathematica's "intuitive" and "informal" approach to
certain mathematical issues. I am very fond of this informality, but
I think that there are situations where it requires more care on the
part of the user than would be the case with a program that required
the user always to specify domains of functions, ground fields (real
complex) for algebraic structures etc.
In particular, when one considers such notions as of continuity and
limits one has to be clear about what topological space one is
working working with. Leaving this out and using "intuition" can
sometimes tie one in all sort of knots. Unfortunately, Mathematica's
"intuitive" approach in this case easily leads to confusion. The
problem is that Matheamtica allows one to combine together objects
belonging to different mathematical realms and perform operations on
them that only make sense in one of them.
One example of this is that Mathematica allows one to combine the
three objects, Infinity, -Infinty and ComplexInfinity in the same
expression. If one treats these as purely formal algebraic entities
one can probably state a consistent set of rules for dealing with all
three in this way, but it is a different matter if you want to
consider topological notions such as convergence. You then need a
well defined topological space and these three object do not belong
to the same one.
In fact there are at least three topological spaces that are relevant
in the context of Infinity, -Infinity and ComplexInfinity. First of
all there is the standard two-point comactification of the real line
(topologically the closed unit interval) [-Infinity,Infinity].
Secondly, there is the "Riemann-sphere" one point compactification of
the complex plane, consisting of all the complex numbers plus the
point at infinity, denoted in Mathematica by ComplexInfinity.
Last there is something problematic: another "compactification" of
the complex plane that turns it not into the Riemann sphere but into
a closed disk, with the complex plane corresponding to the open disk
whose boundary consists of DirectedInfinities in various directions.
You can think of it as the complex numbers plus entities of the form
DirectedInfinity[z], where z is a unit complex number. This
compactification includes Infinity=DirectedInfinity[1] and -
Infinity=DirectedInfinity[-1] but not ComplexInfinity. It is this
compactification that is often used by Mathematica. Unfortunately,
this compactification has rather bad and unintuitive properties
analytic properties.
One of them is that functions continuous on the complex plane
(interior of the disc) may not have a continuous extension to the
boundary. One such example is provided by the exponential function.
Consider the simple question related to Maxim's example: what should
be the value of Exp at DirectedInfinity[1]? One might think that it
is enough to take a sequence of points in the complex plane
converging to DirectedInfinity[1] and take the limit of this sequence
as the value of Exp. But, of course this can't be done in the obvious
way. Indeed, consider the sequences x=a+ I Pi and x=a + 2 I Pi as a -
> DirectedInfinity[1] along the positive real line. In both cases x
tends to DirectedInfinity[1] (although not along rays form 0!) but in
the first case we have
Simplify[Exp[a + I*Pi], a ∈ Reals]
-E^a
while in the second
Simplify[Exp[a + 2*I*Pi], a ∈ Reals]
E^a
Thus the first path should give us DirectedInfinity[-1] as the value
of Exp[DirectedInfinity[1]] while the other should give
DirectedInfinity[1]. This forces us to say that Exp[DirectedInfinity
[1]] is actually not defined continuously althogh Exp[Infinity] is
clearly Infinity. Here I am distinguishing Infinity (one of the ends
of the two point compactification of the real line) and
DirectedInfinity[1] but of course Mathematica considers them to be
the same. Actually Exp[DirectedInfinity[1]] should either be left
undefined or defined as ComplexInfinity.
Of course if Mathematica consistently used the Riemann sphere one
point compactification when dealing with complex infinities such
problems would not occur. In the discussed example the argument would
run as follows:
Consider the expression:
Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
To start with, the fact that we see x->Infinity eliminates the
possibility that x is a point on the Riemann sphere, since on the
Riemann sphere no such thing as Infinity exists. So we must x as a
real valued variable. That means of course that 2*I*ArtTan[x] is now
imaginary valued and x + 2*I*ArcTan[x] must lie on the Riemann
sphere. We can now use continuity and the answer turns out to be
uncontroversially
ComplexInfinity (there is no Infinity or -Infinity in the Riemann
sphere model). This would give ComplexInfinity as the final answer.
If we adopted this approach (Infinity and -Infinity are only used in
a purely real context -- the two point compactification of the real
line while in the complex context we always use ComplexInfinity) we
could still get the more informative answer -Infinity but we would
have to approach the problem differently. In order to avoid getting
ComplexInfinity (which is the only infinity in the complex plane) we
would have to make sure that the function whose limit we are seeking
is always real valued. For example, in the above case we could do:
Limit[ComplexExpand[Re[E^(x + 2*I*ArcTan[x])]],
x -> Infinity]
-Infinity
Of course the current version of Mathematica returns
Limit[ComplexExpand[E^(x + 2*I*ArcTan[x])],
x -> Infinity]
-Infinity
which while happens to be what we wanted is, in my opinion,
"incorrect", in view of what I tried to argue above. The correct
answer ought to be ComplexInfinity. I realize that to many this may
seem excessively pedantic but I can't see any other view to deal with
the problem pointed out by Maxim. In other words the proposed
solution is: return Infinity or -Infinity only as limits of functions
which are unambiguously real valued; in all other cases return
ComplexInfinity. DirectedInfinity[1] and DirectedInfinity[-1] should
be distingushed from Infinity and -Infinity.
Expressions such as Infinity + I*Pi should either be returned
unevaluated or interpreted as ComplexInfinity+I*Pi. One could still,
use DirectedInfinity for limits:
Limit[x, x -> DirectedInfinity[I]]
DirectedInfinity[I]
although this answer should (probably) be ComplexInfinity.
The answer ComplexInfininity I consider correct in all cases, though
of course to return it in all cases could sometimes be viewed a "loss
of information".
If anyone has a better idea that solves the problem pointed out by
Maxim then I would like to hear of it.
Andrzej Kozlowski
Daniel Lichtblau
> On Wed, 10 Aug 2005 07:42:08 +0000 (UTC), Daniel Lichtblau
> <da...@wolfram.com> wrote:
>
>
>>problematic areas where, for example, mistakes involving a combination
>>of branch cuts and arithmetic with infinities can lead to erroneous
>>results. I do not see any evidence of this sort of phenomenon in the
>>example above, though. That was just a design decision. While you may
>>think it was the wrong thing to do, it is not symptomatic of deep
>>mathematical flaws.
>>
>>I will note that by our metrics the number of open bugs in Limit dropped
>>sharply between versions 4 and 5 of Mathematica (I am not going to
>>quantify more closely than that).
>>
>>
>>Daniel Lichtblau
>>Wolfram Research
>>
>
>
properties.
> For example, some functional identities don't hold when infinite
> quantities are involved:
>
> In[1]:= E^Infinity*E^(I*Pi) == E^(Infinity + I*Pi)
>
> Out[1]= False
>
> So E^(a + b) != E^a*E^b. This also means that Exp is not a continuous
> function anymore:
>
> In[2]:= Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
>
> Out[2]= Infinity
>
> This is the result we get if we interchange Exp and Limit operations,
> which is equivalent to continuity. However, the correct result is
> -Infinity (Arg tends to Pi).
This was the sort of example I had in mind. Though I will note that we
have made modest improvement in our development version:
In[1]:= Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
Out[1]= -Infinity
> Also I think Mathematica often has problems with examples where the
path
> along which the limit is taken or the path of integration isn't a
straight
> line from the origin:
>
> In[3]:= Integrate[(1 - Log[z])/z^2, {z, -1 - I, I*Infinity}]
>
> Out[3]= (-(1/8) - I/8)*(3*Pi + 2*I*Log[2])
>
> NIntegrate understands this as the integral along the line (-1 - I) +
t*I
> with t running from 0 to Infinity, and Integrate works the same way, as
> can be seen from simpler examples. But then Out[3] is incorrect,
because
> the antiderivative Log[z]/z is discontinuous on the path of
integration,
> and the result is 2*Pi*I less than the correct value of the integral.
>
> Maxim Rytin
> m...@inbox.ru
I doubt Integrate understands this in any nice way. In general if an
endpoint is infinite, Integrate will have its best chance if the other
point is on the line connecting the origin to that infinite endpoint.
Daniel Lichtblau
Wolfram Research
Andrzej Kozlowski
although it still leads to somewhat strane consequences
(particularly, as I will show at the end, in Maxim's case). In any
case the inspiration for the following whether right or wrong came
form a remark of Daniel Lichtblau in a private response to my posting:
> The general issue of a finite offset being discarded from a
> directed infinity is problematic.
I think this is the central issue. Any topological model of
"infinities" in the complex plane that can resolve the
contradictions that appear in the present one would have, it seems,
to allow for more infinities than just things of the form
DirectedInfinity[z], where z is a unit complex number. I don't think,
however, one can construct such a model unless one starts with a
larger space than the complex plane itself. Below I shall try first
to describe a possible model and then show how it would work in
practice. Of course, one may question the need to have a topological
model at all; one could just add certain rules for behaviour at
infinity and hope for the best. However, with this approach I think
it is inevitable that it will always be possible contradictions of
the kind that arise in the present model.
The essential idea is this. In the current model and "infinity" in
the complex plane essentially corresponds to one of the directions
leading form the origin of the complex plane to infinity. As I
pointed out earlier, it seems to me that there is no hope to make
this model work well analytically. The model that I am proposing
will consider as "an infinity" any infinite path originating
anywhere in the complex plane. Probably it is a good idea for two
such paths to be identified as "the same" infinity when they coincide
"after some finite time". To define a suitable topological space one
can proceed as follows. We consider the space Maps(I,C) of all
continuous paths in C (the complex plane) that is continuous paths
from the unit interval I to C. This space is diffeomorphic to the
space of Maps(I,Int D), where the Int D is the interior of the closed
unit disc D, that is the open unit disc. Now, when we compactify this
space we will get just Maps(I,D), which is differomorphic to the
compactification of Map(I,C). Intiuitively our space now consists of
all finite paths in C and all unbounded paths in C with one end point
"at infinity". The points of C could now be identified with constant
paths the infinities with all paths leading from a point of C to
infinity. The problem with this space is that we feel that infinite
paths which differ only inside a compact region should represent the
same infinity. So we can perform this identification and obtain a
topological space with the resulting identification topology.
We obtain a topological space CC whose set of points consists of the
usual points of C, all "finite" directed paths in C and all infinite
directed paths, where two infinite paths are considered the same if
they differ only inside a compact subset of C. These infinite paths
are our infinities. They include all the standard DirectedInfinity[z]
but in addition lots others.
It is easy to see that any analytic functions C->C can be extended to
continuous function CC->CC. We simply send points to corresponding
points, paths to corresponding paths and infinite paths to
corresponding infinite paths.
Now when we think of an infinity as an "equivalence class of paths"
it is easy to see what p+K is, where p is any finite complex number
and K is a "infinite directed path". It is simply the infinite
directed path K translated by the vector p. Thus
in CC the expression Infinity + Pi * I is no longer equal to
Infinity. The former is "an infinity" that can be represented by an
infinite path obtained by starting at any point z with Im[z]=Pi and
then continuing horizontally to the right and this is now different
from the one given by moving radially from 0 to infinity along the
positive real axis.
On the other hand 2+Infinity (same as 2+DirectedInfinity[1]) is
clearly just Infinity while 2I + DirectedInfinity[I] is
DirectedInfinity[I] etc.
I think with all the above we now have a fairly solid topological
model and we can solve some of the problems that appear in the
present one.
First consider the case:
Exp[Limit[x+Pi*I,x->Infinity] ]
We first compute Limit[x+Pi*I,x->Infinity]. This represents a path to
infinity along the line Im[z]=Pi and denoted by Infinity+Pi*I. We
then apply Exp to all the points on this path and clearly obtain the
path that runs along the real line in the negative direction, in
other words -Infinity. No problem here.
However, consider now Maxim's case:
Exp[Limit[x+2*ArcTan[x]*I,x->Infinity] ].
This time Limit[x+2*ArcTan[x]*I,x->Infinity] represents a different
path, given in parametric coordiantes by {x,2*ArtTan[x]}, as x goes
along the real axis form 0 to Infinity. Suppose we apply Exp to the
points in the complex plane on this path. We obtain the path that
indeed goes to infinity, but it never moves along the real axis but
along an infinite curve in the complex plane. Thus according to this
model the answer is not -Infinity but another "infinity", for which
unfortunately we lack a suitable notation. Note however that
according to our model the limit of the real part of the above
expression is indeed -Infinity, which is something that the current
Mathematica already knows:
Limit[Re[E^(x + 2*I*ArcTan[x])], x -> Infinity]
-Infinity
Having considered all this I have come to an unexpected conclusion. I
am no longer convinced that the new answer returned (according to
Daniel Lichtblau) by development version of Mathematica and stated
by Maxim as the correct one, namely
Limit[E^(x + 2*I*ArcTan[x])], x -> Infinity] == -Infinity
can be made mathematical sense of in any rigorous mathematical model
of infinities. I can see a rigorous way to show that this answer is
ComplexInfinity in the Riemann sphere model and I think I can see how
to get the answer "some kind of infinity" (the model sketched above).
I can't see to get the answer -Infinity, (even though it is suggested
by intuition). I may be confused, if anyone can think of a "rigorous"
way to prove that the answer really "should be" -Infinity I would
like to see the argument.
Andrzej Kozlowski
On 12 Aug 2005, at 17:14, Andrzej Kozlowski wrote:
> Infinity=DirectedInfinity[1] and -Infinity=DirectedInfinity[-1]
> Limit[E^(x + 2*I*ArcTan[x]), x -> Infinity]
>
Andrzej Kozlowski
it a path not contained in any compact subset of the complex plane.
Perhaps one needs to be a little more careful in defining them to
avoid any possible problems with space filling curves which do not
really define any "infinity". These infinite paths are mean to
correspond to curves from a point in the interior of the unit disc to
the boundary of the disc. By choosing a diffeomorphism between the
open unit disc and the complex plane we can obtain all the "infinite
paths" in the complex plane.
Andrzej Kozlowski
>>>> I think it is safe to say that symbolic calculus is fraught with
>>>> problematic areas where, for example, mistakes involving a
>>>> combination
>>>> of branch cuts and arithmetic with infinities can lead to erroneous
>>>> results. I do not see any evidence of this sort of phenomenon in
>>>> the
>>>> example above, though. That was just a design decision. While
>>>> you may
>>>> think it was the wrong thing to do, it is not symptomatic of deep
>>>> mathematical flaws.
>>>>
>>>> I will note that by our metrics the number of open bugs in Limit
>>>> dropped
>>>> sharply between versions 4 and 5 of Mathematica (I am not going to
>>>> quantify more closely than that).
>>>>
>>>>
>>>> Daniel Lichtblau
>>>> Wolfram Research
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> interval) [-Infinity,Infinity]. Secondly, there is the "Riemann-