Talk:Sparkline in unicode: Difference between revisions

m
Line 213:
> ''derivation of <code>fencepost_size</code>, the task description leaves this entirely open''
 
The task description is not a contract or rigorous specification. Properties like usability, fidelity, proportionality are implied. You're free to disagree but you won't convince me or most other people.
The sole purpose of <code>fencepost_size</code> is to prevent the formula from returning 8. In IEEE754 64-bit floats (used by JavaScript, Perl, and many others) it can be about 15 orders of magnitude smaller than <code>max-min</code> before it fails. In 32-bit floats, about 7. Using larger values provides no benefits and (eventual) visible drawbacks, therefore larger values should not be used.
 
ForThe comparison,sole thepurpose half-widthof bug<code>fencepost_size</code> is to prevent the equivalentformula from returning 8. In IEEE754 64-bit floats (used by JavaScript, Perl, and many others) it can be about 15 orders of usingmagnitude smaller than <code>fencepost_size==(max-min)/8</code> before it fails. In other32-bit wordsfloats, it'sabout 147 orders of magnitude. Using larger thanvalues what'sprovides needed,no benefits and it causes(eventual) visible deformationdrawbacks, oftherefore thelarger graphvalues should be avoided.
 
For comparison, the half-width bug is the rough equivalent of <code>fencepost_size==(max-min)/8</code>. It's '''14 orders of magnitude''' larger than needed, and it causes visible deformation of the graph.
The description is not a contract or rigorous specification. Properties like usability, fidelity, proportionality are implied. You're free to disagree but you won't convince me or most other people.
 
> ''as the over-lexicalising tone of your '''"absolutely definitely not [the half-width bug]"''' XYZ... inadvertently confirms :-)''