BoundsError thrown by weight(hook_lengths(partition([4,2,1])))

[fingolfin]

julia> H = hook_lengths(partition([4,2,1]))
+---+---+---+---+
| 6 | 4 | 2 | 1 |
+---+---+---+---+
| 3 | 1 |
+---+---+
| 1 |
+---+

julia> weight(H)  # gives  BoundsError
ERROR: BoundsError: attempt to access 1-element Vector{Int64} at index [6]

A quick look at the code suggests that it requires that the tableau be semistandard, but does not check this! Either we modify the code so that it checks, or we modify it so that all Young tableaux are accepted. I do also wonder whether the name should be changed to weight_sequence. I have searched quickly on internet: given a YT the weight is a sequence; it may assume that the entries in the YT are positive (or maybe just non-negative).

Originally posted by @JohnAAbbott in #3850 (comment)

[fingolfin]

The code in weight(tab::YoungTableau) indeed assumes that the given tableau is semi-standard, i.e., the entries are weakly increasing in each row; but here they are decreasing.

It would be easy to fix weight to deal with this case, but I wonder if this is the way to go. Perhaps @ulthiel has a comment on this?

[JohnAAbbott]

To get a more helpful error message, the code should check that the input is semi-standard, and produce a comprehensible message if not: e.g. Tableau must be (semi-)standard

[JohnAAbbott]

Regarding @fingolfin comment about the name. Oscar tends to use long names (with several exceptions). While the name weight is apparently used in literature focussed on combinatorics, for the benefit of people not so familiar with that small sphere, I think it would be more helpful to use the longer name weight_sequence (e.g. if the person needs to search for this phrase...)

[fingolfin]

@JohnAAbbott can you please open a PR that let's it throw an error if the tableau is not standard? If someone needs the function more generally they can request it.

[JohnAAbbott]

I'm almost ready to make a PR. One question: what name should the function have weight or weight_sequence?

[JohnAAbbott]

My opinion: I believe that the name weight_sequence is significantly better than just weight. A brief search on the internet did not result in any conclusive function notation for the weight sequence of a YT. Changing the name is not backward compatible, but at the moment that probably affects no-one.

[JohnAAbbott]

I do note that the word weight is also used in several other contexts in Oscar, whereas weight_sequence is not used anywhere outside my modified branch.

[lgoettgens]

My opinion: I believe that the name weight_sequence is significantly better than just weight. A brief search on the internet did not result in any conclusive function notation for the weight sequence of a YT. Changing the name is not backward compatible, but at the moment that probably affects no-one.

We could (and IMO should) add a deprecation to the old name in case that you do a rename. (This is possible to do for only some dispatches)

[thofma]

The method exists, is exported and documented. So removing it or deprecating it both require 2.0?

[lgoettgens]

The method exists, is exported and documented. So removing it or deprecating it both require 2.0?

No, deprecating just requires a minor bump (so 1.3). Removing I agree with 2.0.

[joschmitt]

I feel like the discussion about the name is moot as long as no-one who would actually use the function is voicing an opinion. For now, I would leave the name as it is (possibly with an alias for another variant) and hope that the original contributor chose it well. With this hope, I am against deprecating anything unless we are really sure about it.
But again, all of this is moot because I do not expect that I will ever use this function.