Talk:Sparkline in unicode: Difference between revisions

Most of these are buggy
No edit summary
(Most of these are buggy)
Line 1:
==Most of these are buggy==
 
===The wrong way to compute the character index===
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 truncated (<code>floor</code>/<code>ceil</code>/<code>int</code>), the first or last bin will be one value wide.
* when the quotient is rounded, the widths of the first and last bin are too small by half.
 
===The right way to compute the character index===
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.
 
===Test cases that detect bugs===
* <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: ▁▂▅▅▇█
 
====sparktest.pl====
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).
 
<code>perl -Mutf8 -CS -ne 'chomp; s/[^▁-█]//g; next unless length; @c=split ""; $i=$li=$lc=0; for $i (0..@c) { if ($c[$i] ne $lc) { $w=$i-$li; print "$w " if $w; $li=$i } $lc=$c[$i]||"" };print "\n"'</code>
 
Sample usage (in bash, and assuming program accepts space-separated data on standard input):
 
<code>echo {1..8000} | sparkline | sparktest.pl</code>
 
Expected output from the sample is <code>1000 1000 1000 1000 1000 1000 1000 1000</code>.
 
===Not Buggy===
* [[Sparkline_in_unicode#Go|Go]]. Tested up to <code>echo {1..12345} | go run sl.go | sparktest.pl</code>
 
===Buggy===
* C: ▁▂██
* C++: ▁▁▇█
* Clojure: ▁▂▅▅▇█
* Common Lisp: ▁▂▅▅▇█
* D: obvious one-wide bug; didn't run the code
* Elixir: ▁▂▅▅▇█
* Groovy: one-wide; didn't run
* Haskell: looks like half-width bug; didn't run
* Java: one-wide; didn't run
* Javascript: ▁▂▅▅▇█
* jq: one-wide and neglects to check bounds: ▁▃▷►
* Nim: Python translation
* Perl: ▁▁▇█
* Perl 6: ▁▁▇█
* PicoLisp: ▁▂▅▅▇█
* Python: ▁▁▇█
* Ruby: ▁▁▇█
* Rust: thread 'main' panicked at 'attempt to subtract with overflow', sl.rust:8:40
* Tcl: ▁▁▄▅▇█; not a half-width bug (the second character is correct); manifests only on large ranges; see comments above.
 
 
... that's 15 tested, 14 failures, plus 5 didn't-runs that almost certainly have the bug.
 
 
==Bar choices==