Glad you like it!
Am thinking about how to recognize general n-nomials, to be able to
run a match like matches(:a+:b+:c...,Sum(x_1,x_n)^y) would be really
neat. With n = 2 we get the result from considering how many x_1 we
want in our term and seeing how many ways we can choose that many x_1
from the y terms, if we have n x's and know the term we want it should
be possible to get the answer by combining binomials, like with y=7
and we want x_1^3*x_2*x_3^3 we can first pick 3 from 7 then 1 from
4..: binomial(7,3)*binomial(4,1)*binomial(3,3) which equals 140 and
Equations result: addparse(simplify((:x1+:x2+:x3)^7))[14] ==
{140,:x1,:x1,:x1,:x2,:x3,:x3,:x3}.
Have not gotten to the stage where packages can be installed yet, have
opened an issue: https://github.com/JuliaLang/julia/issues/10921
On 21 April 2015 at 16:13, <[email protected]> wrote:
>
>
> 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, <[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!
