El martes, 21 de abril de 2015, 13:16:02 (UTC+2), Marcus Appelros escribió: > > Which cases can not be handled by your native expander?
A lot of cases, IIRC it only does binomial expansion. > Currently > Equations should handle all standard cases I checked it out tried a few things. It's very nice. The expansion worked fine, and no mystery about how to use it. > (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. > > I'm trying in on a few machines and I'm a bit confused on requirements and compatibility. Some of it might depend on the version of SymPy that is installed. I think it needs to be a recent one. > On 21 April 2015 at 13:35, <lapeyre....@gmail.com <javascript:>> 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! >
