Anonymous user
Talk:Sparkline in unicode: Difference between revisions
→Deeper root of the 'bug' ?
Line 181:
::: What you are suggesting is cetainly one way, but '''not''' the only way.
::: The task is '''not''' to fill buckets evenly. The task is to produce a vertically proportional sparkline. Your test does not have a unique correct output. No reason that it should, but if we misrepresent it, we will mislead people [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:14, 27 February 2019 (UTC)
:::: > The task is '''not''' to fill buckets evenly. The task is to produce a vertically proportional sparkline.
:::: To whatever extent the filling is uneven, the vertical axis is non-proportional. These two tasks are exactly equivalent.
:::: Mathematica and R's solutions are reasonable because they are solving a different and more general problem. A crucial difference is that they're making histograms suitable for plotting with a labeled x-axis. Integer breaks are valuable in that situation; perhaps valuable enough to sacrifice evenness.
:::: In this sparkline problem, integer breaks have no value because the y-axis will never be labeled. Bins of equal width (or as close to equal as the data permits), provide fidelity that is superior to bins of unequal width.
:::: There is no contradiction or mathematical incoherence in <code>floor( bins * (v-min) / (max-min+fencepost_size) )</code>. If someone dislikes the aesthetics of clamping the last value—which I can understand even if I disagree—then the optimal solution is implied by this formula. The margin you refer to will be determined by <code>fencepost_size</code>, which can be slightly oversized but should not be lazily chosen as "distance to the next power of ten," nor "distance to the next whole number" and absolutely definitely not "1/8th of total range size" (like Haskell's stats library does). --Oopsiedaisy, 27 Feb 2019
==Bar choices==
| |||