You could read about unification, unification with identity,
associativity, etc.
You could add solving as a method of matching but probably you don't want
to use this routinely. Maxima's matcher does a little of this and most
people
find it surprising.
I think it would be unfortunate if you
I don't remember if it's currently possible, but it's definitely
something that we would like to be able to do. It would also be better
to have the matrix expressions assumptions in the matrix expressions
module, for instance.
Aaron Meurer
On Mon, Jul 28, 2014 at 12:18 PM, F. B.
Concerning the new assumptions to be added for the pattern matcher, is it
possible to use the assumption system by creating new assumptions outside
of the assumptions module?
For example, Q.freeof( ) would be better placed in a pattern matching
module, rather than in the assumptions module,
On Thursday, July 17, 2014 7:07:19 PM UTC-7, Matthew wrote:
The benefit of pattern matching is that 1 complex if-then-else
constructions are hard to write well.
Writing 10,000 rules and being sure that you have 100% coverage of all
possible case and no overlap is
a challenge. It's
On Friday, July 18, 2014 5:33:02 PM UTC+2, Aaron Meurer wrote:
On Fri, Jul 18, 2014 at 6:38 AM, F. B. franz@gmail.com javascript:
wrote:
On Friday, July 18, 2014 5:05:37 AM UTC+2, Ondřej Čertík wrote:
This is also the sort of thing that would benefit from a performant
On Saturday, July 19, 2014 9:30:34 PM UTC+2, F. B. wrote:
Consider the wild *a_.* in the expression above. *a_* would be an
ordinary wild, while the dot tells you that if there is no match for *a_*
in the expression, than *a_ *should be matched as the identity element of
operation, that
On Sat, Jul 19, 2014 at 1:35 PM, F. B. franz.bona...@gmail.com wrote:
On Saturday, July 19, 2014 9:30:34 PM UTC+2, F. B. wrote:
Consider the wild a_. in the expression above. a_ would be an ordinary
wild, while the dot tells you that if there is no match for a_ in the
expression, than a_
On Fri, Jul 18, 2014 at 6:38 AM, F. B. franz.bona...@gmail.com wrote:
On Friday, July 18, 2014 5:05:37 AM UTC+2, Ondřej Čertík wrote:
This is also the sort of thing that would benefit from a performant
core.
We would write patterns in SymPy and then match them using some C++
matching
On Thursday, July 17, 2014 7:07:19 PM UTC-7, Matthew wrote:
The benefit of pattern matching is that 1 complex if-then-else
constructions are hard to write well.
Writing 10,000 rules and being sure that you have 100% coverage of all
possible case and no overlap is
a challenge. It's
On Thu, Sep 26, 2013 at 6:37 PM, Aaron Meurer asmeu...@gmail.com wrote:
My idea was to put assumptions on Wild expressions. I guess using the
new assumptions system, the assumptions do not need to be, nor should
they be, actually tied to the symbols. This will also make it easy to
add
Rubi is apparently structured so that at any time at most one rule will be
applicable,
and it should be easy to figure out how to exclude everything else. I
think that
Albert Rich even expressed the notion that Rubi did not actually need to be
structured as rules..
--- just If/then/else
The
On Thu, Jul 17, 2014 at 7:27 PM, Richard Fateman fate...@gmail.com wrote:
Rubi is apparently structured so that at any time at most one rule will be
applicable,
and it should be easy to figure out how to exclude everything else. I think
that
Albert Rich even expressed the notion that Rubi
The benefit of pattern matching is that 1 complex if-then-else
constructions are hard to write well. Richard the popularity of pattern
matching has been pretty much dead since the 90s. That being said it isn't
a poor crutch, languages like Maude, Elan, and more recently Stratego/XT
What's your idea to include assumptions in pattern matching?
I have some hypothetical uses:
1. a = Wild('a', assumptions=[Q.is_positive])
2. a = Wild('a'); a Q.is_positive(a)
3. expr.match(expr2, assumptions= ... )
Any better ideas?
--
You received this message because you are
On Thu, Sep 26, 2013 at 11:45 AM, F. B. franz.bona...@gmail.com wrote:
What's your idea to include assumptions in pattern matching?
I have some hypothetical uses:
a = Wild('a', assumptions=[Q.is_positive])
a = Wild('a'); a Q.is_positive(a)
expr.match(expr2, assumptions= ... )
What
On Thursday, September 26, 2013 8:39:28 PM UTC+2, Ondřej Čertík wrote:
On Thu, Sep 26, 2013 at 11:45 AM, F. B. franz@gmail.com javascript:
wrote:
What's your idea to include assumptions in pattern matching?
I have some hypothetical uses:
a = Wild('a',
My idea was to put assumptions on Wild expressions. I guess using the
new assumptions system, the assumptions do not need to be, nor should
they be, actually tied to the symbols. This will also make it easy to
add assumptions about general expressions, not just Wilds (and make it
easier to do the
Int[cos[a_.+b_.*x_], x_Symbol] := Sin[a+b*x] / b /; FreeQ[{a, b}, x]
Here *a* and *b* are matched if they do not contain *x*.
Well, I'm a bit confused, but I was just considering, when we call an
integration function:
*integrate(expression, x)*
we already know that *x* is the integration
@Mario: Thank you very much for the reply. I will have to go for this
option If I am unable to
fix `match()`
@Aaron: Sure.
Regards,
Thilina
On Mon, Sep 16, 2013 at 3:43 AM, Aaron Meurer asmeu...@gmail.com wrote:
It's annoying to do this all the time, though. With dsolve and
classify_ode, I
It is easy to write a custom match; in the following example there is a
match for a quartic
form; it is easy to write additional conditions, like restriction to 3
variables, integer coefficients,
etc.
def match4(t):
... match a quartic form
... a = []
... for xx in t.args:
...
It's annoying to do this all the time, though. With dsolve and
classify_ode, I ended up writing a bunch of custom matchers, but it's
much less robust than using Wild() and match() when they work.
Even for things that really do have to be algorithmically matched
(e.g., the homogeneous_order hint
On Apr 28, 2:59 am, Ronan Lamy ronan.l...@gmail.com wrote:
Le mardi 27 avril 2010 à 15:49 -0700, basti a écrit :
Like many others before I stumbled over sympy's pattern matching. I'm
mainly interested in matching non-commutative expressions - which is
currently simply not implemented.
On Apr 30, 3:05 pm, basti basti...@gmail.com wrote:
On Apr 28, 2:59 am, Ronan Lamy ronan.l...@gmail.com wrote:
Le mardi 27 avril 2010 à 15:49 -0700, basti a écrit :
Like many others before I stumbled over sympy's pattern matching. I'm
mainly interested in matching non-commutative
On 28 avr, 02:59, Ronan Lamy ronan.l...@gmail.com wrote:
This issue has been raised many times and I think nobody likes the
current situation. However, the current behaviour is quite convenient
when it works, and much code depends on it. I think that the best
solution is to distinguish
On Apr 28, 2:59 am, Ronan Lamy ronan.l...@gmail.com wrote:
* Refactor whole matching logic into a separate module, and use the
Basic.match function only as interface. This was also done for
printing and I think the pattern matching is complex enough to justify
this step.
I don't
On Mon, Jul 14, 2008 at 8:41 PM, Roberto Nobrega [EMAIL PROTECTED] wrote:
I created a new issue for that, I hope that is okay.
Yes, it's perfectly ok, thanks. If you'd like to work on it, I'll help
you with any questions you might have.
Ondrej
On Thu, Jun 19, 2008 at 5:47 PM, Roberto Nobrega [EMAIL PROTECTED] wrote:
I'm running latest hg version:
[EMAIL PROTECTED]:~/Projects/sympy$ hg tip
changeset: 2143:ccebd03423df
tag: tip
user:Riccardo Gori [EMAIL PROTECTED]
date:Wed Jun 18 17:47:53 2008 +0200
On Thu, Jun 19, 2008 at 3:14 AM, Roberto Nobrega [EMAIL PROTECTED] wrote:
While checking SymPy wiki's tutorial about pattern matching, I ended up with
the following:
from sympy import *
x = Symbol('x')
p = Wild('p')
q = Wild('q')
(5*x**2 + 3*x).match(p*x**2 + q*x)
I got the following
I'm running latest hg version:
[EMAIL PROTECTED]:~/Projects/sympy$ hg tip
changeset: 2143:ccebd03423df
tag: tip
user:Riccardo Gori [EMAIL PROTECTED]
date:Wed Jun 18 17:47:53 2008 +0200
summary: Matrix-number multiplication speedup 700%
[EMAIL
29 matches
Mail list logo
