NOTE: the Reduce.jl package has been created since this discussion started
Using Julia is a really great experience, thanks to all of you!
Since Julia is so inspired by the lisp language, is it feasible to combine the functionality of the Lisp-based computer algebra system known as Reduce Algebra (which is known to be the fastest of its genre) with the Julia language? Having high performance numerical computing in Julia is very great, can high performance symbolic computation also be emphasized? With SymPy and Symata and the Julia syntax, I see a promising future; but it needs to include Reduce algebra in its vision too, I believe. Reduce algebra does symbolic computation very efficiently and has many decades of experience and is available as open source. At the very least, there is probably something Julia could learn from it. Would be great if Reduce Algebra was added to the list of languages that helped inspire the future of Julia.
In the recently published paper in SIAM Review, there were some embedded examples of Jupyter REPL input and output. Is there a specific LaTeX package that was used to achieve this? Recently I discovered the SageTeX package, which is wonderful because it makes embedding and executing Sage code in a compiled LaTeX document a breeze. Will there be tools to make embedding Julia computations, code, and results into LaTeX documents easy and efficient in the future? If Julia was very easily callable from LaTeX, also for inserting graphics; that would be great.
These 2 topics are important for the future of the Julia language, I believe.
My point is only to raise these 2 topics to attention for further discussion,
You’re missing SymEngine, which is probably your best bet here. SymEngine is a re-write of the core SymPy engine to C++. However, it works well with Julia because its basic type has a lot of dispatches (+,-,exp, …), and so things like Julia’s Base library (inv) just “complete the functionality of it”. The only thing that it really needs it an equation solver and some Groebner Basis methods, though some of this could probably be implemented in Julia directly using the dispatches. Since the dispatches are just calling the C++ functions, it ends up being really speedy and easy to extend.
If you are interested, you should start by writing a package for interfacing with Reduce. Similarly, if you think that ideas from Reduce could improve Julia, contribute them. Discussion is interesting, but it is unlikely to inspire someone without an interest to put in the work.
Thanks for the responses. I’d like to help contribute to a package for interfacing Reduce, but I don’t claim to have the right kind of background knowledge to know how to start. Are there any suggestions for how to go about it?
But I don’t think there is a set of background knowledge to make a package other than… make a package. It’s tough the first time, but with some help it works out.
Combining julia with an interactive lisp program like this is actually not too difficult. Maxima.jl is an example of exactly that. The basic idea is to spawn a session with interpretor you care about and reading and writing to a Pipe to make your calls and read the results.
input = Pipe()
output = Pipe()
proc = spawn(`reduce`, (input, output, STDERR))
write(input, "(x + y + z)^2;") # submit input to REDUCE
answer = String(readavailable(output)) # read out response
Hope that helps! Feel free to reach out if you find any problems trying to get REDUCE and Julia to talk to each other.
Thanks for that information, it will help. I wouldn’t know exactly where to start with the REDUCE thing, but investigating at the Maxima package sounds like the right place to look. I have the latest verion of Reduce and Maxima compiled, so I will be able to give a shot at it.
Yeah take a look in src/server.jl (a bit of a misnomer, related to a previous TCP server-client implementation) for the implementation of the MaximaSession and in src/mexpr.jl for the details of making calls to with mcall.
Similar to Maxima.jl package, you can use rcall to evaluate Julia expressions or reduce string using reduce.
julia> rcall(:((1+Ď€)^2))
:(Ď€ ^ 2 + 2Ď€ + 1)
From here, the REPL and additional Julia integration can be done.
However, I am not sure yet how to wait to read the input from the reduce pipe, sometimes the computation can take longer, so the read operation would have to wait for it to finish.
In Maxima.jl, I make maxima write the ASCII End of Transmission (EOT) character to the terminal and then the pipe reads until it hits the EOT character. In maxima this is pretty easy with the print(ascii(4)) command but I’m sure you can find the REDUCE equivalent.
Gotcha, will need to experiment with the best solution for that. You might also want to look at some of the things I did in Reduce.jl, for example
function parse(r::RExpr)
str = r.str
for key in keys(r_to_jl)
str = _subst(r_to_jl[key], key, str); end
for key in keys(r_to_jl_utf)
str = replace(str,key,r_to_jl_utf[key]); end
parse(str); end
In this function I have added a second loop that iterates over an extra dictionary of symbols. This is because reduce and maxima cannot handle the expanded characters like π (for example), so in the _subst iteration only replace the ASCII characters and then afterwards use Julia string replace function to splice the greek symbols back in.
Similarly for the conversion in the opposite direction. I also implemented some error handling in show that you had on your TODO list, but it is based on the way REDUCE produces error messages, but maybe you can use something similar there.
Actually, Maxima can handle UTF8. The only caveat being that Maxima has to be compiled with a common lisp that supports UTF8. Maxima compiled against sbcl works fine.
Having 2 loops like this could make Maxima.jl more compatible for a wider range of maxima installations. I get an error since I don’t have sbcl version set up.
Thanks for all the input, I’ve solved the end of transmission delimiter issue now.
Hi, I have communicated with the upstream developers about updating their build system in order to make additional binaries available for Windows users that make it easier to do the automated build tests on appveyor. This was in late 2017. They were interested in it, but it is not one of their main priorities right now.
Since I don’t have direct access to a typical Windows computer right now, I can’t really make a lot of progress on it myself.
The build script can download the Reduce installer for windows perfectly fine, the only issue currently is that the binary they provide requires an administrator priviledge on Windows to execute, which I’m not sure how can be circumvented on appveyor. My idea was to try making a cab file that can be extracted from the command line, which I think they could incorporate into their build system. However, nobody has really had the time or Windows computers available to properly set it up.
So you can use it on windows, the only issue is making it work on appveyor.
Maybe Julia could ship it with JuliaPro for windows users or something like that?
As far as it being fast, you can test it out yourself. You will find it is indeed very quick. In Julia, it will seem slower, due to the 2-way parsing that has to be done. There are some sources online, where you can read about why people prefer Reduce over, say Mathematica, since it is open source for example, and can also solve some problems faster than it. My goal isnt to try to convince you it is the fastest, but it is very quick and efficient and has been documented to be so in various posts and discussions online. I am still working on making the Julia interface more quick and efficient.
I am just curious to see those sources. Searching for “Reduce” in Google brings up a lot of false hits, and I never heard of it before the Julia package so I’m curious to find some real benchmarks to know what to expect.
As for AppVeyor, I mostly ask because I won’t be checking it out until that holds. I kind of need it for package development .
Yes, I understand your concern. I want it to work on Windows as well, and I understand that is holding people like yourself back.
Hopefully, this issue will get resolved over the summer. There are still some improvements and changes that will happen to the package, so my hope is that in the summer when julia 1.0 is released, that also Reduce.jl 1.0 can be released with the appveyor build support. Then I will be making an official announcement for the package, once that is in place.
As for sources, here is an example of a user who benchmarked a Ginzburg Landau problem with Reduce and Mathematica:
The developers of reduce acknowledge that they would like more testing to be done, so that the current performance can be better understood. But I dont believe that a precise study has been done recently. However, you can find on the order of 1,000 references on their website to find research that used their software.
.