I'd certainly like to see simplifying forms of 'if' and the boolean
operators.
But it might be nice to fix the current translator first -- it is buggy on
the simplest cases of noun 'if'.
test1(c):= if c then 0 else 1$
test1(x) => if x then 0 else 1 <<< OK
translate(test1)
test1(x) => 0 <<< oops!
I suppose we need to add a 'boolean' declaration to be able to tell
'translate' that it doesn't need to handle the noun case.
test2(c):= if c<0 then 0 else 1$
test2(x) => if x<0 then 0 else 1
test2(-x^2) => if -x^2<0 then 0 else 1
translate(test2)$
test2(x) => 0 <<< oops
test2(-x^2) => 0 <<< oops
Here, if x is declared numeric, test2 can have unchanged code.
-s
On Sat, Sep 1, 2012 at 3:33 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 2012-09-01, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>
> > Is there any good reason that (if true then A else B) doesn't
> > *simplify *to A?
>
> I made a half-hearted effort in that direction some time ago; the code
> that I came up with is now in share/contrib/boolsimp. Some of the stuff
> you mentioned are handled by that code, but it's not very extensive so I
> suspect it's easy to come up with examples that it won't handle.
> The boolsimp code handles some Boolean expressions as well as "if"
> expressions.
>
> It might or might not be worth the trouble to update and expand
> boolsimp. Probably an effective approach would be to scope out the
> simplification policies we want to put in place, then see what (if
> anything) can be salvaged from boolsimp.
>
> A related idea which has been floated before is to make the Boolean
> operators simplifying instead of evaluating. I wonder if anyone would
> like to talk about that.
>
> best,
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>