-
Notifications
You must be signed in to change notification settings - Fork 307
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
Improve formatting for arrays with ndim > 2 #633
Conversation
Nice!
|
8613b34
to
679b7e2
Compare
Here are a few options: Option 1 (NumPy-style formatting, the original version of this PR)
Option 2 (@LukeMathWalker's proposal plus trailing commas)
Option 3
Option 4
My preferences in descending order are 2 > 1 > 4 > 3, although I don't have a strong preference between 2 and 1. I'll change this PR to option 2 unless someone likes another option better. |
679b7e2
to
3473ccd
Compare
I think on each level 2
|
I agree that two spaces of indentation looks pretty good. While working on this, I came across some interesting edge cases. Without any special casing, a 4x1x1 array looks like this:
However, we could add a special case for length-one axes to make it look like this:
Which is better? A similar thing happens for e.g. 1x2x3. Which is better?
or
I think I prefer the non-special-cased versions for consistency, but they aren't quite as visually appealing. |
What about using different brackets? Something like this:
|
I agree that consistency here should be preferred, especially with parsing of this output in mind. |
0402363
to
43ef6a2
Compare
What is the status of this PR @jturner314? |
If I'm pragmatic I prefer the first version (numpy bias). I'd prefer to think about daily usage, coding, iterating, debug print and output-printing from finished programs. I think pragmatic and compact while readable is better than using a lot of whitespace for consistency or ease of parsing. For example, double newlines between rows is not very practical. |
After considering this some more, I think I'd prefer to use NumPy-style formatting for the time being because:
Note that we should add the ability to customize the formatting in the future anyway (which would allow supporting the more expanded style) because the user may not want ellipses on long axes. (Personally, I find when debugging that I want to print the entire array, not just a summary.) There are different ways to handle the customization (global variable, wrapper around I'll update the PR to change it back to NumPy-style formatting.
One comment about this -- are you referring to the blank lines in arrays with ndim >= 3, like in my initial comment on this PR? This matches NumPy's formatting and I think greatly helps when reading large higher-dimensional arrays. |
43ef6a2
to
d3918f0
Compare
Assuming the tests pass, this should be ready to merge. (It uses NumPy-style formatting.) |
The gripe about newlines was about the more sparse outputs in later comments. We have that alternate flag we could repurpose of course, the hash/# in formatting. But one knob isn't much for the options. If needed a builder style but simple formatting adaptor could be provided? |
nice! |
Best to merge so that we can fix #705 |
3-D array
Before
After
4-D array
Before
After