Talk:Sparkline in unicode: Difference between revisions
Content added Content deleted
| Line 153: | Line 153: | ||
::: The bug is that bins are not of equal width or anything close to equal. How the minimum (or maximum) is chosen is not relevant: the bug affects both implicit and hardcoded boundaries. You are correct that the second test case assumes implicit boundaries; however you can subtract one from each value, get a zero-based range, and see that the bug persists. You are also correct that the task description doesn't specify a mapping from numbers to heights, but this objection seems silly and pedantic to me. We could randomly select a height for each datum and not strictly violate the task description but what use is that? Usefulness and fidelity dictate that heights are proportional to the data's magnitude (relative to its own extremes, or to reasonable hardcoded values), to the extent possible given the low resolution of the output. -- [[User:Oopsiedaisy|Oopsiedaisy]], 26 February 2019 (UTC) |
::: The bug is that bins are not of equal width or anything close to equal. How the minimum (or maximum) is chosen is not relevant: the bug affects both implicit and hardcoded boundaries. You are correct that the second test case assumes implicit boundaries; however you can subtract one from each value, get a zero-based range, and see that the bug persists. You are also correct that the task description doesn't specify a mapping from numbers to heights, but this objection seems silly and pedantic to me. We could randomly select a height for each datum and not strictly violate the task description but what use is that? Usefulness and fidelity dictate that heights are proportional to the data's magnitude (relative to its own extremes, or to reasonable hardcoded values), to the extent possible given the low resolution of the output. -- [[User:Oopsiedaisy|Oopsiedaisy]], 26 February 2019 (UTC) |
||
:::: 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) |
|||
==Bar choices== |
==Bar choices== |
||