> Software programming practices generally agree :-) > > One exception though: It is advisable to move the duplicate code into a > common function or class, and call it from the places where the original > code was ripped out. > Particular care should be taken to make the new deduplicated code so that it > has a nice, as-narrow-as-possible interface. (A "narrow" interface is one > that has a small number of functions, with short parameters lists, and a > small number of preconditions under which a function may be called. The > narrower the better.) The duplication in question is lambdify vs experimental_lambdify (I start to hate the name that I choose :)
lambdify has evolved to be used in several strange ways, but it is important for numerical evaluation. The problem is that it does not work very well. experimental_lambdify works better but lacks some of the features (and bugs) of lambdify. They are both well separated from the rest of the code base. lambdify is not very narrow (quite narrow according to the documentation, not narrow at all in the real and undocumented way in which it is used). experimental_lambdify is very narrow. They are both far from the best solution. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
