LatticePoset: add is_sectionally_complemented()

[jmantysalo]

This patch will add a function that checks if the lattice is sectionally complemented or not.

[jmantysalo]

New commits:

​18e864d

Add is_sectionally_complemented().

[kdilks]

Would it be of any value to have an optional certificate parameter which would return the poset element whose principal order ideal isn't complemented instead of just False?

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​23c3ee3

Add certificate-option.

[jmantysalo]

Replying to kdilks:

Would it be of any value to have an optional certificate parameter which would return the poset element whose principal order ideal isn't complemented instead of just False?

As you wish.

But now for orthogonality we should add certificates to other functions too. Which is not a bad idea at all, at least for demonstration purposes (really show the pentagon for non-modular lattice etc.). I could start with complements(), but then someone should first review #20727 that corrects a trivial bug.

[jmantysalo]

See also #20972. Hope that certificate-options do something similar and expectable.

[jmantysalo]

See comment about certificate and INPUT-OUTPUT -sections at #20972.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8f1c669

Reformatted input-output -blocks.

[jmantysalo]

Travis, I reformatted the input-output -blocks like in #20972 (btw, thanks for review).

But should the certificate be one object, i.e. a tuple of two elements? It seems kind of unnecessary, but then it would be consistent with certificate of is_relatively_complemented().

[tscrim]

Replying to jmantysalo:

Travis, I reformatted the input-output -blocks like in #20972 (btw, thanks for review).

Doc LGTM.

But should the certificate be one object, i.e. a tuple of two elements? It seems kind of unnecessary, but then it would be consistent with certificate of is_relatively_complemented().

I would have the certificate be one object. It couples the output together and allows the user to have a more standard API of result, cert = P.certificate_returning_method().

Kevin, do you have the rest of the review?

[kdilks]

Yeah, I should be able to get this reviewed today.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​abfcae8

Make certificate a one object.

[jmantysalo]

Replying to tscrim:

I would have the certificate be one object. It couples the output together and allows the user to have a more standard API of result, cert = P.certificate_returning_method().

OK, done that.

Warning to reviewer: last patch is blind-coded as I work in a very slow machine now.

(After all these *complememt*-function we should think about SEEALSO-blocks. But for now we have at least #20817 still in queue.)

[kdilks]

I guess I misunderstood what was being said about the certificate being a tuple. My presumption was that the function would always return True if true, but would either return False or a tuple with all possibly relevant data if false depending on certificate. Isn't that how other certificates in Sage work?

[jmantysalo]

Replying to kdilks:

I guess I misunderstood what was being said about the certificate being a tuple. My presumption was that the function would always return True if true, but would either return False or a tuple with all possibly relevant data if false depending on certificate. Isn't that how other certificates in Sage work?

It depends. Certificate for the dimension of a poset is a list of linear extensions and for breadth of a lattice a list of elements.

For is_dismantlable there is both positive and negative certificate: a dismantling order or a crown subposet.

But I think there are also functions so that they always return a tuple whose first element is a Boolean value.

[kdilks]

If it's not particular consistent/canonical, then I'm ok with it the way it is.

Under OUTPUT, I think the two possibilities for certificate should be separate bullet points, and the default possibility (certificate=False) should be listed first.

I also don't especially like the usage of e and e_ as variable names, but don't really have a justifiable reason to make you change it.

Otherwise, it looks good.

[tscrim]

Replying to kdilks:

Under OUTPUT, I think the two possibilities for certificate should be separate bullet points, and the default possibility (certificate=False) should be listed first.

I disagree. It makes it seems as if there are multiple things in the output (see comment 8 of #20972).

I also don't especially like the usage of e and e_ as variable names, but don't really have a justifiable reason to make you change it.

I don't like the e and e_ either. The first is fine, but the other makes it seem much more correlated with e and is somewhat strange to read. I'd use ep (for e' or e-prime) or f.

[jmantysalo]

Replying to kdilks:

If it's not particular consistent/canonical, then I'm ok with it the way it is.

Or maybe we are now making the standard. Sometimes there might exists a "yes"-certificate, sometimes "no"-certificate, and sometimes both. Hence we can not have strictly unified interface. Always returning a tuple with Boolean value in first position is most close we can do.

Under OUTPUT, I think the two possibilities for certificate should be separate bullet points, and the default possibility (certificate=False) should be listed first.

Arghs. Whatever, as long as it is consistent.

I also don't especially like the usage of e and e_ as variable names, but don't really have a justifiable reason to make you change it.

I can change those.

[jmantysalo]

And about more complicated certificates... See #21002.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2602612

Variable name from e_ to f.

[kdilks]

If they can't be separate bullet points, can we at least have the default/simpler/more commonly used option listed first?

It might be a bit more direct to simply combine the information about input and output into the INPUT the way dimension() does

  INPUT:

   * "certificate" (boolean; default:"False") -- whether to return
     an integer (the dimension) or a certificate, i.e. a smallest set
     of linear extensions.

---

New commits:

​2602612

Variable name from e_ to f.

[jmantysalo]

Travis doesn't like it, but I still think that we should close this one and later open a ticket for just to unify docstrings. Maybe after discussion in sage-devel.

[tscrim]

The description of the certificate is not part of the input, it is the output, so I don't think we should include it in the input. For simple things, this might be okay, but I prefer the separation of concerns. However, I'm not opposed to having the True case first.

[kdilks]

Do you mean having the default certificate=False case first? I'll settle for just that being changed.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​b198cee

Minor doc change.

[jmantysalo]

Replying to kdilks:

Do you mean having the default certificate=False case first? I'll settle for just that being changed.

Now they are in different order in this and is_relatively_complemented. But OK for me...

Some day after poset documentation polishing I'll run the same for lattices.