Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.soft-sys.math.mathematica > #1886 > unrolled thread

Re: Limit[f[x], x->a] vs. f[a]. When are they equal?

Back to article view | Back to comp.soft-sys.math.mathematica

Contents

  Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-04-26 10:51 +0000
    Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Noqsi <noqsiaerospace@gmail.com> - 2011-04-30 09:51 +0000
      Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-05-02 10:51 +0000
    Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Richard Fateman <fateman@cs.berkeley.edu> - 2011-04-28 10:35 +0000
    Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Andrzej Kozlowski <akoz@mimuw.edu.pl> - 2011-04-28 10:36 +0000
    Re: Limit[f[x], x->a] vs. f[a]. When are they equal? Richard Fateman <fateman@eecs.berkeley.edu> - 2011-04-29 11:29 +0000

#1886 — Re: Limit[f[x], x->a] vs. f[a]. When are they equal?

On 26 Apr 2011, at 10:43, Richard Fateman wrote:

> Back to Andrzej's note.
>
>  Sin(1/z) as z->0 is not the same as Sin[z] as z->ComplexInfinity.
>
> 1/z as z->0 has a neighborhood. There is no neighborhood around
> ComplexInfinity.
>
> (I am not, incidentally, proposing that I have a complete solution to
> these issues.)


I have skipped the rest of the post since I have written a great deal about this on this very forum in the past and, unlike some, I do not have the habit of repeating myself ad nauseam. However, the above point involves basic confusion. Mathematica computes only directional limits.

Hence
 Limit[Sin[1/z], z -> 0]
Interval[{-1,1}]
is  a real interval (since the default direction is -1) and


In[31]:= Limit[Sin[1/z], z -> 0, Direction -> I]

Out[31]= DirectedInfinity[I]

and so on. In Mathematica is no sense in taking limits as z ->ComplexInfinity without specifying a direction as there is no natural direction. If you specify the same direction, you will get the same answer:

In[25]:= Limit[Sin[1/z], z -> 0, Direction -> I]

Out[25]= DirectedInfinity[I]

In[27]:= Limit[Sin[z], z -> ComplexInfinity, Direction -> I]

Out[27]= DirectedInfinity[I]

Does ComplexINfinity not have neighbourhoods? It depends, of course, how you interpret it. It certainly has neighborhoods  if you interpret it as the the opposite pole to zero on the Riemann sphere, which is, in fact, what most people expect.



Andrzej Kozlowski

[toc] | [next] | [standalone]

#1921

On Apr 29, 5:29 am, Richard Fateman <fate...@eecs.berkeley.edu> wrote:
> On 4/28/2011 1:30 AM, Andrzej Kozlowski wrote:

> >   In fact I once suggested that an options should be available for the user to decide which compatification he wants to use when taking limits etc,
>
> Sounds plausible to me.
>>   but now I think that this additional functionality would almost never be used and thus is not worth the effort.
> to require the user
> to check something that the system could check is to say, in effect, we
> could make Mathematica do mathematics correctly, but we will settle for
> it doing mathematics "pretty well" and in particular, sometimes wrong.

One difficulty here is that few Mathematica users would understand how
to navigate the maze, if that was the general approach. The issue
you've identified is only one in a huge set of potential "mathematical
context" issues that one might address. Like essentially everyone who
applies mathematics, you yourself throw around terms like "integral",
"function", "neighborhood", "(in)finite", "continuous", and
"differentiable" without stating the precise mathematical context in
which you are speaking. It would be a huge burden to do so, even for
the small minority who really understand these issues.

As for mathematical correctness, well, there exist computer proof
verification systems. They are much more limited in scope, and much
harder to use than Mathematica. Mathematica is more focused on
applications. Usually, the "application context" is stricter
discipline anyway. There is no guarantee that a well-formed
mathematical expression or a formally correct mathematical result
makes physical sense. Nor, in this case, have you identified a result
that is actually incorrect: you merely found a case where you got
different answers to different questions.

