Hi John, I just discovered this thread, some comments:
On Wed, Jan 28, 2015 at 9:53 AM, <lapeyre.math1...@gmail.com> wrote: > > > On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi > wrote: >> >> >> >> On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote: >>> >>> > I read that the next version of Rubi will feature a decision tree, no >>> > longer pattern matching. >>> >>> Interesting. I don't see it, do you have a link? >> >> >> https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 >> > > This looks great (at least based on the linked post) It no longer relies I wrote that post. I also created a PR with actual SymPy code here: https://github.com/sympy/sympy/pull/8036 It seems to work great so far. I am waiting for more code from Albert (I CCed him) and also I need to polish the PR some more. I also tested Rubi using Mathematica, and it seems faster and more robust (it can also do more integrals) than Mathematica's Integrate[] function. Albert said that on his benchmarks, the if/then/else form is massively faster than the pattern matching (maybe up to 100x on some examples). > on the sophisticated part of the core Mma language, so it greatly broadens > number of languages able to run Rubi. (Its only one now: Mma itself) I > guess it's not too much trouble to emit sympy code. I'm pretty sure this > could be easily adapted to Maxima. In fact I wrote an Mma to Maxima > translator a while ago (Hmm I should put it on github) so it might work > immediately. It uses RJF's CL Mma parser (uhh. too many acronyms). The > translator can't handle Mma patterns (maybe just a liitle, I don't remember) > My translator could translate and pass tests for a fair size quantum > information package. It also translated and correctly ran some symbolic > quantum mechanics code used in research that was written by a colleague. > But, it was unacceptably slow, because Maxima uses linked lists for > expressions, which require fundamentally different algorithms, not just > translation... I'm digressing. > > I guess Albert Rich still maintains the data in some other form ? Or is he > editing these big nested conditional statements ... My understanding is that unfortunately he edits the nested conditional statements. Apparently it is not easy to automatically translate the pattern matching rules into a polished if/then/else form, though ultimately it would be nice to have that. The if/then/else is nice, that you can step through it easily via a debugger, and the only way this might not finish is if the functions call each other recursively. If you are interested in helping out with Rubi, please write to Albert. He might really use some help with this, and lots of projects would benefit. He maintains it in Mathematica, and then have automatic translators to other codes, including Maxima and SymPy. >> By the way, I was thinking about the syntax, what about instead of >> >> @ex f(x_, y_Integer, z) := ... >> > Well, I kind of tried different things, including :: at one point. I > gradually moved away from a Julia extension to really another language: I > just wanted the patterns, but they need support from expressions, but that > requires a consistent evaluation sequence, etc. But, because I am relying on > Julia's parser, the options are limited: the parser has to believe it's > valid Julia code (although it won't eval). So, if I disallow underscores in > identifiers and interpret them instead as signifying patterns, I don't > consume any of the limited available Julia syntax. In Mma you can have one, > two, or three underscores before and/or after an identifier, each > combination of which means something different. All of that has to be > encoded in Julia syntax. By disallowing underscores, the whole problem is > solved. I started to implement the Mma "Condition", which is yet another > essential feature of the pattern matching. I tried :: for *that*, but it has > high precedence, so you need to use parens, which I don't like. For now, I > decided on just Condition(a,b). Furthermore, I stopped implementing > Condition because it is relatively easy to do. AC matching is a b$&%h. For > me, there's no sense in continuing the experiment unless I'm convinced the > harder stuff can be done. Of course if you, or someone else want a > particular feature to play with, I'd gladly consider implementing it. At > present, I consider using the stock Julia parser a stopgap. I did spend some > time with the RJF parser and even found a minor bug or two. I also looked at > the Julia parser. For me, it looks like a big job. But, if someone else > wants to do it, great! > >> Anyways, it looks like on your patterns you are implicitly introducing an >> Mxpr <-> type correspondence, i.e. if in x_A the expression A were >> considered both as the head of an Mxpr and as a Julia type. > > Yeah, thats kinda it. Mma tries to maintain a fiction that non-expression > types are really expressions with a particular head and zero length. So in > your example, A might be a type or the head of an expression. I make the > symbol 'Integer' Protected (except, I don't think I have yet put it on that > list in the code), then under certain circumstances, it is evaled to get a > DataType. > >> Any thoughts about interpolation of Julia variables in the @ex macro? I >> tried to call a=3; @ex f($a) but it doesn't work. > > Yes, this works: > > a = 3; @ex f(JVar(a)) > > Not pretty, but I don't want to introduce new syntax/language features at > this point. JVar is done very easily in the standard Mma way. > > apprules(mx::Mxpr{:JVar}) = eval(symname(mx.args[1])) > > That's it. Note that this evaluates a, then evals the result, etc. until it > stops at an SJulia symbol that evaluates to itself. This is the Mma > behvavior, which > I am sticking with for now. If the attribute 'HoldAll' is set for 'JVar', > then JVar(a) always evaluates the Julia symbol :a. Both would be useful, I > just didn't implement that yet. I'll document this . Please ask any other > questions you may have. > Note that I pollute the Julia side, by setting undefined Julia vars to true, > so that the repl completes them in SJulia. You can > turn this off by commenting out a line in mxpr_type.jl . Finally I would mention that in SymPy, we are also developing a very fast C++ core (https://github.com/sympy/csympy), which is actually pure C++, the Python wrappers and seamless SymPy integration (using the Python wrappers) is optional. We also have a C interface (https://github.com/sympy/csympy/blob/master/src/cwrapper.h), though it needs to be extended to cover all CSymPy's functionality. The goal of the C interface is that it can now be trivially called from Julia, here is some preliminary code from Isuru (also CCed): https://gist.github.com/isuruf/cb4f16d05b7266de227b If any of you would like to play with it and help us write a nice Julia interface, that would be awesome. Then we can easily benchmark it against any other computer algebra implementation in Julia. The goal of CSymPy is match performance of any other computer algebra system (or be faster). We are still working on it. Ondrej
