Am 05.07.2014 09:42, schrieb F. B.:
On Friday, July 4, 2014 9:14:29 PM UTC, Joachim Durchholz wrote:
Am 03.07.2014 21:39, schrieb F. B.:
I updated the draft:
https://github.com/sympy/sympy/wiki/Proposal-for-a-new-pattern-matching
The page uses the term "unification" without defining it.
Given that there are multiple variants of unification, some of them even
Turing-complete, the term should be either defined or replaced with a
different one.
(E.g. my experience with unification is from Prolog, which does deep
structural matching and wildcards, among other things. Which is clearly
not what's meant in the draft.)
I meant unification as the one in the library by Matthew, i.e. expressions
that have both wildcards and a substitution is found such that the two
expressions become the same.
That's the definition of unification in general.
The variants are different
I don't think that unification is good in case of subtree matching, because
it would become very ambiguous.
What alternative do you have in mind?
> Mathematica's pattern matching just tries
to identify a subexpression and acts on it. The mathematical expressions
users work with do not usually contain wildcards, I think that wildcards
should be treated only when they are in the pattern.
Can you elaborate a bit?
I'd expect a wildcard mechanism to be inconsequential as long as the
pattern does not containd a wildcard, which would make that point moot,
so obviously I'm missing an important part of the picture here.
(Disclaimer: I haven't looked at the code.)
rewrite should always update the counter. It's a cheap operation, and
having rewrite *and* rewrite_with_counter is just going to complicate
the API with little benefit.
First get it right, then get it fast. And don't worry too much about
speed in the detail if you can still optimize the algorithms.
Yes, that was just a draft. It can be rethought.
That's what I'm giving my feedback for :-)
The general principle why I disliked that particular section of the API
draft is this:
Multiple functions that do almost the same force the API user to divert
time and attention away from what they're actually interested in, and to
selecting the proper call. Usually they don't do this, and create lots
of subtly wrong (or just subtly suboptimal) code.
This is a general problem in many, many libraries. Library designers
have a general tendency to write a separate API for each use case and
generate a very "broad" API with tons of functions which are then hard
to learn and use because you need to know so much to select the proper
function for each use case. A "narrow" API with just enough functions to
get the job done is much easier to use.
I agree it would be nice to be able to explore the different ways to
apply matches.
All of SymPy's matchers so far were concerned in matching the whole
expression. A user may have a huge expression, and be willing to apply a
rewriterule to only some parts of it, that's why we need subtree matching.
Aaaahh... I totally misunderstood that area.
The draft is talking about selecting a subset of applicable matching
positions.
I was talking about selecting which subset of rules to apply to a given
matching position.
The situation can be quite complicated actually. Two mutually exclusive
rules might apply to the same subtree. Or they might apply to
overlapping parts of the same subtree (e.g. one rule might substitute
the A+B in A+B+C, the other might substitute B+C).
We have all source code of Mathics available on github, which is a clone of
Wolfram Mathematica. I would keep compatibility with the sorting
established by Mathematica. Consider the possible advantage of easily
importing open source Mathematica libraries into SymPy or into Python.
Hmm... is there a consensus that replicating Mathematica's detail design
is what SymPy needs?
On the plus side, copying a proven design is always a good idea if we
don't have a better one.
Plus, compatibility can be a huge bonus.
On the minus side, we'd be copying Mathematica's design limitations as well.
Also, trying to be compatible with an existing design means a huge
implementation burden, because to be useful, compatibility must be
flaw-by-flaw compatibility.
I can't say I know the flaws and limitations in Mathematica's rule
engine design. So if I were left to my own devices, I'd simply copy the
rule engine design of Mathematica because I don't know better.
If I had the time, I'd look at the state of the art of subtree pattern
matching. What pattern languages exist, what algorithms exist, what are
their pros and cons regarding efficiency, expressivity, accessibility
for our audience; and THEN decide wether Mathematica's rule engine is
either "good enough", or "too outdated, we can use today's state of the
art and gain order-of-magnitude improvements so compatibility would be
nice but isn't worth it".
Exhaustive replacement needs a limit. Anything that can do the natural
number axioms is Turing-complete, and I bet the substitution rules are
at least as powerful as the natural number axioms.
By exhaustive replacement I meant something similar to this:
http://reference.wolfram.com/mathematica/ref/ReplaceRepeated.html
That's what I understood.
And I meant the MaxIterations option ;-P
For the API: Have you considered a chaining style? (a.k.a. "fluent
style" or "DSL" - the terms aren't equivalent but often go together.)
With the API as proposed, things are going to be pretty deeply nested,
and that tends to be rather hard to read.
I am not very happy with this API, so any other proposals are welcome.
An other idea I had, is to use ordinary expressions with no wild objects,
and recognize symbols as wilds if they have a trailing underscore "_" sign.
This is the way Mathematica works.
On the pro side, some simple lexical convention to distinguish wildcards
and literals would make the pattern language syntax trivial to learn.
On the contra side, patterns and expressions might have become too
similar. A pattern might look like an expression (both at the user level
and at the coder level), and that could create all kinds of subtle mistakes.
So I'd recommend making them analogous but mutually incompatible, so
that no pattern could be mistaken for an expression and vice versa.
I.e. for SymPy users, the pattern syntax might require a prefix or
whatever to clearly mark a string of input characters as "this is a
pattern".
For contributors, it's a bit more involved: Expr and Pattern API would
sometimes have identical APIs, e.g. for constructing them, and these
should be the same. Sometimes they would have different APIs, e.g.
actual matching for patterns, evaluation for expressions; not much
potential for confusion there. Things would get ugly for those parts of
the API that are similar but different; the function names should be
deliberately different for these APIs so that coders who call the API
cannot be in doubt about what kind of object they're dealing with.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@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/53B8EE71.8080404%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
