On a general representation for singularities and infinities

[Tom Bachmann]

Dear list,

while beginning to work with the codebase I have stumbled a couple of
times over the aforementioned problem. A situation occured in bug
1321; also bug 360 is directly related. The "official" ticket is 2200.
You can find there also a link to previous discussion, though under a
non-ideal heading.

Here are my thoughts on how this situation may be remedied. I am not
proposing to implement this (although I may if consensus emerges and
nobody else wants to).


Let me first try to clarify the epistemology. There are three kinds of
objects involved: expressions, "limit directions" and "limit
descriptions".

Expressions are the things we want to take limits of, like cos(x), 1/
x^2, exp(z), ...

Limit directions describe how the limit is to be taken.
In R (reals), this generally is a point and a side of approach, or +oo
or -oo.
In general topological spaces limit directions can be described by
filters (as explained in the previous discussion; I think in practice
filters will hardly be useful for a CAS and limit directions will be
described otherwise).
Other common filters are: a point of C (complex plane), approached
from all sides. This is the definition of limit of normed spaces and
hence generalises. Also ComplexInfinity is a well-defined limit
direction.

Limit descriptions are the answers of limits.
These can be very complicated, if a lot of information is to be
conveyed. For example:

* limits can exist as ordinary numbers, this is the base case
(limit(sin(x), x, 0) == 0 for example)
* limits taken in R can be +oo or -oo in a well-defined sense, e.g.
limit(x**2, x, oo)
* limits such as limit(sin(x), x, oo) have to be described in a more
complicated way. The result could say "point of accumulation for any x
in [-1, 1]".
* limits of meromorphic functions in C can be classified as a number,
a pole of order n (for some n > 0), or essential singularity
* in general, not much can be said. Even a rational function of two
variables can have limits that cannot usefully be interpreted as a
number or infinity.


Much confusion arises, I think, because objects of the three different
classes are often described by the same names:

* a number can be seen as an expression and as a limit description,
and also as a limit direction at least two different ways (over C and
over R)
* oo can be seen as both a singularity description and as a limit
direction
* ditto for zoo

Moreover +-oo can be seen as two points of an extended real line
(topologically its end-compactification). Similarly zoo can be seen as
a point on the riemann sphere.

Finally, we typically want to be able to do at least some arithmetic
with infinities, to write things such as oo+1 == oo. SympyCore calls
this extended number system.


*Use cases*

My primary use case is for code in sympy to be able to understand the
result of a limiting operation. In particular there is currently no
(good) way to interpret the result of e.g. limit(Wild('a')*x, x, oo)
as being "infinity" (to the end user a*oo is visibly infinity, but
(a*oo).is_unbounded is None)

For end-users, a useful result in e.g. limit(sin(x), x, oo) would be
desirable.

Someone has expressed interest (in the other thread) in computing
limits in several variables, this certainly needs a framework along
the lines of the above.


*Semantics for extended numbers*

I think extended number semantics should be given only to limit
descriptions, not to limit directions. Following SympyCore, the
following constraint should be enforced by all core:

if oper denotes an operation that is to be implemented for limit
descriptions s1 and s2 (think oo), then s1 oper s2 == s3 if and only
if for all expressions e1, e2 and all limit directions d, such that
limit(e1, d) == s1, limit(e2, d) == s2, we also have limit(e1 oper e2,
d) == s3.
The symbol NaN could be used to designate that no s3 fulfilling this
condition exists.

In particular from this we can prove:
* oo + oo == oo
* oo + c == oo for c in R
* oo * c == oo for c > 0
* oo * oo == oo
* oo - oo == NaN
(where "oo" denotes the usual limit description. For example
limit(f(x), a) == oo, where a is the number a as a limit direction in
the reals, if and only if for all M > 0 there exists e > 0 such that
whenever |x - a| < e, then f(x) > M)

