On Sunday, July 6, 2014 8:36:38 AM UTC+2, Joachim Durchholz wrote:
>
> >> 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).
>
Running on Mathics your example:
In[2]:= A+B /. x_+y_ -> x+y+C
Out[2]= A + B + C
In[3]:= A+B /. x_+y_ -> y+C
Out[3]= B + C
In[4]:= A+B /. {x_+y_ -> x+y+C, x_+y_ -> y+C}
Out[4]= A + B + C
In[5]:= A+B /. {x_+y_ -> y+C, x_+y_ -> x+y+C}
Out[5]= B + C
Rules are applied according to their order.
> > 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?
>
There is none, it's a suggestion. I like the way Mathematica allows to
rewrite formulae, there is no equivalent in power in SymPy. I would like to
see what other people think.
I had a look at Matthew's strategies and unify modules. I had the
impression that "strategies" look good to implement exploratory algorithms,
i.e. when there is no clear pre-determined scheme of which transformations
to apply. Unification on the other hand does not provide subtree matching.
I believe that subtree matching/rewrite is very important to a CAS.
> 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.
>
>
Yes, there is no need to devise a new design, furthermore there are many
open-source libraries written in Mathematica which could potentially be
very useful.
> 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.
>
>
Mathics already has an extensive coverage of all major features of
Mathematica's language, that's a plus in re-implementing Mathematica's
design. Unfortunately SymPy requires some generalizations to make that
design compatible with type-based expression trees and mixed
commutativity/non-commutativity.
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.
>
That is what I also thought, especially considering the fact that we can
look at Mathics' source code.
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".
>
There is another interesting programming language:
https://en.wikipedia.org/wiki/Pure_%28programming_language%29
It's open source, I didn't have time to examine it so far. Maybe that one
could also be used to get some inspiration.
>> 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.
>
>
In Mathematica, the underscore sign is an operator, these shows how the
given expression is represented (think *//FullForm* as being somewhat
analogous to SymPy's *srepr*):
In[7]:= x_y // FullForm
Out[7]= Pattern[x, Blank[y]]
In[8]:= _x
Out[8]= _x
In[9]:= _x // FullForm
Out[9]= Blank[x]
In[10]:= _x_x_x_ //FullForm
Out[10]= Times[Blank[], Power[Blank[x], 3]]
> 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".
>
Maybe *symbols( ) *and *var( )* could detect a trailing underscore sign
(e.g. x_ ) and call the Wild constructor in step of the Symbol constructor.
It would be much easier to use it in isympy with automatic symbol
declaration mode.
--
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/8edc111e-7da7-44f0-ad92-9b52dad716c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
