Thanks for the info Ondrej and John.
On Friday, February 27, 2015 at 4:31:46 AM UTC+1, j verzani wrote:
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
On Thu, Feb 26, 2015 at 3:44 AM, lapeyre.math1...@gmail.com wrote:
(I am resending because, this my message to Ondřej did not go to the list)
I can see my message right here:
https://groups.google.com/d/msg/julia-users/jP1VlOe80HQ/e4KzNARuI9AJ
Do you know much about the SymPy interface ? (or
(I am resending because, this my message to Ondřej did not go to the list)
Hi Ondřej,
The various sympy projects are very interesting, your work porting Rubi
especially.
SJulia is using SymPy for a lot of features (Integrate, Solve, ...) . Here
is some test code
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
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
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
On Wednesday, January 28, 2015 at 5:53:00 PM UTC+1, lapeyre@gmail.com
wrote:
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.
https://github.com/mathics/Mathics/blob/1a5cd204b76595730bdf4a91a6696a3292159d1a/mathics/core/util.py#L59
These are the util functions of Mathics for its own AC matching
(GPL-licensed). They are lazy permutation generators, maybe you can find
them useful: subranges for associative matching,
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
By
Francesco, I just realized that Mathics is actually aiming to implement the
Mma language. For some reason I thought it was only using the same syntax.
So, this is indeed similar to what I am trying to do. Except that I
consider the code that I have now to be an experiment.
On Wednesday,
http://www.apmaths.uwo.ca/~arich/
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? I wonder if the switch
is being made
for organizational, or efficiency reasons. I decision tree might be
easier
On Monday, January 26, 2015 at 7:20:54 PM UTC+1, Francesco Bonazzi wrote:
A Mathematica parser could be used as an optional addition, such as what
Mathics is to SymPy.
Anyways, there are various options for Julia:
- use Expr and operate on them, this is similar to how Maxima works.
(My posts are not appearing where I want. Hope this one does!)
On Monday, January 26, 2015 at 6:57:48 PM UTC+1, James Crist wrote:
Maybe the parser could be useful if rewritten in Julia:
Side tracking a bit, but one of the reasons I use SymPy instead of
something like Maxima is that it
Maybe the parser could be useful if rewritten in Julia:
Side tracking a bit, but one of the reasons I use SymPy instead of
something like Maxima is that it meshes seamlessly into the language
infrastructure. By writing a parser and creating another system means that
it can't use julia's
14 matches
Mail list logo
