Talk:Sparkline in unicode: Difference between revisions

::::: I disagree (I think you probably will too, on reflection :-) A chart with unused bins to left and right, representing sections of the scale into which no data fell, is no less proportional in the central bins that '''are''' filled. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:16, 27 February 2019 (UTC)

The applications of this code are not imaginary. As someone who wants to communicate to an audience, using this visual tool, what does it gain me if <code>0 1 2 3 4 5 6 7</code> looks like ▁▂▃▄▅▆▇█ but the graph deforms as I scale up the data? Nothing. You're saying that if I plot a list of percentages, and append <code>0,100</code> to the data to fix the scales, that it's perfectly reasonable for the algorithm to assign <code>-6.25,106.25</code> the left and right boundaries. It's not. The assigned numbers are mathematically meaningless in the context of my data.

> ''derivation of <code>fencepost_size</code>, the task description leaves this entirely open''

The sole purpose of <code>fencepost_size</code> is to prevent the formula from returning 8. In IEEE754 64-bit floats (used by JavaScript, Perl, and many others) it can be about 15 orders of magnitude smaller than <code>max-min</code> before it fails. In 32-bit floats, about 7. Using larger values provides no benefits and (eventual) visible drawbacks, therefore larger values should not be used.

For comparison, the half-width bug is the equivalent of using <code>fencepost_size==(max-min)/8</code>. In other words, it's 14 orders of magnitude larger than what's needed, and it causes visible deformation of the graph.

The description is not a contract or rigorous specification. Properties like usability, fidelity, proportionality are implied. You're free to disagree but you won't convince me or most other people.

> ''as the over-lexicalising tone of your '''"absolutely definitely not [the half-width bug]"''' XYZ... inadvertently confirms :-)''

See my comments, a few paragraphs previous, about plotting percentages vs <code>-6.25,106.25</code>. If you'd like to have a discussion about the algorithmic merits of hypothetical 1/n^th-width bugs for n>2, okay, but recognizing the half-width bug as a bug is the starting point. It's an entry requirement.

You've often conflated purposeful selection of zero-based axis/integer breaks (as R does) with the jumbo "margins" produced by bad fencepost sizing (this bug and what Haskell's stats lib does). They are not the same thing, at all. The first is defensible (though probably a bad idea in this specific task); the second is not.

>> To whatever extent the filling is uneven, the vertical axis is non-proportional. These two tasks are exactly equivalent.

> A chart with unused bins to left and right, representing sections of the scale into which no data fell, is no less proportional in the central bins that '''are''' filled.

This doesn't make any sense. You say "into which no data fell" as if the data ''could'' fall there. '''It couldn't'''. If it does, the boundaries move. The term for "proportional with respect to data that cannot exist" is "disproportionate." The first and last height represent 1/14th of the range. The other six heights represent 1/7th of the range each. They are disproportionate.

> At such extremely low resolution, we can easily generate sub-optimal boundary condition artefacts with '''any''' approach, as long as we choose our sample carefully.

I sincerely doubt it. You have not tested this statement. You ought to. I suggest the (current) Perl implementation. --oopsiedaisy