Which cases can not be handled by your native expander? Currently Equations should handle all standard cases (it is training to be able to revert an expansion into a Pow) but it isn't feasible for stuff like (:x+:y+:z)^100. Am writing a generalized expression matcher to create chains of equations, will develop structures for equationchaining in non-commutative geometry and quantum gravity, in collaboration with Vietnam national university.
We share goals, want Equations to be so simple that essentially only one function needs to be called, then an AI handles that function and the user tells the AI what they have and where they want to go from which the AI delivers the closest match. Have been building the current master since morning, there is some build error at osutils and have just ran a distupgrade+reclone, will file and clone your fork if that doesn't work. On 21 April 2015 at 13:35, <[email protected]> wrote: > > > 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!
