Robert,
I did not mean to use "pedantry" as a fighting word :-) I think the point I
was making is that there are situations when the computer can know that a
particular detail does NOT matter insofar as the result is concerned, and
thus it can be simplified away. In such cases, tracking the detail just
unnecessarily complicates the problem without adding any value. For
instance, not simplifying x/x to 1 just because x might be zero, and 0/0 is
undefined is not very helpful. It prevents a lot of useful simplifications
that rely, for instance, on bringing terms to a common denominator, because
you can't just willy-nilly multiply them with x/x when x might be zero, can
you?
So as you say, the computer can track these things, but that means it can
also track when simplifications CAN be safely made, and make them, thus
helping the user obtain the desired result without being sidetracked. In
this particular case, x/x=1 can be assumed without assuming x#0. A useful
rule, in my opinion, is this: a simplification is safe if it can never lead
to a) an incorrect result, or b) the loss of a result.
By the way, I note with pleasure that at present, when I type x/x, Maxima
responds with a 1 and does not want know first if x is zero or nonzero. Let
us keep it that way!
Viktor
-----Original Message-----
From: Robert Dodier [mailto:robert.dodier at gmail.com]
Sent: Saturday, November 29, 2008 6:49 PM
To: Viktor T. Toth
Cc: Richard Fateman; maxima at math.utexas.edu
Subject: Re: [Maxima] atan2(x,x)
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