On Fri, Jul 27, 2012 at 1:28 AM, Alex <[email protected]> wrote: > Yes, A | ~A are left alone. A | A simplifies to A, which is fine. I think > that's about it. > There is a bunch of other functions aside from xor which directly > translates to and, or, not operations:
Yes, autosimplification of A | A lets us do optimizations at constructor time (namely, dumping the args in a set) that are probably not worth giving up just so that expressions like that would be expressible. > > Nand - I'm good with translating it at construction time > Nor -- can stay as is too I agree. These can stay as they are, unless there are requests to make them unevaluated. > > Xor -- should probably not be rewritten automatically > Implies -- should not be rewritten automatically > Equivalent -- should not be rewritten automatically > ITE (if-then-else) -- should not be rewritten automatically Definitely. Especially for Xor, which even has its own symbol recognized by Python. I thought of one other case. x << y should continue to be the same thing as y >> x (we recently removed this sort of thing from <, >, <=, and >=, but I think this case is different: rarely do you want to write x <- y in that order. > > In general, I think it will be quite hard to make simplify() "compile" > to the last 4 high-level expressions, except for the implication. > The general approach would anyway be to translate everything to > And, Or, Not format and work with this limited set of operations: > it's much easier to work on that. > > Once a smaller form is found, some heuristic could try to find > Xor, Implies, etc patterns and "compile up" to these functions, although > I don't think that a final expression full of => signs and xors is necessary > simpler than its $|~ equivalent. Sure, we'll have to see what works. Personally, any logical expression that's more than a few symbols long is hard to read, regardless what form it's in. Perhaps some cases will not be simpler, but certainly some will be (as a simple example, take the case where the entire expression can be reduced to a single Xor or Implies). So probably there is some middle ground, and heuristics that can be used to find it. Perhaps it has something to do with nesting of the operations. And by the way, I think it would be cool to have an algorithm that can convert a cnf form of a bunch of nested implies back to the implies, even if the latter is relatively messy. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
