Problem with Y scaling

[markos]

Hi,
I've developed a CSV -> Google chart module for Drupal (http://
drupal.org/project/csvchart), which uses the Drupal Chart API (http://
drupal.org/project/chart). I'm using the module for the freevec.org
site (http://www.freevec.org) successfully for most graphs. But there
are some graphs that produce the wrong result, with a cutoff on the Y
axis.

Here is a correct graph:

http://chart.apis.google.com/chart?chd=t%3A-1%2C-1%2C1%2C2%2C3%2C6%2C11%2C15%2C18%2C21%2C23%2C23%2C24%2C19%2C19%7C-1%2C-1%2C1%2C3%2C5%2C7%2C12%2C18%2C21%2C23%2C23%2C24%2C18%2C19%7C-1%2C-1%2C1%2C2%2C5%2C10%2C10%2C25%2C27%2C60%2C79%2C86%2C93%2C46%2C47%7C-1%2C1%2C2%2C4%2C9%2C14%2C21%2C42%2C63%2C79%2C90%2C100%2C43%2C40%7C-1%2C-1%2C-1%2C1%2C5%2C13%2C17%2C22%2C29%2C48%2C60%2C62%2C65%2C46%2C47%7C-1%2C1%2C2%2C6%2C8%2C14%2C18%2C27%2C43%2C57%2C54%2C68%2C45%2C45&cht=lc&chs=600x350&chtt=memcpy%28%29&chts=0000ee%2C15&chdl=glibc+al%28G4+1Ghz%29%7Cglibc+nal%28G4+1Ghz%29%7Clibfreevec+al%28G4+1Ghz%29%7Clibfreevec+nal%28G4+1Ghz%29%7Clibmotovec+al%28G4+1Ghz%29%7Clibmotovec+nal%28G4+1Ghz%29&chg=30%2C15%2C1%2C3&chco=00ef00%2C0000ef%2Cef0000%2Cefef00%2Cef00ef%2C00efef%2C00af00%2C0000af%2Caf0000&chf=bg%2Cs%2CFFFFFF&chxr=0%2C0%2C4842&chxl=1%3A%7CMB/s%7C2%3A%7C3%7C6%7C12%7C24%7C48%7C96%7C192%7C384%7C768%7C1536%7C3072%7C6144%7C12288%7C24576%7C49152%7C3%3A%7CSize+%28in+bytes%29&chxp=1%2C95%7C3%2C50&chxt=y%2Cy%2Cx%2Cx&chbh=35%2C0

and here is a wrong one:

http://chart.apis.google.com/chart?chd=t%3A5%2C11%2C7%2C15%2C23%2C63%2C94%2C94%2C116%2C126%2C144%2C147%2C152%2C153%2C142%7C5%2C7%2C15%2C18%2C31%2C54%2C84%2C116%2C58%2C60%2C61%2C62%2C61%2C61%7C5%2C5%2C7%2C11%2C31%2C47%2C94%2C189%2C216%2C252%2C318%2C345%2C361%2C356%2C273%7C3%2C7%2C11%2C23%2C47%2C75%2C151%2C216%2C232%2C275%2C327%2C356%2C353%2C281&cht=lc&chs=600x350&chtt=memcpy%28%29&chts=0000ee%2C15&chdl=glibc+al%28G5+2.3Ghz%29%7Cglibc+nal%28G5+2.3Ghz%29%7Clibfreevec+al%28G5+2.3Ghz%29%7Clibfreevec+nal%28G5+2.3Ghz%29&chg=30%2C15%2C1%2C3&chco=00ef00%2C0000ef%2Cef0000%2Cefef00%2Cef00ef%2C00efef%2C00af00%2C0000af%2Caf0000&chf=bg%2Cs%2CFFFFFF&chxr=0%2C0%2C17491&chxl=1%3A%7CMB/s%7C2%3A%7C3%7C6%7C12%7C24%7C48%7C96%7C192%7C384%7C768%7C1536%7C3072%7C6144%7C12288%7C24576%7C49152%7C3%3A%7CSize+%28in+bytes%29&chxp=1%2C95%7C3%2C50&chxt=y%2Cy%2Cx%2Cx&chbh=35%2C0

Or for more graphs, check http://www.freevec.org/functions

I guess this must be a bug with the way the charts are produced. The
data is produced from the same benchmarking program, and there is no
change in the code that would warrant such a graph. The data scales
wrongly for all datasets. Could you please look into it and tell me if
I'm doing sth wrong, or if I have indeed hit a bug with the API?

Thanks

Konstantinos

[JV]

When defining data using text encoding all values have to be between 0
and 100, some of the values in the second graph are outside that
range. My guess is that you have to look into your own program to find
how what multiplier is used to generate your numbers.

JV

On Mar 17, 8:00 am, markos <mar...@debian.gr> wrote:
> Hi,
> I've developed a CSV -> Google chart module for Drupal (http://
> drupal.org/project/csvchart), which uses the Drupal Chart API (http://
> drupal.org/project/chart). I'm using the module for the freevec.org
> site (http://www.freevec.org) successfully for most graphs. But there
> are some graphs that produce the wrong result, with a cutoff on the Y
> axis.
>
> Here is a correct graph:
>

> http://chart.apis.google.com/chart?chd=t%3A-1%2C-1%2C1%2C2%2C3%2C6%2C...

>
> and here is a wrong one:
>

> http://chart.apis.google.com/chart?chd=t%3A5%2C11%2C7%2C15%2C23%2C63%...
>
> Or for more graphs, checkhttp://www.freevec.org/functions

[markos]

I'm afraid it must a problem with how Google renders the data. Here is
the problematic chart:

http://chart.apis.google.com/chart?chd=t%3A5%2C11%2C7%2C15%2C23%2C63%2C94%2C94%2C116%2C126%2C144%2C147%2C152%2C153%2C142%7C5%2C7%2C15%2C18%2C31%2C54%2C84%2C116%2C58%2C60%2C61%2C62%2C61%2C61%7C5%2C5%2C7%2C11%2C31%2C47%2C94%2C189%2C216%2C252%2C318%2C345%2C361%2C356%2C273%7C3%2C7%2C11%2C23%2C47%2C75%2C151%2C216%2C232%2C275%2C327%2C356%2C353%2C281&cht=lc&chs=600x350&chtt=memcpy%28%29&chts=0000ee%2C15&chdl=glibc+al%28G5+2.3Ghz%29%7Cglibc+nal%28G5+2.3Ghz%29%7Clibfreevec+al%28G5+2.3Ghz%29%7Clibfreevec+nal%28G5+2.3Ghz%29&chg=30%2C15%2C1%2C3&chco=00ef00%2C0000ef%2Cef0000%2Cefef00%2Cef00ef%2C00efef%2C00af00%2C0000af%2Caf0000&chf=bg%2Cs%2CFFFFFF&chxr=0%2C0%2C17491&chxl=1%3A%7CMB/s%7C2%3A%7C3%7C6%7C12%7C24%7C48%7C96%7C192%7C384%7C768%7C1536%7C3072%7C6144%7C12288%7C24576%7C49152%7C3%3A%7CSize+%28in+bytes%29&chxp=1%2C95%7C3%2C50&chxt=y%2Cy%2Cx%2Cx&chbh=35%2C0

and here is the same chart, fixed but the only change is the labels
(moved the "G4 1GHz" from the legends to the title), no other change
to the data:

http://chart.apis.google.com/chart?chd=t%3A1%2C3%2C2%2C4%2C6%2C17%2C26%2C26%2C32%2C34%2C39%2C40%2C42%2C42%2C39%7C1%2C2%2C4%2C5%2C8%2C14%2C23%2C32%2C16%2C16%2C17%2C17%2C17%2C17%7C1%2C1%2C2%2C3%2C8%2C13%2C26%2C52%2C59%2C69%2C88%2C95%2C100%2C98%2C75%7C1%2C2%2C3%2C6%2C13%2C20%2C41%2C59%2C64%2C76%2C90%2C98%2C97%2C77&cht=lc&chs=600x350&chtt=memcpy%28%29+-+G5+2.3Ghz+-+warm+cache&chts=0000ee%2C15&chdl=glibc+al%7Cglibc+nal%7Clibfreevec+al%7Clibfreevec+nal&chg=30%2C15%2C1%2C3&chco=00ef00%2C0000ef%2Cef0000%2Cefef00%2Cef00ef%2C00efef%2C00af00%2C0000af%2Caf0000&chf=bg%2Cs%2CFFFFFF&chxr=0%2C0%2C17491&chxl=1%3A%7CMB/s%7C2%3A%7C3%7C6%7C12%7C24%7C48%7C96%7C192%7C384%7C768%7C1536%7C3072%7C6144%7C12288%7C24576%7C49152%7C3%3A%7CSize+%28in+bytes%29&chxp=1%2C95%7C3%2C50&chxt=y%2Cy%2Cx%2Cx&chbh=35%2C0

Any ideas/suggestions?

[markos]

(sorry that should be "G5 2.3GHz", but the rest stays the same.

[JV]

These two charts are not of the same data. The first data statement
starts with chd=t:5,11,7,... the second starts with chd=t:1,3,2,...
The first one contains data points greater then 100 (it looks like the
chart is scaled such that the maximum of 'glibc nal' is set equal to
100, but the other lines contain larger values). I would recommend to
look into one of the new features announced today that allows us to
define the range instead of the default range of 0-100.

On Mar 18, 10:59 am, markos <mar...@debian.gr> wrote:
> I'm afraid it must a problem with how Google renders the data. Here is
> the problematic chart:
>

> http://chart.apis.google.com/chart?chd=t%3A5%2C11%2C7%2C15%2C23%2C63%...

>
> and here is the same chart, fixed but the only change is the labels
> (moved the "G4 1GHz" from the legends to the title), no other change
> to the data:
>

> http://chart.apis.google.com/chart?chd=t%3A1%2C3%2C2%2C4%2C6%2C17%2C2...
>
> Any ideas/suggestions?