On Mon, Oct 08, 2012 at 08:59:14AM -0600, Aaron Meurer wrote:
> On Oct 7, 2012, at 10:43 AM, Sergiu Ivanov <[email protected]> wrote:
>
> > On Sun, Oct 7, 2012 at 12:58 AM, Matthew Rocklin <[email protected]> wrote:
>
> >>>> Ah, sorry, I was using pure in the sense of "lets just use this
> >>>> function,
> >>>> not a class that represents this function". I wasn't using "pure" in the
> >>>> side-effect-free sense. I do however think that this system should be
> >>>> (mostly) side-effect free (mostly for caching, profiling, debug,
> >>>> etc....)
> >>>> That's somewhat standard in SymPy though.
> >>>
> >>> Yes, and that's an advantage. Although functions with side-effects
> >>> should also be handled nicely, because, from what I know, there
> >>> actually are some mutable objects in SymPy.
> >>
> >> Rules as they're currently written only work on objects that inherit from
> >> Basic. All Basics are immutable. Rules assume immutability. The mutable
> >> types in SymPy (notably Matrix) do not inherit from Basic.
> >
> > Ah, I see; I thought Matrix inherited from Basic as well.
>
> Any mutable type will not inherit from Basic.
Oh yes, I knew that, but I thought Matrix made an exception. I'll
look more attentively at the code next time :-)
> > I'm not sure how well Wild works, but, apparently, we can use it to do
> > some pattern matching. I've never used Wild, though; I just assumed
> > that it's sufficiently powerful. If this is indeed the case, then the
> > format of rules you suggest should be straightforward to implement.
>
> Wild works well, but it's not expressive enough to match some things.
> For example, you could never create a pattern to match a polynomial
> an*x**n + ... a1*x + a0, because there's no way to express n
> coefficients. Also, for Wild to work, the expression had to be in
> exactly the form given, which is understandable, but it can lead to
> little gotchas if you forget to expand the input expression, or if
> some kind of auto simplification prevents you from being in the
> desired format.
Hm, I see.
> Another issue with Wild is that if you aren't careful (which usually
> means specifying the exclude keyword precisely) you can get
> nondeterministic results. For example,
>
> a, b = Wild("a"), Wild("b")
> (x*y).match(a*b)
>
> Could give four possible outputs ({a:x, b:y}, {a:y, b:x}, {a:1,
> b:x*y}, and {a:x*y, b:1}, and the last two are the ones that usually
> catch people off guard). I'm not sure if there's a pattern matching
> system that wouldn't have this issue, though.
Apparently, dropping the other two "unexpected" outputs is not a good
idea, because both of them actually make sense, and thus I agree that
all pattern matching systems will do similarly.
In this case, I think it's a good idea to allow a match() function for
a rule, which will return True whenever the input is git. In this
way, a rule will look like (match(), rule_function()). While such a
structure doesn't seem to be very far away from what Matthew has just
implemented (just a function per rule), I think it's still a little
bit more restricted, because the structure matching functionality is
decoupled from the actual application.
Sergiu
--
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.
