On Sunday, November 30, 2014 12:30:02 PM UTC-8, Joachim Durchholz wrote:
snip...
Partial evaluation isn't doable at all.
I don't know what you mean by partial evaluation.
Difference between lazy and eager evaluation.
Is this something you
think that Lisp does? Maybe
Am 01.12.2014 um 23:25 schrieb Richard Fateman:
There is also the thorny question of the environment to be used for
evaluation.
e.g.
what is to be done in
(let ((a '+)
(b 43))
(eval s) )
does a, b, have bindings from when one did (setq s '(a b c d))?
or the new lexical bindings.
Am 30.11.2014 um 06:53 schrieb Richard Fateman:
Sorry to be argumentative, but Norvig's book is teaching about how one
can go about solving certain problems common in symbolic artificial
intelligence, and that is relevant in any language.
Agreed.
The book probably
shows you how some of
Awesome! That is one of the missing pieces for sympy for sure!
I would definitely have a look at the pattern matching of Mathematica,
to see what kinds of things are useful and needed for that type of
thing.
Cheers,
Brian
On Wed, Nov 26, 2014 at 3:19 PM, James Crist crist...@umn.edu wrote:
On Sunday, November 30, 2014 1:52:08 AM UTC-8, Joachim Durchholz wrote:
Am 30.11.2014 um 06:53 schrieb Richard Fateman:
First-class functions are easy in Python (easier than in C/C++).
OK, I thought I read somewhere about some limitations.
What you can't do easily is macros. There's
Am 30.11.2014 um 20:18 schrieb Richard Fateman:
I just don't understand this emphasis on the difficulty of macros.
Issue is that tools don't know about these preprocessors.
This affects IDEs when finding the definition of a name, or when
refactoring; also stack traces tend to not reflect
I guess solve() would do it, although this has the potential to make
the pattern matcher very slow, and also make it return results that
are all but useless (e.g., I wouldn't want the pattern matcher to
return the cubic formula because it technically makes the pattern
match some expression that
On Fri, Nov 28, 2014 at 6:40 PM, Richard Fateman fate...@gmail.com wrote:
On Thursday, November 27, 2014 7:49:30 PM UTC-8, James Crist wrote:
Oh boy, this is going to be a big post. Responding to everyone in turn:
*@Aaron:*
Nonlinear, AC pattern matching is NP complete. Linear AC
@Richard,
Thanks for the Jenks paper, that was a good read. I also read your paper on
semantic matching http://dl.acm.org.ezp2.lib.umn.edu/citation.cfm?id=806300,
which only detailed the use of matching in Macsyma, and not its underlying
workings. I failed to find anything on how it actually
The system described in the Jenks paper would work better than what I've
written if we plan to use relatively small sets of small patterns. Larger
patterns, or larger rulesets will work better with what I'm writing, (I
think), as they will have more potential paths, and generating specialized
Am 29.11.2014 um 18:52 schrieb James Crist:
The system described in the Jenks paper would work better than what I've
written if we plan to use relatively small sets of small patterns. Larger
patterns, or larger rulesets will work better with what I'm writing, (I
think), as they will have more
Matching against identities can be valuable. Writing out several
variations for a intended single pattern feels like a hack.
Or at least, that was my experience with my matrix expressions system. I
wasn't able to cleanly add in identities so I shoved in lots more
patterns. Things worked.
The
On Friday, November 28, 2014 9:25:01 PM UTC-8, Joachim Durchholz wrote:
Am 29.11.2014 um 02:44 schrieb Richard Fateman:
On Thursday, November 27, 2014 10:35:34 PM UTC-8, Joachim Durchholz
wrote:
Awesome.
The papers I've read have been almost exclusively from the theorem
On Saturday, November 29, 2014 8:29:56 AM UTC-8, Aaron Meurer wrote:
big snip
.
Another question is, how can you teach the pattern matcher that a function
maps to an identity, like cos(a)*x can match x with a = 0, or x**a*y can
match y with a = 0?
You can do this (trivially)
Actually, my pattern matcher in Maxima DOES some solving... in particular
the example I gave..
matchdeclare(a,true);
defrule(r1,f(a+1), g(a));
r1(f(4)) returns g(3)
but it only solves simple linear forms.
I think the lisp code for my matcher is fairly clear. matcom.lisp is the
match
On Thursday, November 27, 2014 7:49:30 PM UTC-8, James Crist wrote:
Oh boy, this is going to be a big post. Responding to everyone in turn:
*@Aaron:*
Nonlinear, AC pattern matching is NP complete. Linear AC pattern matches
can be found in polynomial time.
Interesting. Why is that?
On Thursday, November 27, 2014 10:35:34 PM UTC-8, Joachim Durchholz wrote:
Awesome.
The papers I've read have been almost exclusively from the theorem
proving
world.
I think you should be mostly fine working off these.
I disagree, unless you are able to find much better papers
Am 29.11.2014 um 02:44 schrieb Richard Fateman:
On Thursday, November 27, 2014 10:35:34 PM UTC-8, Joachim Durchholz wrote:
Awesome.
The papers I've read have been almost exclusively from the theorem
proving
world.
I think you should be mostly fine working off these.
I disagree, unless
Response in line
On Wed, Nov 26, 2014 at 3:19 PM, James Crist crist...@umn.edu wrote:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it
Am 27.11.2014 um 16:47 schrieb Matthew Rocklin:
- Is there need for nonlinear patterns? I plan to account for them, but
they make the algorithm a bit more complicated. Nonlinear, AC pattern
matching is NP complete. Linear AC pattern matches can be found in
polynomial time.
I haven't thought
Am 27.11.2014 um 00:19 schrieb James Crist:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it needs some serious cleanup),
but as of now it is
There's a long history of pattern matching fast including work by Richard
Jenks,
(Scratchpad, predecessor of Axiom). The general scheme is to take a
collection
of patterns and compile them into a tree form so that partial results from
pattern 1
can be used to improve speed on pattern 2, etc.
Am 27.11.2014 um 20:52 schrieb Richard Fateman:
I don't know if your AC matcher is intended to be used for (say)
arithmetic expressions
or something else. But if arithmetic -- your stuff also needs to deal with
identities.
In that case if
you don't handle identities, your matcher becomes far
Oh boy, this is going to be a big post. Responding to everyone in turn:
*@Aaron:*
Nonlinear, AC pattern matching is NP complete. Linear AC pattern matches
can be found in polynomial time.
Interesting. Why is that?
Joachim got it right, having each match constrained by other matches,
On Thu, Nov 27, 2014 at 8:47 AM, Matthew Rocklin mrock...@gmail.com wrote:
Response in line
On Wed, Nov 26, 2014 at 3:19 PM, James Crist crist...@umn.edu wrote:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative
Awesome.
The papers I've read have been almost exclusively from the theorem proving
world.
I think you should be mostly fine working off these.
Essentially it's all tree matching of some kind. Things will start to
diverge as soon as domain specifics start to matter; it would be nice to
have
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it needs some serious cleanup),
but as of now it is partly functional. Some notation:
T = set
On Wed, Nov 26, 2014 at 4:19 PM, James Crist crist...@umn.edu wrote:
All,
In my spare time, I've been working on implementing a fast pattern matcher
that accounts for Associative and Commutative symbols. It's going to be a
while before I'm ready to release the code (it needs some serious
28 matches
Mail list logo
