Permutations

[NSoiffer]

From the 25 January meeting: we discussed permutations and permutation cycles. We have the latter. We don't have the two row version of permutations. The group felt that this needed some discussion, hence this issue.

Can the two notations/concepts be unified?

[dginev]

We could always recommend a generic :permutation property which could go on any of the possible notations - which will help to unify but only a tiny amount.

The cycle notation term seems to imply multiple parenthetical groups, but it only covers a single line. Maybe that is a property :permutation-cycle-notation (or just cycle, if it isn't too misleading).

"Cauchy's two line notation" for permutations appears to be a completely separate way of writing (and speaking) a permutation, so I doubt we can unify it from an implementation standpoint. :permutation-two-line-notation would be a sample verbose property name for that.

One could try to vaguely unify by using :permutation in either case, but then AT has to first do a scan and check which notation was used.

[davidcarlisle]

I think we should be quite sparing with properties. concept names have a default behaviour of being read as-is so can help even when the implementation does not know them, but properties by default do nothing. I don't see any need to unify the notations here really, they are mathematically equivalent but arguably not the same representation.

An intent of cycle(1,2,3) for $(1,2,3)$ seems fine to me. the two line notation $ 1&2&3 \ 2&3&1 $ I'd probably want something like intent=permutation(maps-to(1,2),maps-to(2,3),maps-to(3,1))

[NSoiffer]

I agree with David about being sparing with the use of properties for the reasons he mentions. On the other hand, marking up tables is messy, so maybe there is a case to be made that this is "just" another table property that informs AT how to pronounce the table.

This issue makes me think that we probably should write a little text for table properties that says "if the table structure doesn't make sense for the property, ignoring the property may be the appropriate thing to do". In the case of ":permutation" if we decide to add that, then a three or more line table would fall into the "ignore" category.

[dginev]

Well, David's position is to not unify the cases - you'd use cycle in one case and maps-to in the two-line case (carried by the <mtable> ancestor). Which is fine explicit markup. Resolving here with "no action" is OK by me.

---

Also, a detail I had forgotten is that adjacent cycles are multiplied, and spoken as if multiplied: https://youtu.be/UI-SWiyaArE?t=177

So there seems to be no need to introduce anything further in that case.

The rendered (126)(35)(4) has an implied intent times(cycle(1,2,6),cycle(3,5),cycle(4)).

---

I don't like the idea of an "ignore" category for properties on the spec side.

My original suggestion for properties was to reach ARIA parity with e.g. aria-description. An "unknown property" should still be available as a secondary description upon user request. From that perspective, adding a :permutation can always be helpful, even if it is not known to an AT - this is the usual Open realm use.

To me, the difference between the wrappers:

• <mrow intent=":permutation">...</mrow>
• <mrow intent="permutation($1)">...</mrow>

Comes from whether the string "permutation" is preferred spoken always/primary, or sometimes/auxiliary, when not known to AT. When known, implementations MAY choose to use the property as a "hint" as well, but that is likely to be rare.

I agree with David that it is better to be sparing with legislating properties that SHOULD have dedicated implementation work. I currently don't have other ideas how one can unify the cases.

[davidcarlisle]

not necessarily for this permutations use case but the discussion made me want to ask...

mostly the currently specified properties are structural rather than related to specific mathematical meaning infix, prefix, silent... although grey areas like system-of-equations sounds like it refers to meaning but it's more about the layout (and applies to inequalities)

the notable thing about the permutation notation (if you ignore any specific "maps to" reading), is that it's a list of pairs written vertically. So my question is does AT typically have a way to read a table by column rather than by row and would a generic property on an mtable to say read by column make sense?

[dginev]

does AT typically have a way to read a table by column

Prior art here appears a bit messy, and focused on heading elements.

ARIA has role="columnheader" for <th>, while HTML has scope="col" for <th>.

MathML doesn't have table heading elements, and it seems like a pity that the global dir attribute (both in MathML and HTML) is constrained to only deal with left-to-right vs right-to-left, but not top-to-bottom or bottom-to-top.

Table traversal by AT fits better as a new issue I think. Prior discussion was in #337

[NSoiffer]

Answering the AT question: yes, AT users can move around by column (and to the next row entry). I believe "ctrl+arrow" is the standard way to move around a table. MathPlayer/MathCAT uses that.

[dginev]

I was wondering what is the usual academic English for a matrix "read by column", to see if there is a predictable name for a property. I found two variants [1], [2], which could be suggestive property names:

• :column-major-order
  • (possibly shortened to :column-major)
• :column-wise-traversal
  • (possibly shortened to :column-wise)

Similarly to major, the word minor is also in use. So we could also consider :column-minor-order, which appears to be an accepted way to refer to "read by columns, bottom to top".

That is in contrast to "column-wise" which leaves the direction implied and doesn't have a "minor" counterpart.

[davidcarlisle]

column or row major order are the terms almost always used when discussing memory storage layout in computer systems and especially distinguishing Fortran (Column major) and C (Row major). But that is not really related to how the matrix is read (you typically would read a matrix by row even if stored in column major order) it refers to how the 2d array is linearised to store in memory, which doesn't really have any meaning for an abstract mathematical matrix.

So I would say "column-wise" or how I notice I did above "by-column"

[dginev]

almost always used when discussing memory storage

Right, the encyclopedic entry also suggests that is their origin. But an order is not really tied to storage, and the first link also mentioned it in a traversal context:

Two common ways of traversing a matrix are row-major-order and column-major-order.

Also visible from the neat wiki illustration:

---

I made an extra search, and I see "column major order" used for our exact purpose in an accessibility setting (AppKit): https://developer.apple.com/documentation/appkit/nsaccessibility/1535061-accessibilityorderedbyrow

A Boolean value that determines whether the accessibility element’s grid is in row major order or in column major order.

So there is existing precedent for using that term in AT, if that appeared to be a concern.

Curiously, the AT entry also intersects David's suggestion for "by-column", as the flag's actual name is "ordered-by-row", which is the mirror to "ordered-by-column".

[davidcarlisle]

So there is existing precedent for using that term in AT, if that appeared to be a concern.

I'm not surprised and it's not that unreasonable, but AT tools are made by programming types who would have been familiar with those terms. You asked for terminoligy in academic mathematical use. In a previous life I was a professional mathematician working on representations of matrix groups and I'm pretty sure I would not have recognised "column major" as a description during those years.

In everday speech, when describing say the layout of images on a page, you would never call them row or column major order, you would say ordered by row for

1 2
3 4

and ordered by column for

1 3
2 4

"column-major" is a technical term in many areas but isn't normal colloquial english whereas "read by row" would be understood by anyone and might be described of bus timetables or any other tabular data.

intent properties are definitely technical terms and I have no objection to any term used here, we have to define it in any case, but as you were asking for background English usage...

[davidcarlisle]

resolved at 2024-05-16 meeting to add by-column and by-row properties and then close

[NSoiffer]

Added core properties.