Am Samstag, den 06.06.2009, 09:49 -0600 schrieb Robert Dodier:
> On 6/6/09, Dieter Kaiser <drdieterkaiser at web.de> wrote:
>
> > I think it would be a good idea to remove the call of merror in cases
> > like a definite integral which is divergent, e.g.
>
> Agreed.
>
> > (%i27) integrate(x,x,0,inf);
> > defint: The integral is divergent.
> > (%o27) 'divergent
> >
> > But it is problematic to return a symbol, because we get a lot of wrong
> > results, when the integral is part of an expression (I think the
> > problems are known). This is the case for 'inf and 'minf too.
>
> I dunno. Returning 'divergent is suboptimal but it's better than
> triggering an error. How about 'divergent('integrate(...)) i.e. smash
> the offending expression in the return value (or make the expression
> a property of the return value). It might be a good idea to tag the
> 'divergent with a gensym somehow so that we avoid stuff like
> 'divergent - 'divergent => 0.
>
> Whatever we decide with integrate should probably be applied
> to limit as well, since limit now returns ind and und.
That is the most difficult point. What solution would be general and
correct. Furthermore, I think it is very useful to have a simple
concept.
> > Is it a good idea to use the empty list [] to represent the case that we
> > have NO RESULT, but NO ERROR?
>
> Opposed. [] is a valid return value in other, commonly-encountered, contexts.
> Also, it doesn't carry any info about the original expression.
As written in another posting, I am not convinced that we get into
conflicts with the interpretation "No solution" in a context where we
want to solve an integral.
Furthermore, I do not think that it is a problem to have no more
information, because we will print a message. That is not less
information as we have now. For the user it is not much different to get
a symbol 'divergent, any other expression, or [].
By the way: I am thinking about a way to support the user with
additional information about the calculation. One way could be to write
messages in a global list, which can be inspected by the user. A
function can push a message on the list like "Last result from defint:
the integral <some integral> is divergent." or "Last result from
integrate: Maxima might be able to find a solution for the integral
<some integral>, when the sign of the parameter <some parameter> is
known to Maxima." With this method we can return a noun form with extra
informations on a message list to help the user to improve the
formulation of the problem. (Of course this extra informations, when
available, can be printed with every output like the time when
showtime:true).
> > Should we introduce in addition the convention, that functions may map
> > automatically over lists, e.g. sin([a,b,c]) --> [sin(a),sin(b),sin(c)]?
>
> Well, if the return value is something other than [] this
> doesn't matter so much. But for the record, I'm in favor
> of such a convention only if it is implemented via a
> declaration like declare(sin, distributes_over ("[")).
>
> I'm opposed to any implementation which requires hacking
> on the simplifier for each affected function.
> There's already too much of that in Maxima.
I think this point, the implementation of an automatic mapping, is not
so important for the actual problem to represent a "No solution" or "No
result". We will get something like sin([]), but that is not more worse
like sin('divergent) or sin('any other expression).
Perhaps, an automatic mapping which depends on the value of listarith
might be useful to get the mapping of functions more consistent to the
mapping of the arithmetic operators. It is easy to implement and could
be done step by step.
Dieter Kaiser