First of all, a warning: I am not a mathematician, just a computer support
and IT admin interested in strange things.
On Fri, 10 Oct 2014, Anne Schilling wrote:
When Travis and I were working on the bug fix for 14019, we were also
contemplating deprecating HasseDiagram and moving the methods to
FinitePoset
OK, then I'm not only one wondering this.
On Fri, 10 Oct 2014, Nathann Cohen wrote:
- Is it meant to be possible to totally change backend? Not just to hasse
diagram with some other graph backend, but to some bit vector or
matrix-based system or something?
HMmmm... Well for some things it may be much better to have a binary
matrix indeed, for instance when you need to compare a lot of elements
and would like to store the dense version of the adjacency matrix.
Right now it is not possble for all I know. And if what you have in
mind can also be thought of as a graph backend, then perhaps nothing
needs to be changed on the Poset side.
True; also for example there could be "doublehasse", i.e. structure with
both upper and lower covers saved as a list for an element. But let's
suppose that we could have some totally other backend, called foo and not
yet invented, for posets. Then posets.py would be mostly like
def compute_something(self, a, b):
if _hasse_diagram:
_hasse_diagram.compute_something(a, b)
else:
_foo.compute_something(a, b)
def compute_something_else(self, a, b):
if _hasse_diagram:
_hasse_diagram.compute_something(a, b)
else:
raise NotImplemented("Not done yet. Sorry!")
But still, our "foo" might have compute_something_else() formally defined
but so that it just raises a NotImplemented exception.
- It might make sense to have functions for ALL posets, not just finite
ones. Then maybe poset class could have is_lattice defined as
is_meet_semilattice & is_join_semilattice? However, for now there is just
two infinite poset defined.
Well, the current class is called FinitePoset. Some "Poset" class
could do that. I did not know that infinite posets were supported
though.
Actually there is mathematically, for example, class inclusion chain
finite lattices \subset locally finite lattices \subset (all) lattices.
For example upper_covers() can not be defined on general lattice: On
([0,1], \le) element covering 0 should be smallest positive real number.
On divisor lattice of positive integers there is infinite upper covers on
1: all primes; hence on locally finite lattices on might have
upper_covers_iterator() but not upper_covers.
- Hasse diagram is backend to posets and [semi]lattices. Could some function
be used differently, like omitting some checks if we have lattice and not
just poset?
I suppose, but those functions can be implemented in FiniteLattice
already. I believe you did that in a recent patch by the way.
I tried, did not work. Linear extension must be computed, because C code
gave posets with "wrong" order; but it generates posets, so there no need
to check for being acyclic.
--
Jori Mäntysalo
--
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.