> Or perhaps we really don't know how to do this correctly, and we should
> just say (as I've suggested a day or two ago) that it be documented.

The documentation is already impenetrable, and it should not assume
the additional burden of providing a graduate-level education in
mathematics to Mathematica users. Mathematica relates well to the
common practice of applied mathematics education, where this kind of
mathematical context issue is not covered in any great detail. It
would be too distracting.

[toc] | [prev] | [next] | [standalone]

#2025

On 4/30/2011 2:51 AM, Noqsi wrote:
> On Apr 29, 5:29 am, Richard Fateman<fate...@eecs.berkeley.edu>  wrote:
>> On 4/28/2011 1:30 AM, Andrzej Kozlowski wrote:
>
>>>    In fact I once suggested that an options should be available for the user to decide which compatification he wants to use when taking limits etc,
>>
>> Sounds plausible to me.
>>>    but now I think that this additional functionality would almost never be used and thus is not worth the effort.
>> to require the user
>> to check something that the system could check is to say, in effect, we
>> could make Mathematica do mathematics correctly, but we will settle for
>> it doing mathematics "pretty well" and in particular, sometimes wrong.
>
> One difficulty here is that few Mathematica users would understand how
> to navigate the maze, if that was the general approach. The issue
> you've identified is only one in a huge set of potential "mathematical
> context" issues that one might address.

I doubt that it is a huge set. However, the further one departs from 
mathematical correctness in the 'basics', the larger that set becomes.

  Like essentially everyone who
> applies mathematics, you yourself throw around terms like "integral",
> "function", "neighborhood", "(in)finite", "continuous", and
> "differentiable" without stating the precise mathematical context in
> which you are speaking.

The nice thing about much of mathematics is that more advanced notions 
(like other kinds of 'integrals') are generally an extension of the more 
elementary notions, and so someone who delves in the elementary world 
need not know that there are these extensions.

Sometimes there are problems -- e.g. for someone who knows only about 
real numbers will be perplexed by complex numbers coming out of Solve, say.


  It would be a huge burden to do so, even for
> the small minority who really understand these issues.

Quite the contrary.  Getting the basics wrong is a burden to people who 
understand or don't understand --- sometimes.

You could, for example, create a version of Mathematica that did not 
know about complex numbers.  Do you think it would be worthwhile?


>
> As for mathematical correctness, well, there exist computer proof
> verification systems.

You miss the point.  You can't prove things in Mathematica correct 
because they are (in ways I've pointed out), mathematically wrong.
End of story.

A proof system starts with axioms and proof rules and such, and 
sometimes is able to generate a verification of correctness of a proof 
or perhaps of a kind of program.

If the procedures in the programming language do not correctly reflect 
mathematical properties, then the chance that you will be able to prove 
that manipulations are correct, is dramatically reduced.

  They are much more limited in scope, and much
> harder to use than Mathematica. Mathematica is more focused on
> applications.

I think you are misreading the literature on proof systems.  They can 
prove (or attempt to ...) anything formal.

  Usually, the "application context" is stricter
> discipline anyway. There is no guarantee that a well-formed
> mathematical expression or a formally correct mathematical result
> makes physical sense. Nor, in this case, have you identified a result
> that is actually incorrect: you merely found a case where you got
> different answers to different questions.
>
>> Or perhaps we really don't know how to do this correctly, and we should
>> just say (as I've suggested a day or two ago) that it be documented.
>
> The documentation is already impenetrable, and it should not assume
> the additional burden of providing a graduate-level education in
> mathematics to Mathematica users.

No, but it should say what the program does.
What are the valid inputs to Limit ?  Is ComplexInfinity not allowed? 
What else?
What are the valid outputs from Limit?  How is it that two equivalent 
expressions can have different limits?  (e.g. when limit returns an 
Interval...)
what does this mean for mathematics, where limits presumably do not have 
this property?

  Mathematica relates well to the
> common practice of applied mathematics education, where this kind of
> mathematical context issue is not covered in any great detail. It
> would be too distracting.
>
This is, I think, an insult to applied mathematics educators.
RJF

>
>
>

[toc] | [prev] | [next] | [standalone]

#1954

On 4/26/2011 3:51 AM, Andrzej Kozlowski wrote:
.. skipped and snipped...


> and so on. In Mathematica is no sense in taking limits as z ->ComplexInfinity

> without specifying a direction as there is no natural direction.

So the idea of a limit as x->x0  makes no sense if x0 is a member of 
some set of numbers, symbols, whatever.  Maybe the documentation for 
Limit should provide some information on this?

I don't know what you have written previously on this topic and have no 
intention of looking it up.  But in a system which includes 
ComplexInfinity, a concept which unifies at one "place" positive real 
infinity and negative real infinity, it becomes tricky to also have the 
separate values +Infinity and -Infinity.

some of my thoughts are in section 4 of
http://www.cs.berkeley.edu/~fateman/papers/interval.pdf

RJF

[toc] | [prev] | [next] | [standalone]

#1965

On 28 Apr 2011, at 03:29, Richard Fateman wrote:

> On 4/26/2011 3:51 AM, Andrzej Kozlowski wrote:
> .. skipped and snipped...
>
>
>> and so on. In Mathematica is no sense in taking limits as z ->ComplexInfinity
>
>> without specifying a direction as there is no natural direction.
>
> So the idea of a limit as x->x0  makes no sense if x0 is a member of some set of numbers, symbols, whatever.  Maybe the documentation for Limit should provide some information on this?
>
> I don't know what you have written previously on this topic and have no intention of looking it up.  But in a system which includes ComplexInfinity, a concept which unifies at one "place" positive real infinity and negative real infinity, it becomes tricky to also have the separate values +Infinity and -Infinity.
>
> some of my thoughts are in section 4 of
> http://www.cs.berkeley.edu/~fateman/papers/interval.pdf
>
> RJF
>
>
>
>
>


The basic problem is one that is shared by all algebra systems that do not require the user to specify the mathematical context he is working in. Thus Mathematica allows one to perform all kinds of operations for which there is no mathematical context at all, e.g. adding strings to numbers etc. I think anyone who has grasped the basic principle involved here (i.e. that you have to think about what you are doing) will have any problems and I don't see much point in expending the already enormous documentation to deal with what should be obvious to any person intelligent enough to make use of Mathematica.

The problem with various kinds of infinities (and by the way, they all have FullForm DirectedInfinity[z], with Infinity being DirectedInfinity[1], - Infinity, DirectedInfinity[-1] and ComplexInfinity - DirectedInfinity[])  arise from the fact that although the real numbers are naturally embedded in the complex numbers (e.g. as real Banach algebras), the compactifications that are normally used to  deal with infinite limits etc. are different and incompatible. The space of real numbers is usually compactified by adding two points Infinity and -Infinity, the space of complex numbers is compactified by adding just one point - ComplexInfinity. In fact, one can also compactify the real numbers by adding just one Infinity (making +Infinity and -Infinity equal) and getting topologically a circle which is embedded in the Riemann sphere, but this is rarely done as it is not very useful in analysis. In the complex case the reason for using one point compactification is that one gets the Riemann sphere, which  is a complex manifold, so one can extend the concept of analycity to functions defined on the Riemann sphere and taking values in the Riemann sphere. Of course, in the complex case one can also use the "real" compactification, obtained by adding DirecttedInfinity[z] for every direction z. In this case one gets a space diffeomorphic to the two dimensional disc - which is not a complex manifold but whose interior is diffeomorphic to the complex plane. Thus the concepts of limits, derivatives etc are still preserved and one can obtain a lot of useful information by using this approach.

Although these two compactifications are not compatible, there is no reason why they should be any more confusing to an informed user than the ability to add strings to numbers is. In fact I once suggested that an options should be available for the user to decide which compatification he wants to use when taking limits etc, but now I think that this additional functionality would almost never be used and thus is not worth the effort. In my opinion things work pretty well as there are now (barring bugs and user ignorance, both of which are fundamental "facts of life").

Andrzej Kozlowski

[toc] | [prev] | [next] | [standalone]

#2000

On 4/28/2011 1:30 AM, Andrzej Kozlowski wrote:
>
> ...
>> RJF said:
>> So the idea of a limit as x->x0  makes no sense if x0 is a member of some set of numbers, symbols, whatever.  Maybe the documentation for Limit should provide some information on this?
>>
>>
>
> AK said:
> Although these two compactifications are not compatible,

So you agree with me.
> there is no reason why they should be any more confusing to an informed user than the ability to add strings to numbers is.
Note, however,  that "string" and "number" are different types with 
different Heads.  ComplexInfinity and Infinity have the same Heads.
Neither of these infinities though, is NumberQ.  Which may sometimes be 
a good idea, depending.



>   In fact I once suggested that an options should be available for the user to decide which compatification he wants to use when taking limits etc,
Sounds plausible to me.
>   but now I think that this additional functionality would almost never be used and thus is not worth the effort.
I hardly ever use the emergency blinker in my car. Maybe I should have it removed.

>   In my opinion things work pretty well as there are now (barring bugs and user ignorance, both of which are fundamental "facts of life").
There is no way to legislate against ignorance.  But to require the user 
to check something that the system could check is to say, in effect, we 
could make Mathematica do mathematics correctly, but we will settle for 
it doing mathematics "pretty well" and in particular, sometimes wrong.

Or perhaps we really don't know how to do this correctly, and we should 
just say (as I've suggested a day or two ago) that it be documented. For 
example we could specify that Limit computes the real-valued limit of a 
real-valued function at a real-valued limit point approached from a 
real-valued direction in a continuous fashion.   We could, starting with 
that, allow (real positive) infinity, and consequently also its negative.


> Andrzej Kozlowski
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.soft-sys.math.mathematica

csiph-web