On Thu, 7 May 2009 04:10:30 -0700 Mike Hansen <mhan...@gmail.com> wrote:
> > Hello all, > > I've been doing a lot of work recent trying to get the new symbolics > ready for Sage 4.0. With 4.0 due out in 8 days, we're trying to do > the final push. Thank you very much for working on this. I am really amazed to see how you rebased all the pynac patches from William and me to version 1.4.3. > There are currently a lot of printing errors since Pynac/GiNaC prints > expressions differently than Maxima does. Some things still need > doctests, and there are a few small features left to implement. If > you have some free time in the next few days and want to help out, > it'd be greatly appreciated. > > If you want to try the code out, there is an spkg and two patches in > http://sage.math.washington.edu/home/mhansen/symbolics/. These should > install and apply cleanly to Sage 3.4.2. I guess the first patch is a collection of my patches sitting on trac, so I didn't read it. Is this right? Some minor comments after reading the 2nd patch: * does new_Expression_from_GEx() really need the new parent parameter? * how does the new _convert() function relate to the _eval_self() I defined to handle numerical approximations? * in the _factor_list() method, the line "if op is not None:" seems superfluous * in the initialization of SFunction, I had removed the find_function() call, since you don't want to overwrite a previously user created function which might be present in previously created expressions. It seems that your patch adds it back. * I don't think SFunction should have a .serial() method. It is useful for debugging but it shouldn't be exposed to users. * can we not use from sage.all import ... in function.pyx? * why is SR.pi() necessary? * the docstring for SR.var() is confusing, since you use it to create multiple symbolic variables, and return expressions if the argument is already an expression * I don't see immediately why the printing functions are in the parent, and not the elements. I.e., why is printing deferred to SR._repr_element() and SR._latex_element()? As I pointed out earlier on IRC, I don't think it's necessary to patch pynac at all for the constant evaluation. You can just pass in any python object which implements a .numerical_approx() method (the python object for the constant itself?) to the constant constructor. This would also remove the need for a lookup table for numerical approximation of constants. This is the first time I saw the default_variable() function in the previous symbolics code. I suggest that this is deprecated, and the functions that need this require explicitly stating variables. Maybe this discussion should take place in a different thread though, since it's independent of your patch. Thanks again for your time and effort. Cheers, Burcin --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
