Algebraic data types and pattern matching

[Aaron Meurer]

Some people on this list might be interested in this https://github.com/ContinuumIO/pyalge.

Aaron Meurer

[F. B.]

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.

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?

[Christophe Bal]

Hello,

thanks for the link https://github.com/ContinuumIO/pyalge. The problem I met is that the examples are not commented so it is not easy to see a use of this kind of features. I'm ver new to this kind of things.

What could be a use of this in Sympy ?

Sorry for this "noob" question. ;-)

Christophe 

--
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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
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/76c5493f-d6c4-49d6-b3c1-063b16245816%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Richard Fateman]

I don't know about the details, but the "mechansim that understands ..." is computationally infeasible
except for trivial cases.
 

[Aaron Meurer]

On Apr 5, 2014, at 9:14 AM, Richard Fateman <fat...@gmail.com> 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. 

Aaron Meurer

 

--
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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
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/85d52869-f7a3-4832-8d81-e250c9ba5bec%40googlegroups.com.

[Richard Fateman]

On Saturday, April 5, 2014 7:57:10 AM UTC-7, Aaron Meurer wrote:

On Apr 5, 2014, at 9:14 AM, Richard Fateman <fat...@gmail.com> 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?

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 prefer functional style because debugging using trace()  works so well.

RJF
 

[Aaron Meurer]

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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
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.