> 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.
> It would also mean than a program might generate exponentially
> many sub-expressions
In principle, yes. In practice, I see that occurring extremely rarely when I
work with Maple. I don't know if it's because that's the way things are, or
because Maple is smart about it (e.g., attempting to evaluate nested
piecewise() calls to ensure that they don't proliferate) but it doesn't
usually happen. Anyhow, we can always have a function (or another flag! Yes,
I know...) that causes piecewise() to just call asksign recursively (i.e.,
call asksign for the innermost piecewise first in case they are nested.)
> With a much more robust "assume" facility this might be cut down
No argument there, I've cursed assume almost as often as I've cursed
asksign. Since I mentioned Maple, I should also mention that I find the
construct "eval(<expr>) assuming <cond>" quite useful.
> 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?
Viktor