A better renderLayout1sStacked?

[Malcolm Wallace]

Here is a patch that provides an alternative implementation of
renderLayout1sStacked. It avoids using the AnyLayout1 type (which is
now redundant, although I did not yet remove it), and takes a bunch of
Layout1s with the same x and *y* coordinate types. (Previously just
the same x.)

My goal was to avoid having a separate title, legend, and x-axis
labels for each Layout1: now there is a single title at the top (taken
from the first Layout1), a single combined legend at the bottom, and a
single set of x-axis labels at the bottom.

Because of the single set of x-labels, it was also necessary to ensure
that the x-axes genuinely match up vertically; previously, if the x-
values were in different ranges, then the visual vertically-
corresponding points were potentially misleading.

The overall effect of this patch is therefore to change
renderLayout1sStacked from mere vertically-aligned image-compositing,
to semantic composition of the data.

I realise that this change may be controversial. Perhaps both the
original behaviour and the new behaviour would be desirable in
different applications. In that case, I am willing to re-roll this
patch with new names. But in the interests of keeping APIs as small
as possible, I thought I would at least raise the question whether
this _could_ be a replacement rather than an addition?

Regards,
Malcolm

[Eugene Kirpichov]

I introduced this function in the first place to render several completely different graphs with a common time axis - even the domains of their y axes may be different. This behavior is critical for me, in the "timeplot" program (see hackage), so I am strongly opposed to removing the function.

07.01.2011, в 17:03, Malcolm Wallace <malcw...@googlemail.com> написал(а):

> Here is a patch that provides an alternative implementation of renderLayout1sStacked. It avoids using the AnyLayout1 type (which is now redundant, although I did not yet remove it), and takes a bunch of Layout1s with the same x and *y* coordinate types. (Previously just the same x.)
>
> My goal was to avoid having a separate title, legend, and x-axis labels for each Layout1: now there is a single title at the top (taken from the first Layout1), a single combined legend at the bottom, and a single set of x-axis labels at the bottom.
>

> Because of the single set of x-labels, it was also necessary to ensure that the x-axes genuinely match up vertically; previously, if the x-values were in different ranges, then the visual vertically-corresponding points were potentially misleading.

>
> The overall effect of this patch is therefore to change renderLayout1sStacked from mere vertically-aligned image-compositing, to semantic composition of the data.
>
> I realise that this change may be controversial. Perhaps both the original behaviour and the new behaviour would be desirable in different applications. In that case, I am willing to re-roll this patch with new names. But in the interests of keeping APIs as small as possible, I thought I would at least raise the question whether this _could_ be a replacement rather than an addition?
>
> Regards,
> Malcolm
>

> <stacked.dpatch>
> --
> You received this message because you are subscribed to the Google Groups "Haskell Charts" group.
> To post to this group, send email to haskell...@googlegroups.com.
> To unsubscribe from this group, send email to haskell-chart...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/haskell-charts?hl=en.
>

[Malcolm Wallace]

On 7 Jan 2011, at 14:46, Eugene Kirpichov wrote:

> I introduced this function in the first place to render several
> completely different graphs with a common time axis - even the
> domains of their y axes may be different. This behavior is critical
> for me, in the "timeplot" program (see hackage), so I am strongly
> opposed to removing the function.

Fair enough - I suspected this might be the case. Here is a revised
version of my patch, introducing the alternative with a different
name: stackLayout1sVertically.

Regards,
Malcolm

[Tim Docker]

> Fair enough - I suspected this might be the case. Here is a revised
> version of my patch, introducing the alternative with a different
> name: stackLayout1sVertically.

I seem to have some trouble applying this patch along with your earlier
axisLabelling one. I think this is due to conflicts with one or two
patches that are actually in the hackage 0.14 release, but which I'd
failed to push previously to the public darcs repo. Oops!

Do you mind rerecording these two, against the current contents of the repo?

(Also, I'll be on holidays for a couple of weeks from thursday, so won't
reply until after that)

Thanks,

Tim

[Malcolm Wallace]

> I seem to have some trouble applying this patch along with your
> earlier axisLabelling one. I think this is due to conflicts with one
> or two patches that are actually in the hackage 0.14 release, but
> which I'd failed to push previously to the public darcs repo. Oops!
>
> Do you mind rerecording these two, against the current contents of
> the repo?

Sure. The two patches attached here have similar names to the
originals, but I have re-rolled them against the most recent repo
contents.

Regards,
Malcolm

[Tim Docker]

Malcolm, Eugene,

Apologies for the very belated reply to this.

I have attempted to create a single data type and rendering function for
stacked plots. I hope it meets both your needs, ie:

- allows arbitrary y axis types
- single title, combined legend, etc
- x values plotted with a single x axis for consistency

See the attached patch, including a couple of tests. Let me know if you
think this meets both of your needs, and assuming so, I will promote it.

Cheers,

Tim