Integrals and sums with infinite limits

[Waldek Hebisch]

Currently our unevaluated definite integrals and sums must have
finite limits. I am looking at a way to fix this. The trouble
is that infinity is not an expression and aguments to kernels
must be an expression. One, type-clean possibility is to
have 6 new operators, 3 for integrals and 3 for sums, for
each normal combinations of limits, that is lower limit at
-infinity and upper finite, upper limit at +infinity and
lower finite and lower limit at -infinity and upper and +infinity.
That would not handle less usual cases like lower limit
at +infinity. And clearly contour integrals need different
solution.

Another possibility is to attach extra data to operators,
Martin Rubey used this. To make this correct may need
extra code to translate operators when say Expression(Integer)
is converted to Expression(Complex(Integer)). Currently
conversion is handled by mostly boilerplate code in
'operator'.

Another possiblity is to have otherwise invalid expressions
as markers for infinities. I mention this, but rather
dislike such possibility. Namely, there would be danger
of such markers leaking to other places, we would have
to spead out tests in various places. Effectively we
would loose benefits of type discipline.

--
Waldek Hebisch

[Ralf Hemmecke]

On 16.07.23 11:02, Waldek Hebisch wrote:
> Currently our unevaluated definite integrals and sums must have
> finite limits. I am looking at a way to fix this. The trouble
> is that infinity is not an expression and aguments to kernels
> must be an expression.

Hmm... my first thought was: make infinity an expression.

(191) -> sum(sin(x),x=%minusInfty..%plusInfty)

%plusInfty
--+
(191) > sin(x)
--+
x = %minusInfty
Type: Expression(Integer)

Well, that's "infty" not "infinity", but I'd find this the easiest solution.

We should then definitely use %plusInfinity and tell the interpreter not
to introduce OrderedCompletion. I guess having %plusInfty and
%plusInfinity is just too confusing for users.

> One, type-clean possibility is to
> have 6 new operators, 3 for integrals and 3 for sums, for
> each normal combinations of limits, that is lower limit at
> -infinity and upper finite, upper limit at +infinity and
> lower finite and lower limit at -infinity and upper and +infinity.
> That would not handle less usual cases like lower limit
> at +infinity. And clearly contour integrals need different
> solution.

Honestly, my first feeling is against 6 (or 9 since there is also
product) operators. If at all... wouldn't it be enough to introduce just
3 for "uneveluated X" and handle the limiting cases by an argument?
You can then even allow "OrderedCompletion(R)" as an argument for the
bounds.

> Another possibility is to attach extra data to operators,
> Martin Rubey used this.

The code is probably in mantapse.spad, but I cannot easily find the
exact place.

> Another possiblity is to have otherwise invalid expressions
> as markers for infinities. I mention this, but rather
> dislike such possibility. Namely, there would be danger
> of such markers leaking to other places, we would have
> to spead out tests in various places. Effectively we
> would loose benefits of type discipline.

Hmmm, that sounds like my first suggestion with %plusInfty". But what
exactly do you mean with type discipline?

If there were some documentation that explains why the original
developers have decided not to include any kind of infinity in
expression, it would be easier now.

But I do not think that introducing +/- infinity as an additional
nullary BasicOperator that is added to CommonOperators and then made
available in Expression Integer would cause too many troubles.
(My first guess and admittedly not thought until the end.)

Ralf

[Waldek Hebisch]

On Sun, Jul 16, 2023 at 01:40:25PM +0200, Ralf Hemmecke wrote:
> On 16.07.23 11:02, Waldek Hebisch wrote:
> > Currently our unevaluated definite integrals and sums must have
> > finite limits. I am looking at a way to fix this. The trouble
> > is that infinity is not an expression and aguments to kernels
> > must be an expression.
>
> Hmm... my first thought was: make infinity an expression.
>
> (191) -> sum(sin(x),x=%minusInfty..%plusInfty)
>
> %plusInfty
> --+
> (191) > sin(x)
> --+
> x = %minusInfty
> Type: Expression(Integer)
>
> Well, that's "infty" not "infinity", but I'd find this the easiest solution.
>
> We should then definitely use %plusInfinity and tell the interpreter not to
> introduce OrderedCompletion. I guess having %plusInfty and %plusInfinity is
> just too confusing for users.

That is a hack which may work for some purposes, but for proper handling
code must know special properties of infinity.

> > One, type-clean possibility is to
> > have 6 new operators, 3 for integrals and 3 for sums, for
> > each normal combinations of limits, that is lower limit at
> > -infinity and upper finite, upper limit at +infinity and
> > lower finite and lower limit at -infinity and upper and +infinity.
> > That would not handle less usual cases like lower limit
> > at +infinity. And clearly contour integrals need different
> > solution.
>
> Honestly, my first feeling is against 6 (or 9 since there is also product)

Yes, really 9.

> operators. If at all... wouldn't it be enough to introduce just 3 for
> "uneveluated X" and handle the limiting cases by an argument?
> You can then even allow "OrderedCompletion(R)" as an argument for the
> bounds.
>
> > Another possibility is to attach extra data to operators,
> > Martin Rubey used this.
>
> The code is probably in mantapse.spad, but I cannot easily find the exact
> place.

No, this code is in 'rec.spad'.

> > Another possiblity is to have otherwise invalid expressions
> > as markers for infinities. I mention this, but rather
> > dislike such possibility. Namely, there would be danger
> > of such markers leaking to other places, we would have
> > to spead out tests in various places. Effectively we
> > would loose benefits of type discipline.
>
> Hmmm, that sounds like my first suggestion with %plusInfty". But what
> exactly do you mean with type discipline?
>
> If there were some documentation that explains why the original developers
> have decided not to include any kind of infinity in expression, it would be
> easier now.
>
> But I do not think that introducing +/- infinity as an additional nullary
> BasicOperator that is added to CommonOperators and then made available in
> Expression Integer would cause too many troubles.
> (My first guess and admittedly not thought until the end.)

Trouble is that with infinity we no longer have a field. You may object
that we already have ways to introduce zero divisors via algebraic
dependence. But algebraic kernels are essential for algebraic
computations and there are ways to use them in safe ways. We
have bunch of other strange stuff, starting from 'abs' trough 'floor'
to 'diracDelta' ('abs' was present from the start, most other are
FriCAS additions). But they make sense in arthtmetic, and agin
there are ways to use them in safe ways.

AFAICS difference is that infinity makes almost no sense in
arithmetic. So original design keeps infinity separate.

Thinking more about this: infinity would be reasonably safe if
treated as transcendental kernel. But then we need to accept
things like

%plusInfinity + 42

or

(%plusInfinity^3 - 16*%plusInfinity + 1)/(%plusInfinity^2 - 17)

and do not try to simplify them in any way (more "natural" ways
of handling infinity would break field properties). And we
need at least two infinities, that is %plusInfinity and
%minusInfinity (ATM is is not clear to me if we need
complex infinity in Expression).

--
Waldek Hebisch