Jori Mäntysalo writes:
>
> I understood. But when do user have an object of class lattice and he or
> she wants to check that it is a lattice?
This could easily happen in a function that accepts any poset but can do
clever stuff when the input happens to be a lattice.
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?).
Thus ProductPoset.is_lattice should be overrriden and look something like
def is_lattice(self):
if self.left_poset().is_lattice() and self.right_poset().is_lattice():
return True
else:
#More complicated logic perhaps
>> Some of the unnecessary re-computation might be alleviated by using
>> @cached_method on strategic methods, such as join_matrix() and
>> meet_matrix(). You should strive for a design that is easy, comfortable
>> and efficient to use, for experts and novices alike. Don't rely on
>> strange things like unsetting private variables in order to get decent
>> performance.
>
> Yes, but should it be cached when creating a lattice or when first used?
> (Of course the whole question arises because check for a poset to be a
> lattice is done by computing meet- and join-matrix. I don't know if there
> is some easier way for it.)
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.
> Then there should be implementation for AntichainPoset, BooleanLattice
> etc. I guess that properties for those are already known, so they are not
> used in "real life" other than testing algorithm, showing something to
> students etc.
My "derived constructions" example above with ProductPoset is, I
believe, a reasonable example of why you would want "trivial"
constructions to have high performance on known properties.
But teaching and testing is not bad reasons either. It makes you able to
test on big, albeit simple, examples. And it's sort of embarrassing if
Sage has terrible performance on clearly trivial examples because it
uses squared, cubic or worse algorithms to compute something everyone
can do in their head.
We have the exact same issues in coding theory :-)
> Do Sage has "normal users"? Is somebody making goat cheese, and using Sage
> to compute how many goats are needed for a given amount of cheese?
I don't know about goats, but definitely cows.
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.
Johan
--
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.
