Anonymous user
Talk:Sparkline in unicode: Difference between revisions
→Deeper root of the 'bug' ?
Line 156:
:::: The problem is simply that while your scheme is perfectly practicable, it is not the only scheme that is reasonable or effective, and in fact the R and Mathematica approach seems marginally better, avoiding the need for special fudges, while yielding visibly different results at the margin.
:::: Given that equally reasonable approaches can yield differing sparkline horizons at the margin, we can't define a unique 'correct result' for the 0-7999 case, and we can't use it to sort buggy from bugless implementations. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 02:15, 27 February 2019 (UTC)
::::: It's hard to comment on the reasonableness of R's result because I can't figure out what it's doing or how the output of <code>breaks</code> maps to actual breaks. Output says lower bounds are <code>0 1000 ... 4000 5000 ..</code>, but then 0 and 999 go into one bin, while 4000 and 4999 go into two different bins?
::::: Speaking generally, if the task is "'''assign 8n items to 8 bins as equitably as possible'''", a solution that doesn't assign n items to each bin is wrong. It's wrong because a more equitable assignment was possible.
::::: The Haskell approach is the half-width bug and simply bad: the first and last bins are half the widths of the others for no good reason. --Oopsiedaisy 26 Feb 2019
==Bar choices==
| |||