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
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/705d6866-eed2-04c4-2194-2102a6bc3403%40hemmecke.org.
