Here's a Haskell version that uses a single loop to do the normalizing, and has a main that doesn't use do syntax. This was mostly a nice little brainteaser:
mapNormalize takes a function, and produces a function that runs that function with the normalized input. It runs in a single iteration, rather than 2 maps. Credit to `dylex` for much hand holding on a single iteration normalizer :)
Because Haskell is evaluated lazily, two maps doesn't imply two iterations over the data. In this case, I would expect only one pass through the data for both of the maps.
Out of curiosity, I did a quick criterion benchmark for both functions. Here's the result on a list of 100 elements:
(As an aside, is there something in particular you dislike about do syntax? I find that it often makes things more readable, though slightly more verbose.)
I am aware of that, as I said this was more a mental exercise. normalizeMap is harder to understand, but it was interesting to write - it wasn't meant to be a stab at your code or claim it's better :)
In terms of do syntax, I try and avoid that because I find it detracts from the overall flow of data. With: "putStrLn . spark . map read =<< getArgs" I find it easy to see that main doesn't do much other than transform the users input. maybe a personal preference thing though...
This is pretty cool. Unfortunately it's coupled with some of the more obnoxious documentation I have seen recently. While the docs aren't very long, I had to read through a third of it to figure out simply what Spark is.
I'm all for being cute, but it shouldn't come at the cost of a basic understanding of what the program actually does and is useful for.
The script is not a proper POSIX bourne shell script, as it uses arrays.
For starters, it won't work in dash (Debian and Ubuntu /bin/sh implementation). So the shebang line should be changed to #!/bin/bash (not sure if it would work in Zsh either).
I can't speak to NetBSD, but FreeBSD doesn't put any user-installed programs in /bin or /usr/bin, they all go into /usr/local. Since bash isn't distributed as part of the base system, it goes into /usr/local/bin/bash
So then how do you write cross-platform scripts? You can't even do "#!/usr/bin/env bash" since I'm assuming what you're saying means 'env' is in /usr/local/ as well, but on Linux systems it'll be in /usr/.
Broken! Can we please just pick one convention and stick with it? Oh, standards... so many to choose from.
I'm curious: is there a reason U+2584 LOWER HALF BLOCK is missing from the character set, which otherwise contains the progression from U+2581 to U+2587?
Edit: U+2588 seems like an obvious candidate as well.
At least in my OS/X terminal using the "Monaco" font (which I think is the default), the final one (U+2588) doesn't descend as far as the rest of the characters. It really produces some ugly output with that one included.
Including the space character means that you lose a nice baseline if the input is fairly sparse, so it looks less like a bar graph and more like just some random blobs.
(edit) Ah, the downvoting frenzy! 4601 karma points to go. Bring it on, fellow HNers. Don't forget to quote the guidelines and to lecture me too as no bashing is complete without showing some smug superiority with a hint of righteousness.
Well. When I posted the above comment, its parent was lingering at the very bottom of the page. Then it quickly floated to the top, and after that mine got as quickly downvoted into oblivion. Interesting dynamic in itself.
Right now the karma counter keeps oscillating around 4600... which makes me regret that I didn't say it was 4701 :)
I rewrote it in C, so it's faster and can work more efficiently on different data sets. It also uses a prettier algorithm for determining heights. Have fun:
A sparkline is a specific type of graph used for certain types of data. The wiki page is pretty clear with the uses and limitations.
Not all graphs are created equal, it's important to use the right tool for the job. This tool isnt just a graph generator, it's a spark bar chart generator that's compact enough to fit in the command line. Overall a cool idea.
I feel like I'm being reprimanded. Forgive me if I'm mistaken.
> A sparkline is a specific type of graph
My point is this should be explained _somewhere_. Anybody else unfamiliar with sparklines will now have the benefit of this thread. Previously, to me anyway, it was a mystery.
> The wiki page is pretty clear with the uses and limitations.
It is. It was only presented upon my initial query, and am grateful to @IgorPartola for providing!
> Not all graphs are created equal, it's important to use the right
> tool for the job. This tool isnt just a graph generator, > it's a
> spark bar chart generator that's compact enough to fit in > the
> command line. Overall a cool idea.
It is, indeed. My initial note wasn't about the coolness of the project, just "what _is_ the project"? Is clear now. Anybody else who is ignorant about sparklines as I was, enjoy this thread!
All involve awk or sed. That cuts out a large portion of the potential userbase...
Perhaps common uses could be wrapped in options to the script? For instance, an option to graph numbers on separate lines, to graph all numbers in the input in order, to graph a specific column of information (like passing through cut first) or to graph commonly graphed sources?
I feel like they're examples of really awesome use cases, so it shouldn't matter if people can't use them. Not to mention, I feel like this tool is targeted for terminal junkies who likely already have awk/sed.
Tufte honestly thinks pixelated type is pretty terrible, too. 16 pixel density is embarrassing compared to printed or pressed text.
But in either case, it's obvious that's a silly argument. Trends posterized to 8 levels are far easier to read in "sparkbar" form than as a list of numbers. It's suboptimal, but better than the plain list.
Doesn't seem to be able to display the block characters neither on PuTTY, gvim on Windows or my Linux terminals/editors. Am I missing something obvious here?
https://github.com/Mgccl/mgccl-haskell/blob/master/random/sp...