El martes, 21 de abril de 2015, 7:52:19 (UTC+2), Marcus Appelros escribió: > > "Thank you for offering to help. I would like to phase out SymPy, but I > don't see it happening in the foreseeable future. I'm not sure how to > quantify the amount of capability in SymPy, but it is more or less > "enormous". I think I could work 8 hours a day for a year and not duplicate > it in Julia." > A better approach might be to complement SymPy, what would you say is > missing from SymPy? Also keeping it from entangling with the core like it > is now easy to disable SymPy by commenting two lines. > > Yes, it would be nice to make SymPy optional, but that would take some work. In fact, the native Julia/SJulia Expand is much faster than SymPy, but handles fewer cases. Currently, the native version is disabled in favor of SymPy. Using the native version when possible would be better, but the logic would be quite a chore.... maybe its better to wait until there is a full replacement for Expand. Regarding what's missing, I don't really know. You could hang out on their lists. They are developing. Maybe an example is SJullia 'Count'. It takes a pattern as an argument. I don't think SymPy does something like this now, but they have some pattern matching and there is talk about doing something new. The way pattern matching is used in functions like 'Count' needs to be generalized. But really a better thing would be to spend some time looking at SymPy and SJulia (and maybe other things) and see what interests you. Or maybe what you are trying to do with Equations (I didn;t look at it yet carefully) is really complementary to SJulila. I really think the most important thing is to improve the Julia <--> SymPy AST translation. But, this is free software; I expect that you'll do, like everyone else, what you are motivated to do and what you find interesting.
Good plans for the future involve letting SJulia and Equations with > offsprings mingle behind the scenes, at the base there will certainly be > some duplicated functionality however am intending to quickly progress to > very specialized implementations. > > Sure, it's good not to duplicate effort, and to get things to play well together. If you keep up with Equations, I am interested in helping it communicate with SJulia. I may have said it before, but my primary interest with SJulia is making something like Mathematica that is useful of r 'the masses' and not only computer enthusiasts, ie something for people who want to get an integral quickly and hate hearing 'everything is an object' and 'homoiconic'. The Julia and Python ecosystems and support for interfacing are awesome, which is really something to take advantage of. I'm glad I took Francesco Bonazzi's advice (and help) about translating the SymPy AST sooner rather than later. Interfacing with Maxima (and maybe, eg. Axiom) might be very useful as well, but I'm not going to investigate writing a CL interface at the moment. > "Your example does work for me using Version 0.4.0-dev+3965 (2015-03-22 > 12:24 UTC), > but things break fast with 0.4.0 !" > Alright will have to get access to recent versions of everything, > configuring a cloud computer to handle julia comfortably, it is currently > running with minimum resources. > > I just tried SJulia on a recent Julia v0.4 build. I mostly works, but there are some new errors. > "You shouldn't need to do all that. I'll have to build a new v 0.4.0 and > see if there is a problem." > Was looking for the source code for the expansion, expanding large > polynomials is currently a problem in Equations. > > "Yes, the macro is expanded when it is entered. Julia functions can be > used with SJulia, but it is not integrated to this extent. I think I do > have a Julia-side interface to Expand, but it is disabled. I need to find a > more organized way to make some SJulia functionality available from Julia." > How do julia functions work at sjulia>... ? > > "The SJulia command line mode is now built into the module, you no longer > need to build the fork of Julia (thanks Keno)." > Superduper! >
