Enumerating greedy linear extensions

[jmantysalo]

Add function to iterate over all greedy and supergreedy (also called depth-first-search) linear extensions of a poset.

[jmantysalo]

I would like to add function(s) to iterate over all greedy and super-greedy linear extensions of a poset. What is a reasonable interface? Currently linear_extensions() returns an object of a specific type, but for example tau() of a greedy linear extension is not necessarily greedy.

[jmantysalo]

Code added, interface missing.

---

New commits:

​b93ba19

Add iterator over greedy linear extensions.

[git]

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

​f7e27b8

A correction.

[tscrim]

I would probably subclass the linear extension classes and have P.linear_extensions() take a (super)greedy argument.

[git]

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

​67c9879

Add supergreedy extensions.

[jmantysalo]

Replying to tscrim:

I would probably subclass the linear extension classes and have P.linear_extensions() take a (super)greedy argument.

But what to do for .tau() then?

[jmantysalo]

Meanwhile I mark this as needs_review: this does not affect "interface", i.e. posets.py at all. Interface can be thinked independently.

[tscrim]

Replying to jmantysalo:

Replying to tscrim:

I would probably subclass the linear extension classes and have P.linear_extensions() take a (super)greedy argument.

But what to do for .tau() then?

Have it return something in the general linear extension class (a lá Tableau and its subclasses).

[tscrim]

Replying to jmantysalo:

Meanwhile I mark this as needs_review: this does not affect "interface", i.e. posets.py at all. Interface can be thinked independently.

It is simple enough to change this later on too. While it made me laugh, we should be a bit more professional than i_want_python_3 as a variable name.

[git]

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

​6db34e4

Unfunnying variable name.

[jmantysalo]

Replying to tscrim:

While it made me laugh, we should be a bit more professional than i_want_python_3 as a variable name.

Changed that. (But for example orthocomplementations_iterator has same kind of variable name.)

[tscrim]

Replying to jmantysalo:

Replying to tscrim:

While it made me laugh, we should be a bit more professional than i_want_python_3 as a variable name.

Changed that. (But for example orthocomplementations_iterator has same kind of variable name.)

I don't think I reviewed that. Although that has something worse: raising a StopIteration (at least, IIRC this to be a bad thing and instead you should just return).

Anyways, thank you. Positive review.

[jmantysalo]

Replying to tscrim:

Thanks for review.

Although that has something worse: raising a StopIteration (at least, IIRC this to be a bad thing and instead you should just return).

Can be no yield and return in the same function.

[tscrim]

Replying to jmantysalo:

Replying to tscrim:

Thanks for review.

No problem.

Although that has something worse: raising a StopIteration (at least, IIRC this to be a bad thing and instead you should just return).

Can be no yield and return in the same function.

Void returns are okay, you just cannot return any object. Addendum: For example, see sage.combinat.partitions.RegularPartitions_all.__iter__.

[jmantysalo]

Replying to tscrim:

Can be no yield and return in the same function.

Void returns are okay, you just cannot return any object.

OK, I did not know that. It is at least shorter to write just return, althought I did not find a reference to prefer it instead of raise StopIteration.

[tscrim]

Replying to jmantysalo:

Replying to tscrim:

Can be no yield and return in the same function.

Void returns are okay, you just cannot return any object.

OK, I did not know that. It is at least shorter to write just return, althought I did not find a reference to prefer it instead of raise StopIteration.

It is gone after Python 3.5.2: ​https://www.python.org/dev/peps/pep-0479/

See also: ​https://stackoverflow.com/questions/14183803/what-is-the-difference-between-raise-stopiteration-and-a-return-statement-in-gen