Am Samstag, den 06.06.2009, 07:57 -0700 schrieb Richard Fateman:
> This is a very good question. There are several related issues. In
> logic I think there is a similar concept associated with the symbol
> "bottom" which looks like an upside-down T.
> There is also the empty SET which might be different from the LIST with
> no elements. There is the case of a limit not existing, where
> "undefined" is returned. There is the possibility of an interval with
> no elements in it, like the interval [1,-1]. (Although some people,
> myself included, might use this for [-inf,-1]+[1,inf].) or interval
> [inf,-inf].
> There is the case of solution sets from solve where there are no
> solutions, e.g. sin(realpart(x))= 2.
Yes, I have thought about other cases too.
> I think that the solution of making functions map over lists so that
> sin([]) becomes [] is interesting, but conflicts with the use of []
> as a list!
> For example, append([a,b],[]) is [a,b], not []. If you had another
> symbol for "undefined" you might say that
> append([a,b],undefined) = undefined.
I am not really convinced that we get a conflict. Perhaps it is matter
of the context we are in and the interpretation of the results.
When a list can represent some solutions or values like [a,b,c] and []
represents no solution, then append([],[a,b,c]) --> [a,b,c] is the case
that we have not appended a new solution to the list of solutions.
Furthermore, when the list [a,b,c] represents three solutions Maxima
does the following arithmetic with these solutions (with
listarith:true):
2*[a,b,c] --> [2*a,2*b,2*c]
We can cons an empty list to this list of solutions and get a list with
elements which represent three solutions and a "No solution":
2*cons([],[a,b,c]) --> [[],2*a,2*b,2*c]
This works for other operators too, but not for functions. Furthermore,
Maxima does the following:
[]+[] --> []
[]*[] --> []
[]/[] --> []
This behavior is helpful to interpret [a,b,c] as a list of solutions and
the empty list [] as "No Solution" or "No Result" within this context.
> If we revise the system so that it routinely returns SETS for answers
> when there is more than one, or even when there is one, then the empty
> set may make sense.
> e.g.
> solve(x^2-4=0,x) --> {-2,2}
>
> divergent integral --> message , returns {}
>
> At this point the same question comes up when you consider the result of
> using a set operation like union: union({a},{}) is {a}.
I have thought about the representation as a set too. One problem is,
that in the context of the evaluation of a mathematical expression we
can do a lot of strange things with sets, e.g.
{}+{} --> 2*{}
{}*{} --> {}^2
{}/{} --> 1
This behavior is not helpful to interpret the empty set as "No
Solution". (We get the same for lists when listarith:FALSE).
The advantage of the empty list is, that all necessary functionality we
need to represent a "No solution" is available.
> Some of this comes from Maxima allowing any type object to appear in
> almost any context, and trying to do something with it.
> A strongly typed system would not allow you to compute the union of a
> set and something that is not a set at all.
Because Maxima can do this, I would have no problem with an empty list
to represent "No solution" as long as the results of mathematical
calculations are correct and not in conflict within the context. E.g, it
might be useful to cons a solution of an integral to a list of symbols
which represent a string:
cons(integrate(x,x,0,inf),[": represents no solution"])
> It seems to me that a no-such-object like "bottom" is logically most
> consistent, where indeed f(...,bottom,...) is bottom for all f.
I have tried this idea too. The main problem of a new object, I think
is, that we have to modify the simplifer and meval to look into every
expression for such a new object.
Dieter Kaiser