2009/5/22 Gonzalo Tornaria <torna...@math.utexas.edu>: > > On Thu, May 21, 2009 at 5:27 PM, John Cremona <john.crem...@gmail.com> wrote: >> However sometimes I have felt that "algorithm" did not quite capture >> the distinction being made for some function. I have written >> functions in Sage which have an algorithm parameter which can be >> either "pari" or "sage", where the underlying algorithm is in fact the >> same, but we are choosing to use one implementation of it instead of >> another. I could try arguing for the use of "implementation" as the >> name of the parameter... but "algorithm" will do fine. > > +1 on both "implementation" seems a bit better, but "algorithm" is ok. > > Sometimes I wish there was a standard/uniform way to code the frontend > for a multiple-implementation function in such a way that > > (a) introspection knows about it, so e.g. "function??" shows the > actual code for the default implementation, and it's also easy to get > the actual code for the other implementations.
This can be done if the implementation are in different sub-functions (maybe with underscore prefixes, and suffixes equal to "_" + "algorithm"). > > (b) doctesting can be improved based on that (e.g. doctests are run > with algorithm="all", without need to repeat). Not all functions with algorithm parameters allow "all" and do a comparison. Should they? (Omitting those which require optional packages, of course). > > (c) a generic tuning/benchmaketing framework could be implemented > feeding back the tuning to the frontend. > > (d) in case there is a better implementation which depends on optional > packages or tables, it becomes default when the required optional > package is installed. That happens to some extent already -- e.g. if you ask for the generators of an elliptic curve in my database, it does a look-up if the database is installed and otherwise computes them. This is probably left to be handled case-by-case. John > > Just my 2 cents.. > > Gonzalo > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
