Empty sparkline with floats #1137

The values of the Goal Plugin are floats (e.g. 1.53% conversions).
The sparkline of conversion rate and eventually overall revenue do not show up.

Correction: I got all sparklines showing up after this hack that converts all values to integers:
/core/Visualization/Sparkline.php method Piwik_Visualization_Sparkline->main() line 67, I add this after the foreach statement:
*$value = (int)($value100);**

The factor 100 does no harm to all other sparklines, because they are resized. I would be good to have this included in the next release.

Attachment: Sparklines fail
sparkline fail.PNG

Attachment:
index.php.png

Attachment: sparklines before hack
Capture-Piwik Web Analytics Reports - Mozilla Firefox.png

Attachment: sparklines after hack
Capture-Piwik Web Analytics Reports - Mozilla Firefox-1.png

Attachment: minimalistic debugging of feature point offset
patch-simple.txt

Attachment: debug of feature point offset and antialiasing
patch-antialias.txt

No, we already scale conversion ratios by 100. This is a bug in the sparkline-php library.

I'll sync up and see if a fix is still needed.

I var_dumped $this->data, and it was not scaled by 100. Are you sure this applies to Goal tracking too?
Do you convert (float) to (int) to work around the bug in sparkline-php?

Yes, I'm sure. The scaling is applied when the conversion rate is calculated and stored in the database.

(In [1822]) fixes #1137 - empty sparkline with floats

• Visualization/Sparkline.php: back out our SetYMax(+.5) hack and upcase function name.
• Goals/Goals.php: refactoring
• libs/sparkline
  • update license files to reflect dual licensing
  • fix clipping issue, ref: https://sourceforge.net/support/tracker.php?aid=2842183
  • fix Y range calculation, ref: https://sourceforge.net/support/tracker.php?aid=2944691

I svn up, and generated sparklines, but sparklines don't look good. I think that is how they used to look like before I manually patched the library, but the changes in [1822] probably reverted this.

See the attached screenshot. The points are many pixels off on the left which looks confusing.

Hi, why not using http://omnipotent.net/jquery.sparkline/ ?

pebosi: yes, I've already looked at that. At this time, I'm not going to change that.

Looking down the road, we might want to support both client and server-side chart generation:

• Client: to offload processing from the server and loosen the installation requirements (gd).
• Server: for email/pdf reports.

(In [1884]) fixes #1137 - off-by-one in x-axis range

thanks Anthon. There is still a small offset in the green point but I think this has always been the case (see attached sparkline)

Near as I can tell, it's a scaling artifact. Sometimes noticeable, sometimes not.

The problem I initially reported is still not corrected in piwik 0.5.5, as the two uploaded screenshots prove.
The first shows piwik 0.5.5 as is,
the second shows the same statistics after I reapplied the patch described above:
/core/Visualization/Sparkline.php method Piwik_Visualization_Sparkline->main() line 67, I add this after the foreach statement:
*$value = (int)($value100);**

The bug is in the sparkline library itself. The sparkline library is converting all input first into a string, and then test if it is numeric.
According to http://ch.php.net/manual/fr/language.types.float.php#language.types.float.casting, php is using the decimale separator defined in the current locale when converting to string, but only recognizes '.' as decimal separator while testing is_numeric.
My backend is configured in the locale fr_FR, which means that (string)1.5 converts to '1,5'.

The solution is to comment out the first two lines in libs/sparkline/lib/Sparkline_Line.php of the method SetData:
$x = trim($x);
$y = trim($y);
or to change them to (which will be a more general solution):
if(!is_numeric($x)){
$x = trim($x);
}
if(!is_numeric($y)){
$y = trim($y);
}

(In [1982]) fixes #1137 - thanks Lorenz (lmeyer) to debugging this locale issue; reported upstream in https://sourceforge.net/tracker/?func=detail&aid=2975415&group_id=122936&atid=694962

I created two patches that correct the offset issue.
The first patch (patch-simple.txt) only corrects the bug in the sparkline lib (and your workaround in Sparkline.php)
The second patch (patch-antialias.txt) pretty much rewrites $Sparkline->RenderResampled and also antialiases the feature points.
I like real circles better than the losanges of piwik sparklines, but it is up to you to decide...

(In [1983]) refs #1137 - fixing various off-by-one errors in drawing feature points; credit: lmeyer