Finite Family: sort dictionary keys in repr

[embray]

Although the order of indices is not necessarily meaningful, it often makes for nicer, more human-meaningful output to sort them. For example:

sage: A = Algebras(QQ).WithBasis().Filtered().example()
sage: grA = A.graded_algebra()
sage: grA.algebra_generators()
Finite family {'x': bar(U['x']), 'y': bar(U['y']), 'z': bar(U['z'])

instead of the more seemingly arbitrary

Finite family {'y': bar(U['y']), 'x': bar(U['x']), 'z': bar(U['z'])

which of course is itself a result that is not in any way guaranteed.

In addition to being more user-friendly, this change will also help a lot with tests that otherwise fail on Python 3 due to arbitrary differences in dict key ordering.

Component: misc

Author: Erik Bray

Branch/Commit: u/embray/sets/sort-finite-family-repr @ 4573574

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

[sagetrac-git]

Commit: cf4855e

[sagetrac-git]

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

05b00ee	Fix the FiniteFamily repr to sort its defining dictionary.
cf4855e	Tests whose expected output needs to be updated now that FiniteFamily's

[tscrim]

comment:4

I had meant to respond to this earlier, but it fell off my radar.

I think that FiniteFamily should print out following self._keys if that is not None (which also dictates iteration order) and then fallback to the sorted output (see the values method).

[embray]

comment:5

I see, that makes sense.

[embray]

comment:6

Ah, I knew I already did this, and forgot it still needed work :)
I was just about to do it again...

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

5cea4bb	Fix the FiniteFamily repr to sort its defining dictionary.
87c7339	Tests whose expected output needs to be updated now that FiniteFamily's
86aaf43	Change the repr formatting to ensure that if the keys argment was given,

[sagetrac-git]

Changed commit from cf4855e to 86aaf43

[embray]

comment:9

Hold on, just realized this is actually wrong

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

4573574

Change the repr formatting to ensure that if the keys argment was given,

[sagetrac-git]

Changed commit from 86aaf43 to 4573574

[tscrim]

comment:12

What if the keys are not sortable, say 'a' and 1 (in Python3)? I think the sorting order needs to be in a try-except block and just default to some ordering if sorted fails.

[tscrim]

comment:13

I think this will fail with your branch:

sage: sorted([complex(1), complex(2)])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-7-6dddb83c526f> in <module>()
----> 1 sorted([complex(Integer(1)), complex(Integer(2))])

TypeError: no ordering relation is defined for complex numbers
sage: L = [complex(1), complex(2)]
sage: Family(L, lambda x: x)
Finite family {(1+0j): (1+0j), (2+0j): (2+0j)}

(I am at the airport waiting for a flight and my laptop only have 8.3.beta0, so I cannot test it right now.)

[embray]

comment:14

True--I didn't see any cases in the tests where that was a problem but that could certainly happen I guess. On Python 3 pprint uses a "safe key" wrapper for the keys which falls back to Python 2-style ordering for unorderable types.

I mentioned in my commit message that we might want to add something like this to Sage--I've definitely been finding other places in Sage where one would like to at least order things as best possible. Maybe I'll go ahead and do that first...

[embray]

comment:15

Still planning to work on fixing this up. I'm running into issues with these again :)

[embray]

comment:16

I believe this issue can reasonably be addressed for Sage 8.4.

[tscrim]

comment:17

Any progress?

[fchapoton]

comment:18

ticket was duplicated in #26225...

[fchapoton]

comment:19

let us close this one as duplicate

[embray]

comment:20

Ok.