Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5141 +/- ##
==========================================
+ Coverage 84.61% 84.90% +0.28%
==========================================
Files 706 706
Lines 95579 95675 +96
==========================================
+ Hits 80877 81233 +356
+ Misses 14702 14442 -260
🚀 New features to boost your workflow:
|
The code in GAP does not allow to e.g. restrict a permutation to a single line.
56c5905 to
78b84ee
Compare
|
I am a bit confused that permutations should be shortened at all when they are printed by themselves. We don't do that for numbers, polynomials or matrices. |
|
Agree with @joschmitt. Do we want single line printing of objects by default in the REPL? Maybe there was a discussion I missed. |
|
I am not aware of a general discussion. I am mostly interested for this in lists of elements. I am open to have the default for "direct" printing on the REPL in various ways... in particular it wouldn't have to be single line, but in my experience anything that fills more than one screen is almost always useless. So having a cutoff at anything between 1 and SCREEN_ROWS lines by default (with an escape hatch if you really want to see all) would make sense (and IMHO not just for permutations) |
The code in GAP for printing a permutation does not allow to e.g. restrict a permutation to a single line. It also has other IMHO suboptimal behaviour, For example, while it restricts the number of cycles being printed if there are too many, it still always prints the first cycle in full, even if it has length 1000. This leads to "uneven" output, where some permutations get much more space than others:
So I took the printing code in GAP and rewrote it in Julia, and started to tweak it. I won't claim it is "perfect" (nor won't I claim to know what that even means ;-) ) but at least by having it in Julia it becomes easy for us to tweak it as we wish.
Of course you can still print the whole thing:
This code was originally written for and used in my PR #2878 but I figured I could try to get it merged separately. But ideally there should be proper & thorough tests for it... Alas I did not find the time to write any but I also don't want this to get lost, so I am opening this as a draft PR, until someone finds time to make it ready. (Besides it's an easy way for me to find out which parts need coverage or if any existing printing tests are broken by this.)
(This PR contains PR #5140 which should be merged first)