Skip to content
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

Provide a way to print the whole array #705

Closed
bluss opened this issue Sep 10, 2019 · 4 comments · Fixed by #707
Closed

Provide a way to print the whole array #705

bluss opened this issue Sep 10, 2019 · 4 comments · Fixed by #707
Labels

Comments

@bluss
Copy link
Member

bluss commented Sep 10, 2019

#606 implemented some sweet ellipsizing for arrays, but there's no way to print the whole array and we need to provide for it.

We don't use the alternate flag (#) for anything at the moment, so we could use this for forcing the full display.

I also think that the default ellipsizing should be far more generous than just three elements on each size of the fold - a larger number would be convenient for most users.

@bluss bluss added the bug label Sep 10, 2019
@bluss bluss changed the title There's no way to print the whole array Provide a way to print the whole array Sep 10, 2019
@bluss
Copy link
Member Author

bluss commented Sep 10, 2019

The following things exist as parameters in formatting:

https://doc.rust-lang.org/nightly/std/fmt/index.html#syntax

Out of all of these, fill, align, sign, alternate, type etc, I think that only the alternate flag is something we can reasonably hijack for this purpose? All the others - including which format type (trait, Display, Debug, LowerHex etc) seem to make sense to be used for the element's formatting and not really for changing how the array/the framing is formatted.

In the long run, it also makes sense to ask for some kind of reasonable, minimalist extension to Rust formatting strings - if we can find something that's generally useful and good for extensible formatting in Rust in general.

@jturner314
Copy link
Member

I agree that the alternate form flag makes sense for this use case. I've created #707 to implement this.

I think we should choose a better heuristic for when to use the ellipsis in order to reduce how often it appears. NumPy chooses whether or not to abbreviate axes based on the total number of elements in the array. (If there are more than 1000 elements, NumPy abbreviates the axes, leaving 3 items at the beginning and end of each axis.) I think this is a pretty good heuristic, but I'd modify it slightly:

  • If there are no more than 1000 elements in the array, collapse axes with length greater than 200.
  • If there are more than 1000 elements in the array, collapse axes with length greater than 10.

This approach tries to limit the axes to reasonable lengths, while avoiding ellipses in common cases.

One other thing worth noting is that it may be worth choosing a different limit for the last axis than the other axes, because the last axis is written horizontally (within a line) instead of vertically (across lines). Alternatively, we could wrap the last axis when it gets too long (like NumPy), although I don't like this much myself.

@bluss bluss mentioned this issue Sep 15, 2019
@bluss
Copy link
Member Author

bluss commented Sep 15, 2019

That suggestion is a lot better than just using the alternate flag. It makes me wonder, if we would to repurpose the alternate flag for something different later, and that merging that one use of it would just lead to us backing out of it later. If we have a reasonable default for printing array elements, then we could have more complicated ways to configure it, like for example:

use ndarray::FormatOptions;
let opts = FormatOptions::new().no_limits();
println!("{8.4}", array.display_with(&opts));

Could have more fluent shortcut(?) - still a mouthful but I think this is where we often end up in Rust (? prove us wrong 🙂 )

println!("{8.4}", array.format_options().no_limits());

@lucasjinreal
Copy link

@bluss

println!("{8.4}", array.format_options().no_limits());

this caused error

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants