I think PyCall already has what you need for conversion: PyObject(big(pi)) will create a an mpf instance of a big float, like big(pi) convert(BigFloat, PyObject(big(pi))) will return a BigFloat from an mpf instance.
On Thursday, February 26, 2015 at 6:57:37 AM UTC-5, lapeyre....@gmail.com wrote: > > BTW. > > Do you know much about the SymPy interface ? (or maybe the authors are > reading this ?) > Francesco has already supplied a lot of information, but I am new to sympy. > > Here, I ask for an integer to be converted with _to_mpmath > > https://github.com/jlapeyre/SJulia/blob/master/src/sympy.jl#L89 > > And find that if the integer is actually a machine integer, then I get an > Int64. So big > integers go to big integers and machine integers to machine integers. > > Is there something similar I can do to get big float and machine floating > point to map correctly > to Julia ? I'm not sure how SymPy encodes complex and rationals, but > the code I have seems > to handle all of these correctly. > > On Thursday, February 26, 2015 at 4:30:04 AM UTC+1, Ondřej Čertík wrote: >> >> Hi John, >> >> I just discovered this thread, some comments: >> >> On Wed, Jan 28, 2015 at 9:53 AM, <lapeyre....@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 >> >
