On 11/18/08, Viktor T. Toth <vttoth at vttoth.com> wrote:
> > Probably every variation you have thought of has been considered
> That's why I asked. Given Maxima's 30-year history, I hesitate every time it
> occurs to me to "improve" on something, because there's a good chance that
> whatever I have in mind has already been tried, and there's probably a good
> reason why it wasn't done that way in the end.
Please don't be discouraged.
> No argument there, I've cursed assume almost as often as I've cursed
> asksign.
Yes, assume is pretty weak & needs to be strengthened.
> Since I mentioned Maple, I should also mention that I find the
> construct "eval(<expr>) assuming <cond>" quite useful.
Agreed.
> > e.g. instead of simplifying x/x to 1, we might need
> > "if x=0 then undefined else 1" or "1 unless x=0"
>
> I always thought of this as unnecessary pedantry with little or no practical
> value. Now x/abs(x) is another matter, since the left and right limits don't
> agree (Maple, quite incorrectly in my opinion, evaluates x/abs(x) it to +1
> at x=0, which can lead to contradictory results depending on the order of
> evaluation), but what purpose would it serve to leave x/x undefined at 0?
Disagreed about pedantry here. A computer should be able to
keep track of details that would be burdensome to a human.
Sometimes the details matter, sometimes they don't --- when
you're solving a new problem, there's really no way to tell which
one in advance.
Maybe this business with implicit assumptions is, in part, a
display problem. Maybe a result could be tied to a collection
of assumptions, which is present in the display but usually
closed, and optionally opened to display stuff like "assuming x # 0".
FWIW
Robert Dodier