-
Notifications
You must be signed in to change notification settings - Fork 72
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
Add ASCII output for 1D histograms #74
Comments
Hi, |
Cool, thanks! |
Hi,
I would like to clarify some details:
|
This looks great so far! Some suggestions.
Can you please put the counts per bin on the right-hand-side of the ASCII art? |
This is what I have in mind:
|
Thank you for comments.
|
Both look great! I am more inclined towards the "updated version" than the "alternative version" as you can imagine, but I will try to get some more feedback from other people. The mainline version sets the focus on the bars, the counts are an extra. The alternative version puts the focus on the counts. |
the "counts right" looks cleaner somehow, but less practical: Tbh: no strong preference. But the longer I stare at it, the more I prefer the cleaner, "counts right" version. |
I would be tempted towards "alternative version" for the practicality of mapping a count to a bin. As another option, what about putting the counts on the far left so the bar and counts are both next to the interval:
|
What about putting counts "inside"?
|
Oh no, you guys added even more options! 😅 @przemb Your first version of counts inside produces a very irregular image, I find that very irritating and strenuous to look at. The second option is better, but I don't like that bins without an entry don't get a zero. I would prefer your original "alternative version" over the new one. @chrisburr That's an interesting one, but it seems less obvious than the "alternative version" from @przemb. I think it is more natural to read from the left to right, starting with the bin interval first and then get a listing of the counts. Ok, all things considered, I would now favor the "alternative version":
|
What's nice about that one: you can consider the character length of the printed numbers as another "bar", effectively you get a second log-scale view of the histogram for free. |
You get a second log scale histogram anywhere you have the counts printed as long as they line up (though right aligned provides an odd backward histogram). I like the counts right, outside best, followed by the "alternative version" directly above. It's cleaner and less distracting I think to have them far right. I don't like the "inside" ones, as the endpoint of the bar is not clear. The more I look at it though, the more I like the "alternate" version - though it's not quite as clean, I think it is fairly simple to infer the meaning. |
@przemb So we have a winner, the "alternative version". Could you prepare a pull request so that I can review the implementation? |
Yes, sure. I would "polish" it, and I will make PR at the weekend. |
Hi everyone, let me add to the party :): let me start by saying that I have no strong preference between the 2 ones that are getting more attraction. This being said, I do slightly prefer the version with the counts on the right, outside. After all, if I'm doing an ASCII representation of the plot, then I'm probably more interested in the looks than in the actual bin counts, which I can retrieve. Having the counts on the left, side-by-side with the bin definitions, is a bit distractive in that respect. This is me just thinking on why I would do an ASCII plot. |
@eduardo-rodrigues I am happy to see that both you and Henry basically had the same preference as me, initially, but just like in Henry's case the version with counts on the left grew on me. What changed my mind is the following thought: this is an implementation for |
I see. As said, no strong preference. Both versions will be "readable" :-). |
This would be Tufte's version with non-essential lines removed:
|
Somehow, I didn't see this until now. I think it's great that you (@przemb) are seriously thinking about this issue! Here are my comments:
This isn't an ASCII histogram in the old sense (PAW's If you're interested, Histogrammar had more cases: see this documentation and this code (in Scala) for profile plots:
and 2-dimensional histograms (this one could use a bounding box, and perhaps marginal projections on the left and bottom):
Interestingly, I found this discussion on the ROOT forum in 2009. A user was looking for this feature because of a difficult ssh situation. |
@jpivarski Thank you for these valuable comments! Your argument for putting the numbers on the left also makes a lot of sense to me. I like the suggestion to use unicode box characters, we can try to upgrade the plotting at a later point with this, if we figure out a way to detect whether the terminal supports unicode. The ASCII art has the advantage of being the lowest common denominator. I would therefore stick to that for now. Regarding the terminal width, this can be queried at runtime. It is difficult to do in a platform-independent manner, but the ncurses library and some programs manage to do it, so it is possible to adapt the width of the histograms to the current terminal width. Again I would worry about that later. For now I would like to move on with this feature. Regaring the plot Tufte-style, I put that here to document how it looks, but I am not clearly preferring it - at least if we can make sure that the terminal width is properly handled and bars never overflow into the next line. I am generally a fan of Tufte's minimalistic approach, but like any good thing it is also possible to overdo it. I can't find the article any more, but there was a blog entry where a professor tried a standard and a Tufte-rised histogram on his students. It turns out that the students liked the standard version better, because it had a frame around the plot. A frame is apparently a visual clue that grounds us, even when it does not provide quantitative information. Finally, it would be nice to follow a consistent style for histograms and profiles, which we both want to visualize, and the profile plot really needs the frame. So the histogram plot should also have it. |
There we go, tests for unicode support: |
Actually, I'm not so sure I'd want Unicode to be automatically detected—I might choose pure ASCII on a terminal capable of Unicode because I plan to copy-paste the output. Maybe the choice of default could come down to auto-detection, though. I have a similar—and stronger—feeling about console width. You can try to auto-detect the width for the sake of a default, but there will be many circumstances where it's wrong. Passing through ssh, screen, Emacs's shell-mode, strange GUIs that have a terminal inside them, whatever Jupyter's terminal does, a VT100 emulator through Kermit—even if you find work-arounds for each of the cases I'm mentioning here, there will be others. The point of an ASCII histogram is that it's the least common denominator, and curses isn't the least common denominator (or at least, curses without being piped through something that curses doesn't know about). In short, I'm arguing that simplest is best—if the function produces standard output, always the same size, minimal decoration, users will work around it (particularly users who are asking for ASCII plots!). |
I agree with Jim - Simpler is better as a default. Auto-detection is great, but you can always find a way to break it, so it should not be used in And the wrapping issues sold me on numbers-on-the-left. |
No, simpler is not better as a default. simple is not a design criterion for a default at all. A default should work for most people, most of the time, and you cannot guess the terminal widths that people use. So setting a fixed width makes no sense. My terminals, for example, vary dramatically in width. Whatever fixed width you would chose, it would not work in some terminals. The width has to be autodetected by default, which is also what other terminal programs do, like everything that draws a progress bar, for example. You cannot pass options to |
Two points to clarify. 1) When I speak about a default, I always mean a value that users can customize but which has a setting that works for most scenarios. 2) I didn't propose that Boost.Histogram should depend on the ncurses library to get the terminal width. Boost.Histogram may only depend on Boost and the C++ std lib. It can use the same logic that ncurses uses, though, to get the terminal width. |
I meant a fixed size with the understanding that it would be wrong on some terminal sizes. We're both addressing this issue of terminals being a variety of sizes, and my thinking was that it may be better to return the same width by default and be wrong by default than to try to figure it out and get into a weird corner case with curses or something. I didn't realize that this was to be the You're right that "simple" didn't always make good defaults—it should keep as many users as possible from having to touch the defaults, particularly if they'd have to switch modes to do so (like, from bare |
Now implemented by @przemb who wrote an awesome patch! Thanks! |
Awesome work! Cross-referencing the PR #201 |
Even in times of GPUs, ASCII art is still popular. Some users asked for simple ASCII output, e.g. like the one in uproot:
The question is what to do when you want to plot an N-dimensional histogram.
The text was updated successfully, but these errors were encountered: