Talk:Sparkline in unicode: Difference between revisions
→Deeper root of the 'bug' ?
Line 194:
:::: 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
:::: Good. We are in agreement on the rationality of <code>floor( bins * (v-min) / (max-min+fencepost_size) )</code>
::::
:::: As for our options in the derivation of <code>fencepost_size</code>, the task description leaves this entirely open, as the over-lexicalising tone of your '''absolutely definitely not''' XYZ... inadvertently confirms :-)
:::: The only thing that remains is that to avoid misunderstanding and misdirection, I think you '''do''' need to edit your presentation of the test samples above, to clarify that three spark levels for the second one is diagnostic only of the implementation of '''one particular approach''', but will yield diverging results for other equally correct approaches.
:::: It is not inherently diagnostic of a 'bug'.
:::: In fact, it's not really clear that the (mathematically perfectly coherent) TCL version contains a '''bug''', any more than fudging the upper boundary condition constitutes a '''bug'''.
:::: At such extremely low resolution, we can easily generate unfortunate border condition artefacts with '''any''' approach, as long as we choose our sample carefully. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:16, 27 February 2019 (UTC)
==Bar choices==
| |||