Okay, I'm tired of this. As soon as all the current patches are reviewed I will turn all this code into socially acceptable Object-Oriented crap. It will be bad work, bad decisions taken for bad reasons, but this will let me add actual mathematical code to Sage later on while I cannot do this if every single tickets takes days of fights.
You will be glad. There will be a Parent named "OrthogonalArrays", another named "TransversalDesigns", another named "MutuallyOthogonalLatinSquares". There will be Elements, i.e. the actual orthogonal arrays, transversal designs and mutually orthogonal latin squares. They will all inherit the following totally useless (and broken) methods : sage: sage: Element. Element.N Element.category Element.dumps Element.n Element.rename Element.subs Element.base_extend Element.db Element.is_zero Element.numerical_approx Element.reset_name Element.substitute Element.base_ring Element.dump Element.mro Element.parent Element.save Element.version There will also be a parent for all "Orthogonal Arrays of parameters k=?,n=?". It will have a .an_element() method to return an actual design. and a is_nonempty() function to know if it contains anything at all. I don't know yet how to implement the "largest k such that there exists a OA(k,n)" but I am pretty sure that a quite non-obvious OrthogonalArrays(n=4).largest_k() would do the trick. Of course, the actual orthogonal arrays, transversal designs, will need a data structure. It will be immutable and as predicted above it will require useless copies. It will be FANTASTIC. Hundreds if not thousands of lines of code for absolutely NO added feature. Objects creates and deallocated for absolutely no point, possible memory leaks like the "cached method that returns UniqueRepresentation objects" if I can manage it. But it will be socially acceptable. It will be reviewed immediately because it is what everybody accepts without even discussing the design. I can't wait to be socially acceptable. Nathann On 6 June 2014 18:47, Nathann Cohen <nathann.co...@gmail.com> wrote: > > 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.
