Am Montag, den 08.06.2009, 00:14 -0600 schrieb Robert Dodier:
> On 6/6/09, Dieter Kaiser <drdieterkaiser at web.de> wrote:
> > 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.
>
> Why invent this special convention at all? Why go to the
> trouble of it, when we can just as easily have a symbol
> or expression which explicitly indicates an error?
I have suggested in another posting to use something like:
(list '($noobject) (gensym))
Could this be a first step. What about a better name?
> > 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.
>
> I'm opposed to this. If there is some information which is known,
> just smash it into the return value somehow. If it is too verbose,
> attach it to the property list.
The first idea I had was to introduce a standard function like
user_message() to print a user message. This is done for an error
message in the function merror. The last error can be inspected by the
user.
The advantage would be to avoid the lot of different ways and
conventions user messages are printed within functions. The next
advantage would be that a user can switch off such messages. A next step
could be to give different types of messages like warning,
information, ... A minimal implementation could be a copy of the
behavior of merror.
> > 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.
>
> If "step by step" means hacking the simplifier in each of the places
> which we can find, then that's exactly what I want to avoid.
We have not to modify the simplifier, but the simplifying functions. By
the way, there is a lot of work possible to implement more functionality
for functions.
Dieter Kaiser