On Apr 6, 2014, at 3:56 PM, Richard Fateman <[email protected]> wrote:
On Saturday, April 5, 2014 7:57:10 AM UTC-7, Aaron Meurer wrote: > > > > On Apr 5, 2014, at 9:14 AM, Richard Fateman <[email protected]<javascript:>> > wrote: > > > > On Saturday, April 5, 2014 12:23:30 AM UTC-7, F. B. wrote: >> >> >> On Thursday, April 3, 2014 5:04:36 PM UTC+2, Aaron Meurer wrote: >>> >>> Some people on this list might be interested in this >>> https://github.com/ContinuumIO/pyalge. >>> >> >> >> Indeed, that can be very powerful to symbolic math. >> >> I don't really like their style of putting the string of the expression >> inside the dispatching decorator, but otherwise you can't easily freeze >> expressions to an unevaluated state in Python. That's a point in favor of >> Julia. >> > > I didn't like that either. I was trying to convince the author not to do > it that way. You can easily freeze expressions to unevaluated state by just > not evaluating them. > > >> In any case, in SymPy there are wildcards types, so a possible solution: >> >> x = symbols('x') >> w = Wild('w') >> >> @patterndispatch(sin(w*x), assumptions=Q.positive(w)) >> def foo(a): >> a**2 >> >> @patterndispatch(sin(w*x)) >> def foo(a): >> a**3 >> >> # there should be a mechanism that understands which one is more >> specific. >> foo(sin(3*x)) # ==> sin(3*x)**2 >> foo(sin(-2*x)) # ==> sin(3*x)**3 >> >> What do you think about this approach? >> > > I don't know about the details, but the "mechansim that understands ..." > is computationally infeasible > except for trivial cases. > > > I think a (well-defined) heuristic would be fine. Assumedly each function > definition would be mathematically correct, so the worst that would happen > would be not computing so etching as well as you could. > etching? That's what happens when you compose emails on an ipad. It should just be "something". Well, you could use heuristics as does Mathematica, but then you end up using some other ordering as does Mathematica, like last-rule-in gets tried first. If your rules are defined to be non-overlapping, then the order will not matter except for efficiency. If your rules are defined so that special cases are defined after general cases (and therefore are tried first) that might work also. Allowing users to specify the order of rules is another possibility. However, it turns out that for most people, the complexity of interaction of rules that overlap is a substantial opportunity to create bugs that are difficult to cure. I do not know if there have been studies comparing bug frequency or debugging difficult using rules vs. using conventional sequential programming constructs vs. functional-style programming. I don't know about bug frequency, but I imagine that proponents from each camp prefer their favorite paradigm for debugging. I prefer sequential, but that's because I've gotten good at debugging it. But that doesn't mean I couldn't learn to debug other paradigms. And IMHO good debugging depends more on the tools and the insight of the (human) debugger than the programming language or paradigm. Aaron Meurer I prefer functional style because debugging using trace() works so well. RJF > > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/83d5f006-eb76-4001-a6cb-6f57c717c64a%40googlegroups.com<https://groups.google.com/d/msgid/sympy/83d5f006-eb76-4001-a6cb-6f57c717c64a%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3747363748709455536%40unknownmsgid. For more options, visit https://groups.google.com/d/optout.
