For anyone involved in findstat, there are several layers of complexity. This is my assessment from outside the findstat collaboration: - they also deal with Mathematica code - they also deal with user-generated information that is not code - they also develop some of the code and would thus 1) prefer to maintain one rather than two separate objects (code and database) 2) like to easily and flexibly be able to develop the code as they intend to use it (i.e. equipped with everything, cf. monkey patching) - some of the information they want is added/could easily be added by others in sage code - just like the LMFDB, the database term is a misnomer. They want their thing to be data and code. The code is partly their data, either directly (class dependencies) or indirectly (the code is run to produce the data).
Paul Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 12:13 AM, Simon King <simon.k...@uni-jena.de> wrote: > Hi Viviane, > > On 2014-05-27, Viviane Pons <vivianep...@gmail.com> wrote: > > The way it works: the decorator replaces the tagged methods by instances > of > > combinatorial map class, the functions only checks which methods are > indeed > > instances of this class. > > And, if I understand correctly, it is this kind of things that makes > Nathann ask for removal of the decorator. > > What you *want* to do is create a database that handles requests of the > type "what combinatorial maps are provided by a class C?", or perhaps even > better "what combinatorial maps are provided by a sub-category S of > Sets().Finite()?". This could very well be a (SQLAlchemy?) database that is > stored somewhere, perhaps even in a remote location. > > But what you *do* is to encode this database via the *type* of methods. > The information is not put into an external database, but the > information is stored *implicitly* by changing Sage code. > > I agree with Nathann: This is intrusive! And when your decorator > replaces methods by "instances of some class" then certainly the > overhead of calling these methods will increase. Applying your decorator > to a frequently (recursively?) used method may result in a slow-down, as > it seems. > > Even when trying to take your perspective, I still don't understand why > you might want the decorator to work in that way. > Certainly a proper database (relying on a dedicated database engine) is > faster and easier to search and thus more useful for you than an ad-hoc > function that ultimately relies on listing attributes and determining > their types. > > So, what is the rationale for *not* using a database for your database of > combinatorial maps? > > > It is partly the information you need even so I'm not sure it's a good > way > > to have it. > > I see no reason how this could be a good way to have it. > > > And also, this function is hidden somewhere and not accessible > > from the object or the parent itself. > > "Hidden somewhere" is bad for a user interface. > > > About Nathan's suggestion to have a flag, I don't know if it's such a > good > > idea. The idea is to provide this semantic information to any user of > Sage > > not machines. > > It seems to me that you are argueing *against* the current decorator. > Calling a function that is hidden somewhere and relies on introspection > (listing attributes, type check) is for machines. A user of Sage should > have a database with a proper interface. > > > The way I see this, *because* of the FindStat use case, the > > combinatorial_map decorator has been introduced and many Sage developers > > have been devoted time into adding semantic information into sage > methods. > > Of course, we could remove this all together, but this would be a great > > loss for Sage as this semantic information is useful for users. And > Here, I > > speak as a combinatorist person working with these objects every day. > > > > So, our concern should be: how to make this information easily available > to > > users and how could we store this without impacting efficiency of the > > program. > > Do not store information by a decorator that changes code. Migrate it to > a proper database, that may be stored in SAGE_SHARE. The decorator > should write information into the database (or perhaps even pull > information from it?) and, when done, simply return the unaltered > method. In that way, it would not be intrusive, and the database would > provide a not-so-hidden single point of entry. > > Best regards, > Simon > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-de...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
