On Sun, Sep 6, 2009 at 10:24 PM, Nils Bruin<[email protected]> wrote: > > On Sep 6, 2:28 am, Juanjo <[email protected]> > wrote: >> On Sep 5, 9:22 pm, Nils Bruin <[email protected]> wrote: >> >> > couldn't convince the C compiler that two mpz_t's were really of the >> > same type) >> >> mpz_t's are not designed to be copied around. > > Well, mpz_t is a pointer to a certain struct. In sage's Integer > wrapper class, one can get a *pointer* to an mpz_t > I tried to do a big_register_get, extract the mpz_t from that and do a > mpz_set with the big_register as a target. > The C compiler kept complaining about incompatible types (I got cython > to believe I knew what I was doing). Anyway, strings work fine for > now. > >> ECL can run several threads, each one with an isolated stack, etc, >> etc. The problem is that Maxima kepps 90% of variables as global >> variables. Hence, to start a clean thread one has to identify them and >> create thread-local bindings for them. It can probably be done >> programatically -- inspecting the nature of symbols -- but this will >> add another layer of complexity to your application which yo do not >> want. At least not until things are more polished. > > As discussed above, we can probably get away with a "maxima symbolic > ring" that caries global state. It's probably not a problem we can > have only one instance at a time. I am interested in your suggestion, > though. In library-mode, the main call we would be making to activate > maxima would be > > cl_funcall(MEVAL,EXPRESSION) > > where MEVAL is a cl_object pointing to the symbol "MEVAL" and > EXPRESSION to the expression that needs evaluation. How would one > specify the proper thread context in that situation? > > ---- > > For other people interested in maxima-as-a-library: I personally don't > have a clue what the right way forward is from here. What > functionality do we need from maxima? Is a minimal functionality > library the right way to go, a la the "myint" example above? Or would > we be served with a fully functional > MaximaSymbolicRing, where one can simply coerce between SR and > MaximaSymbolicRing, whenever one needs functionality available in > Maxima/PyNaC but not in PyNaC/Maxima. I think this project at this > point really needs input from someone familiar with Sage's symbolics. > (I personally don't have a use for them).
You're right. We should make a list of everything Maxima does for our basic symbolic manipulation that would be a lot of work to simply rewrite in PyNaC. Also, I think a Sage Days workshop would be very helpful. I also worked very hard for a while this summer on a C library interface to GAP. Having a Sage Days/working session on C library interfaces to GAP, Maxima, and Singular (?), would be an exciting and cohesive topic. Thoughts? I'm thinking of something in Seattle (or maybe Vancouver), or possibly in between. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