Similarly we can prove
* zoo + c == zoo for c in C
* zoo * c = zoo for c != 0
* zoo*zoo == zoo
* zoo + zoo == NaN
(where zoo denotes the usual thing, i.e. limit(f(z), a) == zoo where a
the complex number a as a limit description in the complex numbers if
and only if for all M > 0 there exists e > 0 such that whenever |z -
a| < e, then |f(z)| > M. In particular limit(exp(1/z), 0) != zoo)

Things like zoo+oo are completely undefined in this scheme of things,
and should probably be left opaque.

*Implementation*

Here I don't know a lot to say at all. Limit descriptions should
derive from Expr, possibly even Number. Limit directions should not.
The "honest-to-got" limit evaluation function should take as arguments
an expression, a variable and a limit direction and returns a limit
description. A more user-friendly wrapper can query things like the
type of symbol and then construct a call to call to the "honest-to-
god" function. E.g. (pseudocode)

def limit(ex, var, a):
if var.is_real:
if a.is_bounded:
return limitHonest(ex, x, RealDirection(a, twoSided=True))
else:
return limitHonest(ex, x, RealDirection(a))
else: # assume a is complex for now
return limitHonest(ex, x, ComplexDirection(a))

I have no idea if effective algorithms exist for determining limiting
behaviours in more general cases.


This is my two cents. I know I am just getting started working with
sympy, so there are probably many things wrong with this proposal. I'm
just trying to clarify things and get discussion started.

Thanks,
Tom

[Aaron S. Meurer]

Why do you use Wild('a')?

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>

[smichr]

You say:

In particular there is currently no
(good) way to interpret the result of e.g. limit(Wild('a')*x, x,
oo)
as being "infinity" (to the end user a*oo is visibly infinity,
but
(a*oo).is_unbounded is None)

But 0 trumps oo, so if `a=0` this is 0, right? It could also be -oo or
zoo given the right value of `a`, so it seems ok to me to leave it as
`a*oo`.

[Aaron S. Meurer]

Neither one trumps the other. That is why 0*oo returns nan.

Aaron Meurer

[Chris Smith]

