Talk:Sparkline in unicode: Difference between revisions

==Most of these are buggy==

Anything that uses the number 7 (<code>bins-1</code> etc.) in the binning assignment has too-wide bin sizes. The two most common manifestations of the bug are:

* when the quotient is rounded, the widths of the first and last bin are too small by half.

The Go code uses <code>int( 8 * (v-min) / (max-min) )</code> which works in all cases except when <code>v==max</code>; it deals with that case by clamping values larger than 7 to 7 (for a zero-based array).

The Tcl code gets honorable mention for using <code>int( 8 * (v-min) / (max-min)*1.01 )</code>, which mostly does the same thing as the Go code. It avoids the need for clamping but gives bins that are 1% too wide, which becomes visible when the range is large. This approach works if the multiplier is larger than 1, smaller than <code>1 + 1/(max-min)</code>, and large enough to not get overwhelmed by floating-point imprecision.

* <code>0 1 19 20</code> detects the one-wide bug. Output should be the same as <code>0 0 1 1</code> with exactly two heights. The bug looks like ▁▂██ or ▁▁▇█

* <code>0 999 4000 4999 7000 7999</code> detects the half-width bug and some smaller errors (see Tcl). Output should have three heights; the half-width bug looks like: ▁▂▅▅▇█

This is some Perl code that will report the widths of same-height sections of output, when provided with a sparkline on standard input. Non-sparkline-lines are ignored. The line produced from a continuous integer sequence should produce eight equal widths (or almost equal if the sequence length is not a multiple of eight).

Expected output from the sample is <code>1000 1000 1000 1000 1000 1000 1000 1000</code>.

* [[Sparkline_in_unicode#Go|Go]]. Tested up to <code>echo {1..12345} | go run sl.go | sparktest.pl</code>

* C: ▁▂██

* C++: ▁▁▇█

... that's 15 tested, 14 failures, plus 5 didn't-runs that almost certainly have the bug.

==Bar choices==