Waldek Hebisch wrote Sun, 16 Jul 2023 02:02:23 -0700:

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.

This was posted in <fricas-devel> on Google Groups.

Integration ranges such as from (-INF + #i) to (+INF + #i), or from
(-1 - #i*INF) to (+1 - #i*INF), &cetera, may occur too, although mostly
in parts of contour integrals. A general solution for indefinite
integrals would then be a single parametrized type of integral where
both limits are a special type of expression. Addition and subtraction
of finite expresions must be possible for this type to reflect
transformations of the integration variable, as should be the
multiplication and division by finite expressions, and the special type
should be acceptable to limit evaluations in cases where an explicit antiderivative can be given.

I suppose this would require what you call attaching extra data to
operators.

What would be the problem with allowing INF in general expressions to
cover these special operations? After all, LOG(0), TAN(pi/2)^2,
&cetera, are presumably allowed to appear already.

Martin.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)