> > Note that I would also need to triple MANY functions in the graph code, > for the very reason that you insist on writing Python code as if it were C > code. > > Interesting, there are things like that in the optimization-based graph code too?
> I have been doing this in the Graph code for years. And I think that I > remember how it began : > > It was the early days of Linear Programming. I was writing functions to > solve NP hard stuff, returning partitions of vertices or list of vertices, > and though that perhaps I could save this with a "value_only" flag. When a > graph function has such a flag, it means that it will not return the actual > list of vertices, but its size instead. > > This, because in the optimization world, we deal with existence problems. > And existence problems have what is called a "certificate", ie "some > information which can be used to check, in polynomial time, that the answer > given to the decision problem is right". > > Thus in the graph code you will have functions with a "certificate" flag, > others with a "value_only" flag. And their output changes according to that. > > Python is *NOT* typed. Accept it. > > I am very glad Python is dynamically typed! For me, it has nothing to do with type, and everything to do with not confusing end users. Especially because it seems (but I may have misunderstood some comments in the vast trove of emails and tickets) that one could get different output types without the use of special 'certificate' keywords. I don't want to have to create objects that will be only used to access > methods. > If I create those objects, I will need to write a OrthogonalArray class, a > TransversalDesign class, and these objects (which, currently, are lists of > lists) will HAVE to be immutable. > Actually, I was kind of surprised that they were just lists of lists when I was looking at the code. Surely one wants more structure than that, or don't they have more structure? This is exactly the kind of thing we are just talking about with the game theory code - we want a class because you want to *do* something with it. Tab-completion rules! But I suppose it's possible that all these designs really are just lists of lists. Those are all the changes that are triggered if I have to use those cursed > objects where they don't belong. > > I guess I don't know why they have to be immutable since not every class is immutable (is it?) but I will trust you on this. > (And ones that also don't use > > "who_asked", a purely internal thing - that should be some internal > > attribute, not a keyword.) > > This keyword is used to break infinite recursions. If you see a way around > I am interested. > > So there isn't some attribute it can set, like self._who_asked, to check this, with the same purpose? Again, just asking, maybe the only way to break them is a keyword. But it does look quite awkward; such things really shouldn't be exposed in the API. > I don't mind the work if it makes sense. But having to pick a worse data > structure and having to generate useless objects just because you cannot > stand a syntax that the language allows really is bad work. > > I don't know that I can't stand it, but just that Sage has typically not done this, so as to have an easier-to-parse API. Certainly there are always exceptions, since we also (as you say) want to release stuff. > Please don't consider sage/combinat/designs/ as part of the combinat/ code > :-P > > I just went by directory structure :) > It is still largely possible to refactor the code, especially the > functions that are available from the global namespace. And it can be > done easily as it is just about modifying "design_catalog.py" which is > rather independent from the coming tickets. > For the internals, many constructions in combinatorial designs are > recursive and complicated. So separating the existence from > construction means do an exact copy of the code. The boolean answer is > just intended to cut the actual construction (the object are rather > big). So we can not live with two functions. On the other hand, this > function can be hidden from the global namespace. I guess I'm just surprised you need two functions; why can't you have one (underscore?) function that both of them call? That is what was surprising to me, if it really is an *exact* copy of the code? > For the external, as Nathann already said, multiplying the namespace with > designs.orthogonal_array(k, n) > designs.orthogonal_array_existence(k, n) > designs.orthogonal_array_maximum_size(n) > looks ugly to me as there are many combinatorial designs on which you > would have the same. It might also be gathered with no cost as > designs.orthogonal_array.SOMETHING > Perhaps better, I am not sure. Maybe. I guess I see an awful lot of such extra namespace stuff in many other parts of Sage, so it doesn't frighten me :) > But it will be socially acceptable. It will be reviewed immediately because it is what everybody accepts without even discussing the design. Let me put it this way. There is a lot of stuff I wrote five years ago for a paper that just finally got published (or will in September). It all looks just like this - very convenient, avoided lots of repetition, returns lists of lists (truly!), etc. And I know it isn't ready to include in Sage for that very reason. A thought experiment - what is the mission statement? I guess if similar functionality in other software also returns multiple types of things depending on keywords, then maybe that's just how it has to be. As I hope is clear, I don't really care if this is what happens, personally; but I really don't want somebody coming back ten years from now and complaining about the design now that Sage is a mature project. I can think of several places where very early decisions were made, to get something off the ground, that still are annoying today for end users; that is okay, because having Sage is way better than not having it :) but we are in a different place now where we can afford to at least think about this. > I can't wait to be socially acceptable. At least for me, it's not about that, though I understand why you feel that way. And I'm certainly not suggesting you have to inherit from Element, which I don't understand anyway! Thanks both Nathann and Vincent for explaining some of the more technical details. -- 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.
