On Sun, 14 Jun 2015, Johan S. R. Nielsen wrote:
Say I have a ProductPoset class which takes two posets and returns a poset representing the cartesian product (is this already in Sage?). I might very well in "real life" research use this construction with both sides being lattices, in which case the product is a lattice (right?).
This is already done. However, it is NOT beatiful implementation: posets.py contains the whole function, and it checks types and returns (semi)lattice accordingly. Same applies to for example ordinal_sum() or relabel().
I imagine something like the following: At lattice creation time you *usually* want to check to see that the input *is* a lattice. So e.g. __init__() would call self.join_matrix(), which would compute and cache the result for later use (automatically, done by @cached_method). If the check had been deactivated by the user or calling code, then the user's first call to self.join_matrix() would compute the matrix.
Sounds reasonable. So you also think that normally we should use a little more RAM to save some CPU time.
Should there be "create_lattice(...)" that calls "_create_lattice(..., check_input=True)"? Then internal functions could call _create_lattice(..., check_input=False). Of course we already have things with __init and so on --- so somebody with more knowledge about Python should say how to do this.
Anyway. I don't think that the basic needs from a computer algebra system of a math enthusiast/student/researcher/farmer are that different. All of them needs the trivial, basic things to be fast and with lots of services such that they can be played around with, build upon, and extended.
Hmmm... Researcher is, by definition, going to the limits and over. So it is different to some degree. But true, in both case basic things should be fast.
-- Jori Mäntysalo
