Add certificate to is_relatively_complemented()

[jm58660]

At #20940 Kevin Dilks suggested a certificate-option, which I did. For consistency I guess that other functions should have the same option too. This patch adds it to is_relatively_complemented().

CC: @kevindilks

Component: combinatorics

Author: Jori Mäntysalo

Branch/Commit: 1213a37

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/20972

[jm58660]

Branch: u/jmantysalo/rel_complemented_cert

[jm58660]

Commit: dcbdf00

[jm58660]

New commits:

dcbdf00

Add certificate to is_relatively_complemented().

[tscrim]

comment:3

I think the INPUT: block should just say:

- ``certificate`` -- (default: ``False``) whether to return a certificate if
  ``self`` is not relatively complemented

and then put the description of the certificate/output in an OUTPUT: block. Similar for #20940.

[jm58660]

comment:4

Replying to @tscrim:

I think the INPUT: block should just say:

- ``certificate`` -- (default: ``False``) whether to return a certificate if
  ``self`` is not relatively complemented

and then put the description of the certificate/output in an OUTPUT: block. Similar for #20940.

Can be done, of course, but I guess that then at least is_dismantlable() should be changed too. What about breadth() of a lattice? See also is_chordal() and is_circulant() in generic graphs.

Is it possible to accept this and #20940, and then later change docstrings for those? Also we should think if certify at canonical_label() of graphs should be changed to certificate.

[tscrim]

comment:5

I think it is better to do this to new functionality in those tickets and then change the other docstrings in a separate ticket. This keeps changes local to the ticket, as well as we don't introduce something that is worse and we are just going to change one moment latter. This has a slight disadvantage of making the doc be less consistent, but Sage is not known for its doc consistency ;). (Yes, I know that is somewhat of a double standard, but the locality of change is the differentiating factor.)

Although my opinion on this is not very strong. If you think doc consistency is more important than doc correctness (or at least separation of concerns within the doc), then we can leave it alone.

[sagetrac-git]

Changed commit from dcbdf00 to f8aca83

[sagetrac-git]

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

f8aca83

Restructure input-output blocks.

[jm58660]

comment:7

Do you mean something like this?

Replying to @tscrim:

I think it is better to do this to new functionality in those tickets and then change the other docstrings in a separate ticket. - - Sage is not known for its doc consistency ;). - -

Whatever. In any case we will need documentation polishing tickets sometimes, as functions will have diverse format for same things.

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:8

I would prefer if it is one bullet point, but that's only because I would use separate bullet points for different parts when the output is a tuple. Also, that is so stylistic and minor that I'll leave that decision to you.

[sagetrac-git]

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

1213a37

Output block format.

[sagetrac-git]

Changed commit from f8aca83 to 1213a37

[jm58660]

comment:10

Replying to @tscrim:

I would prefer if it is one bullet point, but that's only because I would use separate bullet points for different parts when the output is a tuple.

I am not sure what you mean. Something like this?

[tscrim]

comment:11

Yep, exactly. Thanks.

[vbraun]

Changed branch from u/jmantysalo/rel_complemented_cert to 1213a37