> This is something fixable. We deal with this in plotting and symbolics all > the time. Naming things twice (esp. since orthogonal_array isn't in the > global namespace, just designs.[tab]) seems very reasonable to me. > > designs.orthogonal_array_maximum_size > designs.orthogonal_array_existence
Okay let's be reasonable. The functions I would need are : designs.orthogonal_array_maximum_size # note that the terminology is not right designs.orthogonal_array_existence designs.orthogonal_array designs.transversal_design_maximum_size # same comment designs.transversal_design_existence designs.transversal_design designs.mutually_orthogonal_latin_squares_maximum_size # same comment designs.mutually_orthogonal_existence designs.mutually_orthogonal Of course, I would also needs 3 hidden function that would be called by the others _orthogonal_array_all_at_once _transversal_design_all_at_once _mutually_orthogonal_latin_squares_all_at_once 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. > Usually, in Sage, we have kept to a convention that such keywords do things > like try other algorithms or verify truth (as indeed in orthogonal_array in > Sage 6.2, where I though I saw a check keyword of some kind). Naturally, > Python can do this, but it is helpful to keep things 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. > Shell isn't Python. In fact, you are losing the point of > object-orientedness. Again, I'm sure Sage also does this in some places, > but over time it would be good to minimize those places. I think, on the other hand, that people are so used to object-oriented programming that they do not see when it is not a good idea anymore. 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. If these objects are made immutable, I will NEED to copy them again and again and again in all recursive constructions instead of changing them. Those are all the changes that are triggered if I have to use those cursed objects where they don't belong. > Anyway, since all this new stuff is still in beta, is there a possibility of > refactoring this and making a few methods? I have a lot of modification to do on these files, a lot of nice stuff to add, but there are currently 9 patches in needs_review in the combinatorial_designs section. I cannot add code not improve anything unless the patches end up being reviewed. > (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. > I really really really really (!) understand that it would be a very > annoying piece of work to do so. 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. > And I know it is, if not orthogonal, at > least tangential to the question of cache functions. But it would be so so > so good for Sage in the long term. I know I am no expert software engineer > and make lots of dumb design choices, and of course much of the combinat > code is largely not going to be used by me or my students or people I teach > Sage... Please don't consider sage/combinat/designs/ as part of the combinat/ code :-P > but on the other hand if we have the chance to tighten things up, it > seems reasonable to take the opportunity. I have been walking in circles for days or weeks because the patches are waiting for a review. I cannot write code for as long as there is stuff still left to be reviwed. Nathann -- 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.
