On Mar 30, 2010, at 12:04 PM, Brian Granger wrote: >> N() is equivalent to .evalf(). > > I propose renaming .evalf() -> .N(). > >> Also, Chris is refactoring the expand_* functions so that you can just do >> expand(expr, mul=True) instead of expand_mul(expr). > > Great! That takes care of the expand_foo methods (let's remove them). > > I think it's one of his 1766 branches at smichr at github. I think > .fdiff() not used very often by the user. .extract_multiplicatively() > is mainly used for algorithms where you don't know what you are > working with ahead of time (otherwise, you can just do regular > division). > > OK, so maybe these two are not important enough to have as global functions. > >> I'm not sure if *all* of these should be methods, but I agree that the most >> common ones should. I think that .subs() should be a function too, and >> .l/nseries should be functions, or at least keyword arguments to series(). > > What about doit? > >> By the way, it is easy to see what there is in isympy with ipython using the >> tab completion, so if your students don't see it in the namespace as a >> function, then it is a method, or visa-versa. Do you plan on using it >> mainly interactively, or through scripts? > > IPython, what's that? ;-) Yes, students would have tab completion at > their finger tips, but doing sympy.[TAB] pull up way too many results > to be really useful to a truly new user. > > So maybe your students would benefit from some kind of cheat sheet, as suggested in issue 1817.
Aaron Meurer > Cheers, > > Brian > >> Aaron Meurer >> On Mar 29, 2010, at 8:50 PM, Brian Granger wrote: >> >>> Hi, >>> >>> I have gone through sympy and made a list of the functions and methods >>> (of Basic) that are essential "action verbs", like "expand", >>> "simplify", etc. I plan on using sympy with students and for this >>> purpose, I need to have a super clean user interface. My students and >>> I will go crazy if I have to continually answer the "is * a method or >>> function" question. In this email I am only focusing on the user >>> interface (how users call things) NOT on the implementation. >>> Implementation is an entirely different issue. >>> >>> I have divided the list into 3 categories: >>> >>> 1. The action verb appears as both a global function AND a method of Basic. >>> 2. The action verb appears only as a global function. >>> 3. The action verb appears only as a method of Basic. >>> >>> * I have focused on action verbs that deal with a single expression, >>> so things like sum and product are not included. >>> * I probably have missed some of the more obscure ones. >>> >>> Here is the data: >>> >>> Both global function and Basic method >>> ===================================== >>> >>> evalf >>> series >>> diff >>> integrate >>> limit >>> expand >>> rewrite >>> conjugate >>> >>> Only global function >>> ==================== >>> >>> simplify >>> nsimplify >>> *simp >>> refine >>> cancel >>> invert >>> expand_* >>> apart >>> collect >>> separate >>> together >>> factor >>> >>> Only Basic method >>> ================= >>> >>> subs >>> doit >>> n >>> nseries >>> lseries >>> fdiff >>> extract_multiplicatively >>> >>> This data below suggest that the "action verbs" in sympy are not >>> treated in a consistent manner - in fact, to the untrained eye, it >>> looks like we flip a coin (OK, maybe a 3 sided coin) to determine >>> where we put these action verbs. I would love to help make a decision >>> on how to handle these action verbs in a uniform manner across sympy. >>> If we can reach a decision, I am willing to help implement the >>> decision AND document it clearly throughout the sympy sphinx docs. >>> >>> Here are the options that I see: >>> >>> A. Make all action verbs functions, never methods (the global >>> functions could still call _private implementation methods). >>> B. Make all action verbs methods, never functions (those methods >>> could still call a global but _private implementation function). >>> C. Make all action verbs both function and methods. >>> >>> What do people think? >>> >>> Cheers, >>> >>> Brian >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to sy...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> sympy+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sy...@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
