Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the downward monotonic cone to the cone catalogue #37802

Merged
merged 8 commits into from
May 2, 2024

Conversation

orlitzky
Copy link
Contributor

This an an old PR that I never migrated from trac. We have a catalogue of convex cones accessible through cones.foo(), and this PR adds the downward monotonic cone to the catalogue. It will also close #30200.

Add the paper "Group majorization and Schur type inequalities" by
Marek Niezgoda to src/doc/en/reference/references/index.rst, which
contains the global reference list. This paper mentions several
convex cones in the context of group majorization, and can be used
as a reference for some things in the cone catalogue.

Here's a BibTeX entry for good measure:

  @Article{
    niez1998,
    author = "Marek Niezgoda",
    title = "Group majorization and {S}chur type inequalities",
    journal = "Linear Algebra and its Applications",
    volume = 268,
    number = 1,
    year = 1998,
    pages = "9--30",
    doi = "10.1016/S0024-3795(97)89322-6"
  }
The downward-monotonic cone is the dual of the Schur cone that one
can obtain by running

  sage: cones.schur(n)

It is used in convex optimization, and is nice to have available
independent of the Schur cone, because cones.schur_cone(n).dual()
not only gives you back a cone that lives in the dual lattice of
the Schur cone, but is slower than constructing the downward-
monotonic cone directly. The new cone is available as

  sage: cones.downward_monotonic(n)

in the cone catalogue.
I have used the phrase "majorization order" in the cone catalogue in a
few places. It is however only a preorder, and not a partial order, so
the first order of business is to change that phrase.

There was also one test case that used a majorized_by() function whose
implementation was incorrect. No harm was caused by this, but as a
personal rule I prefer it if a function called majorized_by() actually
implements the majorization order. This commit fixes that as well, by
rearranging the arguments' elements in nonincreasing order, so that
the function truly tests whether or not one argument majorizes the
other.
Copy link

github-actions bot commented Apr 15, 2024

Documentation preview for this PR (built with commit fa21c28; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

Copy link
Contributor

@mkoeppe mkoeppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise LGTM

Thanks to Matthias Koeppe for the suggestion.
...and rewrap the docstrings afterwards. Thanks to Matthias Koeppe for
the suggestion.
For example,

  (x,y) = foo

becomes

  x,y = foo

Thanks to Matthias Koeppe for the suggestion.
@orlitzky
Copy link
Contributor Author

Done, thanks.

@mkoeppe
Copy link
Contributor

mkoeppe commented Apr 16, 2024

Now I remember that we had a discussion about terminology back then that was not finished. I'll withdraw my suggestion to consider renaming it cones.nonincreasing_sequences; but note:

So I think it should be renamed as cones.monotone and/or cones.downward_monotone

…otone

Rename this cone. "Monotone" is more popular than "monotonic", but
once you include the upward- or downward- prefix, "monotonic" begins
to win. I like the bike shed just the way it is, but the color isn't
important enough to me to leave the bike outside for another four
years while we ponder it.
@orlitzky
Copy link
Contributor Author

So I think it should be renamed as cones.monotone and/or cones.downward_monotone

OK you win. Bare "monotone" is ambiguous (the upwards monotonic cone is also used), and switching from "downward monotonic" to "downward monotone" drops the number of google hits from ~10 to zero. But it's not worth keeping this PR open for another four years.

@mkoeppe
Copy link
Contributor

mkoeppe commented Apr 17, 2024

Thanks. "Monotone cone" by itself is clearly a fixed, well-understood term in a (pretty large ...) community; but for purposes of Sage, adding "downward" in front does add useful extra clarity.

vbraun pushed a commit to vbraun/sage that referenced this pull request Apr 28, 2024
    
This an an old PR that I never migrated from trac. We have a catalogue
of convex cones accessible through `cones.foo()`, and this PR adds the
downward monotonic cone to the catalogue. It will also close
sagemath#30200.
    
URL: sagemath#37802
Reported by: Michael Orlitzky
Reviewer(s): Matthias Köppe
@vbraun vbraun merged commit 68e657c into sagemath:develop May 2, 2024
13 checks passed
@mkoeppe mkoeppe added this to the sage-10.4 milestone May 2, 2024
@orlitzky orlitzky deleted the downward-monotonic branch July 14, 2024 10:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add the downward monotonic cone to the cone catalogue
3 participants