Hmmm...I thought I left such behavior in (`x*oo`) after a suggestion of yours perhaps thinking that the above was true...perhaps you had the -oo in mind? Regarding the other,
[ http://www.philforhumanity.com/Zero_Times_Infinity.html ]

/c

[Tom Bachmann]

> > My primary use case is for code in sympy to be able to understand the
> > result of a limiting operation. In particular there is currently no
> > (good) way to interpret the result of e.g. limit(Wild('a')*x, x, oo)
> > as being "infinity" (to the end user a*oo is visibly infinity, but
> > (a*oo).is_unbounded is None)
>
> Why do you use Wild('a')?
>

Hm. I think somewhere I found something like acos(1+a*x**2).series(x).
Perhaps just using y instead of a would be more sensible. In any case
this code should return an error. It has to evaluate the
limit(acos(1+a*x**2).diff(x),x,0) which currently returns I*a*oo.

A simpler example would be limit(y*x, x, oo). What should this return?
It currently returns y*oo which is perhaps helpful for the user, but
not for code. How is code supposed to interpret this - in fact how
even recognise it?

Strictly speaking of course, the limit should either be left
unevaluated, or returned as a case expression {oo: y>0, -oo: y<0, 0:
y==0}. Anyway there should be a way for the above code to figure out
that in some cases this is unbounded, and hence should return an
error.

I initially suggested simply to add a .is_potentially_unbounded flag,
but goodok objected that this was not the "mathematically right
way" (and I agree, hence my longer proposal).

[Ronan Lamy]

For me, no matter what we call them, limit directions *are* filters.
A priori, I agree that going back to the theoretical definition will
often not be terribly useful in practice. However, the definition is
very important for the design because it ensures that we can operate on
these objects in a perfectly consistent manner.

>
> Limit descriptions are the answers of limits.
> These can be very complicated, if a lot of information is to be
> conveyed. For example:
>
> * limits can exist as ordinary numbers, this is the base case
> (limit(sin(x), x, 0) == 0 for example)
> * limits taken in R can be +oo or -oo in a well-defined sense, e.g.
> limit(x**2, x, oo)
> * limits such as limit(sin(x), x, oo) have to be described in a more
> complicated way. The result could say "point of accumulation for any x
> in [-1, 1]".
> * limits of meromorphic functions in C can be classified as a number,
> a pole of order n (for some n > 0), or essential singularity
> * in general, not much can be said. Even a rational function of two
> variables can have limits that cannot usefully be interpreted as a
> number or infinity.
>

Limit descriptions are filters as well (except that I don't see how to
express the order of a pole with a filter, but I'd argue that it is
singularity classification, not limit description). For any filter X,
limit(f(x), x -> X) is the filter f(X), i.e. the filter generated by the
set {f(A)| A ∈ X}.

>
> Much confusion arises, I think, because objects of the three different
> classes are often described by the same names:
>
> * a number can be seen as an expression and as a limit description,
> and also as a limit direction at least two different ways (over C and
> over R)
> * oo can be seen as both a singularity description and as a limit
> direction
> * ditto for zoo
>
> Moreover +-oo can be seen as two points of an extended real line
> (topologically its end-compactification). Similarly zoo can be seen as
> a point on the riemann sphere.
>
> Finally, we typically want to be able to do at least some arithmetic
> with infinities, to write things such as oo+1 == oo. SympyCore calls
> this extended number system.
>

All this works just as well if oo and zoo are defined as filters.

>
> *Use cases*
>
> My primary use case is for code in sympy to be able to understand the
> result of a limiting operation. In particular there is currently no
> (good) way to interpret the result of e.g. limit(Wild('a')*x, x, oo)
> as being "infinity" (to the end user a*oo is visibly infinity, but
> (a*oo).is_unbounded is None)
>
> For end-users, a useful result in e.g. limit(sin(x), x, oo) would be
> desirable.
>

If oo is a filter, sin(oo) is perfectly well defined: it's the filter
generated by [-1, 1].

Arithmetic between numbers and filters can be defined via f(X) =
limit(f(x), x ->X) where f is an ordinary real or complex function, i.e.
1 + oo = limit(1 + x, x -> oo) = oo.
Arithmetic between filters can be defined via f(X, Y) = limit(f(x,y),
(x, y) -> X×Y). This gives the same results as above except where NaN is
involved.
oo - oo is well defined. Going back to the definition of filters, it's
easy to see that its value is the filter generated by R, which should be
called something like "AnyReal". Similarly, zoo + oo is AnyComplex.
Turning now to 0 * +oo, we see that it's important to make a difference
between 0 as a real number and 0 as limit direction. If 0 is a real
number, then according to the first definition above 0 * oo = 0. If we
consider the neighbourhood of 0, calling the corresponding filter '0~'
to avoid ambiguity, then the second definition applies
and we have 0~ * oo = AnyReal, 0~ * zoo = AnyComplex, etc.

> *Implementation*
>
> Here I don't know a lot to say at all. Limit descriptions should
> derive from Expr, possibly even Number. Limit directions should not.
> The "honest-to-got" limit evaluation function should take as arguments
> an expression, a variable and a limit direction and returns a limit
> description. A more user-friendly wrapper can query things like the
> type of symbol and then construct a call to call to the "honest-to-
> god" function. E.g. (pseudocode)
>
> def limit(ex, var, a):
> if var.is_real:
> if a.is_bounded:
> return limitHonest(ex, x, RealDirection(a, twoSided=True))
> else:
> return limitHonest(ex, x, RealDirection(a))
> else: # assume a is complex for now
> return limitHonest(ex, x, ComplexDirection(a))
>
> I have no idea if effective algorithms exist for determining limiting
> behaviours in more general cases.
>
>
> This is my two cents. I know I am just getting started working with
> sympy, so there are probably many things wrong with this proposal. I'm
> just trying to clarify things and get discussion started.
>

Thanks for sharing your ideas. This discussion is very interesting.

> Thanks,
> Tom
>

[Tom Bachmann]

> > In general topological spaces limit directions can be described by
> > filters (as explained in the previous discussion; I think in practice
> > filters will hardly be useful for a CAS and limit directions will be
> > described otherwise).
> > Other common filters are: a point of C (complex plane), approached
> > from all sides. This is the definition of limit of normed spaces and
> > hence generalises. Also ComplexInfinity is a well-defined limit
> > direction.
>
> For me, no matter what we call them, limit directions *are* filters.
> A priori, I agree that going back to the theoretical definition will
> often not be terribly useful in practice. However, the definition is
> very important for the design because it ensures that we can operate on
> these objects in a perfectly consistent manner.
>

I agree. I think the definition of the terms oo, zoo etc should
feature somewhere very prominently. I don't know about others, but I
feel very uncomfortable handling these objects without having a proper
definition around.

>
>
> Limit descriptions are filters as well (except that I don't see how to
> express the order of a pole with a filter, but I'd argue that it is
> singularity classification, not limit description). For any filter X,
> limit(f(x), x -> X) is the filter f(X), i.e. the filter generated by the
> set {f(A)| A ∈ X}.
>

Oh, thanks for pointing that out. (We didn't study filters very
thoroughly in my course, just showed how they can be used to define
limiting processes in arbitrary topological spaces.)That's very neat
indeed.

>
> Arithmetic between numbers and filters can be defined via f(X) =
> limit(f(x), x ->X) where f is an ordinary real or complex function, i.e.
> 1 + oo = limit(1 + x, x -> oo) = oo.
> Arithmetic between filters can be defined via f(X, Y) = limit(f(x,y),
> (x, y) -> X×Y). This gives the same results as above except where NaN is
> involved.
> oo - oo is well defined. Going back to the definition of filters, it's
> easy to see that its value is the filter generated by R, which should be
> called something like "AnyReal". Similarly, zoo + oo is AnyComplex.
> Turning now to 0 * +oo, we see that it's important to make a difference
> between 0 as a real number and 0 as limit direction. If 0 is a real
> number, then according to the first definition above 0 * oo = 0. If we
> consider the neighbourhood of 0, calling the corresponding filter '0~'
> to avoid ambiguity, then the second definition applies
> and we have 0~ * oo = AnyReal, 0~ * zoo = AnyComplex, etc.
>
>

So we have the following commonly used filters (I find it easier to
think in terms of filter bases):

for x in R:

RB(x) = {filter generated by [x, x+1/n) for n in N}
LB(x) = {filter generated by (x-1/n, x] for n in N}
B(x) = LB(x) + RB(x) = {filter generated by (x-1/n, x+1/n)}

For z in C:
CB(z) = {filter generated by {y in C: |z-y| < 1/n}, n in N}
P(z) = {filter generated by {z}} = {all subsets of C containing z}.

oo = {filter generated by (x, oo) for x > 0}
-oo = -1 * oo = {filter generated by (-oo, x) for x < 0}

zoo = {filter generated by {y in C: |y| > n}, n in N}

AnyReal = oo - oo = {filter generated by R}
AnyComplex = B(0)*zoo = CB(0)*oo = {filter generated by C} = {C}

Filters generated by intervals [a, b], and many other similar filters.

Many more relations can be worked out, of course.


We then have defined (in principle) the following operations, for
f(z), g(z, y) any functions of complex variables, F, G any filters
* limit(f, F)
* f(F)
* g(F, G)

These things are hard to compute in general, but manageable in many
interesting cases.

Of course 0*oo = P(0) is slightly conuter-intuitive...

[Tom Bachmann]

> * limit(f, F)
> * f(F)

Of course these two are actually the same.

> * g(F, G)

= limit(g, FxG)

[Tom Bachmann]

On 30 Mrz., 21:56, Tom Bachmann <ness...@googlemail.com> wrote:
> > * limit(f, F)
> > * f(F)
>
> Of course these two are actually the same.

Thinking again, it is not quite that simple. In general f(F) is *very*
complicated. Usually limit(f, F) should return z such that CB(z)
\subsetof f(F); this is the normal definition of convergent filter. My
feeling is that there should be a natural equivalence relation on
filters, under which all filters convergent to the same point fall in
the same class, principal (ultra-)filters all fall in different
classes, and no non-convergent filter falls into a class with a
convergent filter. Does anyone know or can think of such a relation?

[Alexey U. Gudchenko]

28.03.2011 23:51, Tom Bachmann пишет:

Tom, can I ask you to put your letter content on wiki? I am going create
section where to put similar materials (Under Consideration or something
else).

Regarding the content itself, I have some little remark that `Limit
descriptions` is some confuse name-token, because it is not obviously
what it is: either it is description of procedure, or description of
result of it.

--
Alexey U.

[Tom Bachmann]

>
> Tom, can I ask you to put your letter content on wiki? I am going create
> section where to put similar materials (Under Consideration or something
> else).

I have created the following page:

https://github.com/sympy/sympy/wiki/Infinities-and-Singularities

[Alexey U. Gudchenko]

10.04.2011 00:37, Tom Bachmann пишет:

Thanks, I will answer in a day.

--
Alexey U.

[Alexey U. Gudchenko]

10.04.2011 00:37, Tom Bachmann пишет:
>
>>

Sorry for the late answer.

Problematic
------------

First off all, I would to clarify the aims, what problematic issues it
touch on, which are unresolved or under decision now.

So I add some ones and If I'll write something wrong, correct me please.

Issue 2200, what should be :

>>> limit(sin(x),x,oo)

Issue 2097, what should be:

>>> sin(oo)

issue 2096, What should be:

>>> 1/0

Issue 1116, integrate outputs wrong result when the function is singular.

Issue 360, Arithmetic with complex infinity

Issue 1321, trigonometric functions of floating-point numbers should
return floating-point numbers.

Issue 2242, A general way to describe and test for singularities is needed.

Issue 1000, What should be:

>>> limit(abs(x)/x, x, 0)

Definition of limit (One-sided limits).
(See Hector's last mail message)

This issues touch upon various topics, and we will rely on those common
definitions:
* limit
[1] http://en.wikipedia.org/wiki/Limit_of_a_function
[8]

* singularities
[2] http://en.wikipedia.org/wiki/Mathematical_singularity

* Real field extension
(R U +oo U -oo)
[3] http://en.wikipedia.org/wiki/Extended_real_number_line
(R U oo)
[4] http://en.wikipedia.org/wiki/Real_projective_line

Previous discussions collection:

limit(abs(x)/x, x, 0)
[5]
http://groups.google.com/group/sympy/browse_thread/thread/c834029d7696de5c

On a general representation for singularities and infinities (limits in
topological spaces, described by filters)
[6] https://github.com/sympy/sympy/wiki/Infinities-and-Singularities
[7]
http://groups.google.com/group/sympy/browse_thread/thread/73f7e90aef508882

Limits
------

Regarding the issue 1000 (`limit(abs(x)/x, x, 0)`)

Hector almost resolved it right now for reals. I agree, that
mathematically limit don't exists at zero point, but only one-sides
limits exist.

(a) One question (to all), is the exception needed or is returning of
nan (or None) sufficient in this case?

On the one hand, if we can assume that `nan` related with value of
source expression, so limit can't return result as the value in a field
of function result.

On the other hand, we can use exception, but to avoid exceptions in
outer user's code, user can use (and we can introduce) some tester
methods (has_limit, is_continues, get_singularity_description).

e.g limit(sin(x), x, oo) is not exists (in both sides, btw).

(Oops, I can't say exactly is it continuous *at* `oo` point or not, I
think rather not, it is related with the way of real number line extension)

Regarding the issue 2200, what should be `limit(sin(x),x,oo)`.

In Tom's [6, 7] the general way is described how to deal with limits in
topological spaces (general definition of limit, and one-sided limits
are also in it)
Additionally the difference between general limit results (value of
function, singularity description, infinity) on one hand and
description of limit procedure on the other have introduced, which is
mixed now in SymPy in case of `oo`.

Further I am going answer to Toms's page (because I promised to answer).
But before I want to say, that from limit procedure I expect (in general
meaning) to get the behaviour of function in limit (is it value, or
singularity description, or something else), so I'll always keep in mind
this aim (with above issue resolution).

Preliminary remarks about [6]:
(b) In preamble section I should like to add the above issues if they
are related (with links for convenient).

(c)

> There are three kinds of objects involved: expressions, "limit

directions" and "limit result descriptions".

To avoid confusion, as I understand, by the term "limit directions"
entailed "limit directives" how to obtain limit (not directions on the
plane or axes).

Now classify the kinds of results of limit procedure precisely.

As it have written above the strict definition entailed the existence of
limit or not:
(d) If limit exists then value is returned (which belongs to the field
of function).
The discussion question in this case is only how consider `oo` (this
question rises in issue 2096)

(e) If limit is not exists, then discussion question is what should
resulted in (exception or nan, or limit result description)

(f) "limit result descriptions"

Note that if (e) will be resulted to return nan or exception then
separated procedure will be required for obtaining "limit result
descriptions". Nevertheless for the moment I see just only one aim of
it: describe behaviour of function in limit. E.g.

>>> limit(sin(x), x, oo)
Singularity(type="essential", interval=[-1, 1])

or another variant( it depends on (b) resolving):
>>> limit(sin(x), x, oo)
nan
>>> singularity(sin(x), x, oo)
Singularity(type="essential", interval=[-1, 1])

also it can be resolved somehow (I am not sure)

>>> sin(oo)
Singularity(type="essential", interval=[-1, 1])
>>> sin(oo)**2
Singularity(type="essential", interval=[0, 1])

May be the others "limit result descriptions" exists too.

(g) But, as I understand , the last variant does not underlie the thesis
that "filters are not limit result descriptions". (right, Tom?)

Now talk about algorithms.

(i) The direct method described in Tom's page, as I understand, is
consist of with operations with filter.
(This question is very hard for me, so I omit it).

(k) Additionally (or with combination), we can go on the other hand to
achieve some targets .
We can describe a class of function for which well known that in any
filter they have limit (or pole) (E.g. continuous, complex analytical).
This calculation may be recourse and rely on some properties of
elementary functions and their combinations.

In this case, the task can be in separated to question of implementing
useful methods (`is_continuous` `is_differentiable`, `is_analytical`)
for other topics (series)

(Unfortunately I don't estimate how it related with gruntz algorithm.)

In conclusion I write, that (a-k) are questions for discussions, in
wchich I am not sure. (b,c) rather for Tom about [6] wiki-page.
And I am going to extend wiki pages (with the help of Tom) after discussion.

Sorry for tangled message.

--
Alexey U.

[Tom Bachmann]

I will just continue the discussion here, so we can write things up in
the wiki when (if) consensus emerges.

> First off all, I would to clarify the aims, what problematic issues it
> touch on, which are unresolved or under decision now.
>

Yes, that is certainly a good idea.

> So I add some ones and If I'll write something wrong, correct me please.
>
> Issue 2200, what should be :
>
>     >>> limit(sin(x),x,oo)
>

Very good point. This is an example where the limit does not exist as
an element of R or +-oo, but it would still be nice to give some
information. This relates to my last topic on the wiki, *what should
limit return, in general*. (It should probably return filters modded
out by a suitable equivalence relation, but I couldn't think of one
yet. A brutal way would be just to say F1~F2 if F1, F2 both converge
and converge to the same number. Then we return a number if the limit
exists as a number, and else a complete filter. I think this may not
be great because limits carry extremely much information, often more
than the user cares about or we can hope to compute. On the other hand
in this case we get the filter generated by [-1, 1] which is quite
nice.)

> Issue 2097, what should be:
>
>     >>> sin(oo)
>

The same as limit(sin(x), x, oo).

> issue 2096, What should be:
>
>     >>> 1/0
>

NaN. (IMHO)

> Issue 1116, integrate outputs wrong result when the function is singular.
>

I don't know about this one.

> Issue 360, Arithmetic with complex infinity
>

Well we already know how we want zoo to behave, except perhaps in some
weird cases.
The question here really is: what *is* zoo? Is it the filter "zoo" as
a limit direction (then we shouldn't be doing arithmetic, IMHO!), or
is it "zoo" as a limit result description.
In this question it would be the latter (I think), and so we need to
figure out what limit result descriptions should be and how to do
arithmetic with them. With my above proposal (but recall it's flaws!),
we do get the right answers.

> Issue 1321, trigonometric functions of floating-point numbers should
> return floating-point numbers.
>

Yes. There needs to be a way for code to tell: "is e an honest-to-god
expression, or are there infinities around". This is quite vague but I
am certain this is the *kind* of thing many of us have stumbled about.

> Issue 2242, A general way to describe and test for singularities is needed.
>
> Issue 1000, What should be:
>
>     >>> limit(abs(x)/x, x, 0)
>

>

> Limits
> ------
>
> Regarding the issue 1000 (`limit(abs(x)/x, x, 0)`)
>
> Hector almost resolved it right now for reals. I agree, that
> mathematically limit don't exists at zero point, but only one-sides
> limits exist.
>
> (a) One question (to all), is the exception needed or is returning of
> nan (or None) sufficient in this case?
>

I think eventually it should return a "limit result description" in
the case the limit does not exist as a number, which tells about the
two one-sided limits. Of course the issue should also be solved short-
term, and I will leave it for people who properly know sympy to
answer.

>
> e.g limit(sin(x), x, oo) is not exists (in both sides, btw).
>

Hm. First of all limits to oo are always "one-sided", because there is
only one direction from which we can approach oo (in the end-
compactification). And certainly the limit does not exist as a number.
SymPy currently returns sin(oo), which is not too bad (at least it is
descriptive). Note that this result comes from the heuristics, gruntz
cannot compute this limit.

>
> Preliminary remarks about [6]:
> (b) In preamble section I should like to add the above issues if they
> are related (with links for convenient).
>

Definitely do edit in any way you see fit!

> (c)> There are three kinds of objects involved: expressions, "limit
>
> directions" and "limit result descriptions".
>
> To avoid confusion, as I understand, by the term "limit directions"
> entailed "limit directives" how to obtain limit (not directions on the
> plane or axes).
>

Well, whatever "descriptive" word we use, this are filters, in the
end.

Hm.
I was saying (coming from a strongly typed background) that limit
should always take as arguments an expression and a filter (limit
directive), and return a limit result description. Even with the above
equivalence relation to form limit result descriptions, the
distinction is important, because the filters 0- and 0+ both project
to the limit result description "0, the number". Maybe you are right
and differentiating the functions "compute classical limit" and
"compute limit result description" is helpful. Then the latter can
return e.g. 0+ for x->0+.

> Now talk about algorithms.
>
> (i) The direct method described in Tom's page, as I understand, is
> consist of with operations with filter.
> (This question is very hard for me, so I omit it).
>

I have no idea how to implement any of this. Even determining if the
limit exists in the strictest sense is a fairly non-trivial business
(I'm spending a lot of time *fixing* the implementation of gruntz,
currently!).

> (k) Additionally (or with combination), we can go on the other hand to
> achieve some targets .
> We can describe a class of function for which well known that in any
> filter they have limit (or pole) (E.g. continuous, complex analytical).
> This calculation may be recourse and rely on some properties of
> elementary functions and their combinations.
>

This is I think a better idea. Use the general mathematical
description in terms of filters to make sure we are talking
coherently, but implement the process only in very special cases.

> In this case, the task can be in separated to question of implementing
> useful methods (`is_continuous`  `is_differentiable`, `is_analytical`)
> for other topics (series)
>
> (Unfortunately I don't estimate how it related with gruntz algorithm.)
>

I think this mostly independent of gruntz. Basically if gruntz says
"PoleError", we run a completely different algorithm to determine the
type of singularity. I haven't thought it through, though.

> In conclusion I write, that (a-k) are questions for discussions, in
> wchich I am not sure. (b,c) rather for Tom about [6] wiki-page.
> And I am going to extend wiki pages (with the help of Tom) after discussion.
>
> Sorry for tangled message.
>

My answer is not much better, either :-)