Thread: [Ocaml-gnuplot-devel] plotitems, tags and global style setting

Hi ChriS,

> If we move to the
> proposal I made to you (plotitems), the implementation will again
> change a great deal...  BTW, even with plotitems, on could provide
> some kind of tags for the user convenience: these would be plotitems
> that one can manipulate to (1) add other plotitems, (2) delete some
> and, (3) of course, plot them (in the order they were added -- that's
> the convenience).

ON LEVELS OF PLOTITEMS
I think liberating plot-items from style is a good idea
(even if you say it means basically only 'save my data', cause it
creates the plot-item's data-intensive part).
When you associate a plot-item with a viewport and a style, then you create
another object, which you manipulate with the help of tags or the way you like
(as *your* plot-items above).

1. we need a level for the manupulation of plotitems for user's convenience
and for erasure and redraw, replot on a different display.

2. We need a way to be able to reuse the same data in different plots
in different viewports without having to recalculate it.

My idea was to satisfy 1 and 2 by introducing (a) plotitems
(if you like, data uniformly formatted for plotting) which are
independent of display style and display location; and (b)
plotitems which are associated with a style, a viewport (and a tag).
This satisfies 1 and 2 and implementable sg like the way
I proposed last time.

Your idea, as far as I can see is to have only plotitems which
are already styled and manipulate these. This satisfies 1 but
to satisfy 2, one should provide function to change the style
of the plot-item (thereby keep and not recalculate its data-related
content).
However the style of a displayed plotitem cannot be changed, because
the viewport has to remember the correct style (and linewidth) in order
to be able to properly erase a plot. So in this case
second level is needed for the plot-objects stored in tags/whatever.

Alternatively if the change of style parameters is not in situ then it (a) either
involves copying the data-content (violates 2) or (b) sharing the
data-content (which is equivalent to my solution).
So you need (at least) two levels either way.

Maybe you never debated that, in that case it was just a brain exercise
for me to understand things more :-)

STYLE
If you accept that style params like lines/points, width and color
should be simultaneouly specified/absent on a particular level,
then it follows that in the second case global setting of pen may
not be a good idea.
This is because plotitems are in principle handle-independent
(the moment they are styled, they are not associated with a display)
so it would be strange to associate them with a handle only in order to know
which pen to use to color them.

ON TAGS
On your other point about tags vs. just list of styled items given to
the display functions, I don't understand if there is much difference.
a) If we want to be able to redraw viewports automatically (a la the Managed tag)
we can't get away without remembering the styled plots we displayed.
b) If we want to allow the user to control which plotitems are managed
and which aren't we also have to keep the tag states.
For a) and b) it seems reasonable then to keep a history of plots for the viewport:
a set of (styled)plotitems with an info whether they are hidden or displayed and should
be managed or not.
But if plotitems can be sequences of atomic plots, this is equivalent to
having tags. Is it not?

Sorry if this is hasty. Tomorrow I try to reply in detail.

Cheers
Viktor

Hi Viktor,

On Tue, 10 Aug 2004, Viktor Tron <v....@ed...> wrote:
> 
> ON LEVELS OF PLOTITEMS
> I think liberating plot-items from style is a good idea [...]  When
> you associate a plot-item with a viewport and a style, then you
> create another object

I do not really like that idea because it requires an additional step
to be able to plot something.  IMO, if one wants to re-plot the same
data, it is likely to be with the same visual characteristics
(e.g. for a zoom or to compare it with other plots).  It as also good
practice for the one who will interpret the plots because it creates
visual unity.

> 1. we need a level for the manupulation of plotitems for user's
> convenience and for erasure and redraw, replot on a different display.

With plotitems deprived of visual characteristics (e.g. linewidth), we
cannot erase them properly.  So either one has to provide again the
original plotting parameters for erasing (not nice) or to operate at
the level of "decorated plots" (but then what are the "raw plotitems"
good for?).

> 2. We need a way to be able to reuse the same data in different
> plots in different viewports without having to recalculate it.

Like I mentioned a [clone] function would be provided to redecorate a
plot.  I envisioned the possibility that plotitems (here decorated)
could be mutable or not to end up with the conclusion that it is
better they are immutable.  So:

> viewport has to remember the correct style (and linewidth) in order
> to be able to properly erase a plot

becomes a non issue.

> (b) sharing the data-content (which is equivalent to my solution).

Data would obviously be shared (otherwise this discussion does not
make sense).  Sure, this is equivalent to your solution but without
the overhead for the user of the library.  I do not want that
flexibility get in the way of getting simple plots done quickly.

> STYLE
> If you accept that style params like lines/points, width and color
> should be simultaneouly specified/absent on a particular level, then
> it follows that in the second case global setting of pen may not be
> a good idea.

???

> This is because plotitems are in principle handle-independent [...]
> so it would be strange to associate them with a handle only in order
> to know which pen to use to color them.

The [plotitem] type will be independent of [handle].  You are right
though that in order to create a "decorated" [plotitem], a handle will
need to be provided for styles.  Giving the decorations through
optional arguments does not appeal much to me (at present, 6 optional
arguments would be needed for pen, pen_width, point, point_width,
font, font_size).  Needing to provide these arguments again and again
(and also to pass them to functions) seems unpleasant to me.  An
intermediate solution would be to create a [decorations] (independent
of the [handle]) type that would be passed around.  But maybe this is
a bit overkill...

> ON TAGS
> On your other point about tags vs. just list of styled items given to
> the display functions, I don't understand if there is much difference.

There is not.  See below for a more detailed account.

> a) If we want to be able to redraw viewports automatically (a la the
> Managed tag) we can't get away without remembering the styled plots
> we displayed.

[Managed] may disappear.  More precisely, if a user deletes plots, he
has to care whether other plots may be damaged.  However, when e.g. in
autoscale mode we still may need full redraw so in this case we indeed
need to remember.

In order to re-plot we need a (mutable) structure that allows

* [iter]: iteration in the order plots where added;
* [snoc]: adding one more plot at the end;
* [remove]: deleting a given plot (when hiding, may be in the middle);
* [clear]: deleting all the plots (because e.g. of a new page).

Of course, if you explain that it is convenient for animations to have
a [Managed] state, that can be introduced too.  There is one
fundamental difference though: before tags were integers which means
we had to keep all plots for the viewport (even hidden) for fear they
would be re-plotted.  Now, only visible plots will be hold.  If the
user wants to re-plot a previously hidden tag, the tag itself (of type
[plotitem]) will hold the (shared) data.  If the tag becomes
inaccessible (and no other plot/tag uses the same data), the plot data
will be deleted.

> But if plotitems can be sequences of atomic plots, this is
> equivalent to having tags. Is it not?

Exactly.  Like you said, the user can do that easily with lists.  But
since we need anyway to have a module with the above functions, it may
be convenient to expose them for the user.  An additional benefit is
that groups of plots created with these functions would themselves be
of type [plotitem] thus allowing easy group manipulations.  Functions
like [show] would still take a list of plotitems because it is heavy
to group plots in such a way if one does not need to manipulate the
group later.

ChriS

On Wed, 11 Aug 2004 16:03:33 +0200 (CEST), Christophe TROESTLER <chr...@us...> wrote:

> Hi Viktor,
>
> On Tue, 10 Aug 2004, Viktor Tron <v....@ed...> wrote:
>>
>> ON LEVELS OF PLOTITEMS
>> I think liberating plot-items from style is a good idea [...]  When
>> you associate a plot-item with a viewport and a style, then you
>> create another object
>
> I do not really like that idea because it requires an additional step
> to be able to plot something.  IMO, if one wants to re-plot the same
> data, it is likely to be with the same visual characteristics
> (e.g. for a zoom or to compare it with other plots).

Well, maybe you are right.

> It as also good
> practice for the one who will interpret the plots because it creates
> visual unity.

??

>> 1. we need a level for the manupulation of plotitems for user's
>> convenience and for erasure and redraw, replot on a different display.
>
> With plotitems deprived of visual characteristics (e.g. linewidth), we
> cannot erase them properly.  So either one has to provide again the
> original plotting parameters for erasing (not nice) or to operate at
> the level of "decorated plots" (but then what are the "raw plotitems"
> good for?).
>
>> 2. We need a way to be able to reuse the same data in different
>> plots in different viewports without having to recalculate it.
>
> Like I mentioned a [clone] function would be provided to redecorate a
> plot.  I envisioned the possibility that plotitems (here decorated)
> could be mutable or not to end up with the conclusion that it is
> better they are immutable.  So:
>
>> viewport has to remember the correct style (and linewidth) in order
>> to be able to properly erase a plot
>
> becomes a non issue.
>
>> (b) sharing the data-content (which is equivalent to my solution).
>
> Data would obviously be shared (otherwise this discussion does not
> make sense).  Sure, this is equivalent to your solution but without
> the overhead for the user of the library.  I do not want that
> flexibility get in the way of getting simple plots done quickly.

I cannot tell yet, which one is more simple (see the problem with styles).

>> STYLE
>> If you accept that style params like lines/points, width and color
>> should be simultaneouly specified/absent on a particular level, then
>> it follows that in the second case global setting of pen may not be
>> a good idea.
>
> ???
>
>> This is because plotitems are in principle handle-independent [...]
>> so it would be strange to associate them with a handle only in order
>> to know which pen to use to color them.
>
> The [plotitem] type will be independent of [handle].  You are right
> though that in order to create a "decorated" [plotitem], a handle will
> need to be provided for styles.

which is not good.

> Giving the decorations through
> optional arguments does not appeal much to me (at present, 6 optional
> arguments would be needed for pen, pen_width, point, point_width,
> font, font_size).  Needing to provide these arguments again and again
> (and also to pass them to functions) seems unpleasant to me.

I agree, especially, that this has to be rewrittem each time we introduce new
style dimensions.

> An
> intermediate solution would be to create a [decorations] (independent
> of the [handle]) type that would be passed around.  But maybe this is
> a bit overkill...

This is the only 'normal' solution I can see at the moment.

>> ON TAGS
>> On your other point about tags vs. just list of styled items given to
>> the display functions, I don't understand if there is much difference.
>
> There is not.  See below for a more detailed account.
>
>> a) If we want to be able to redraw viewports automatically (a la the
>> Managed tag) we can't get away without remembering the styled plots
>> we displayed.
>
> [Managed] may disappear.  More precisely, if a user deletes plots, he
> has to care whether other plots may be damaged.  However, when e.g. in
> autoscale mode we still may need full redraw so in this case we indeed
> need to remember.
>
> In order to re-plot we need a (mutable) structure that allows

It has to be mutable since they are remembered by viewports?

> * [iter]: iteration in the order plots where added;
> * [snoc]: adding one more plot at the end;
> * [remove]: deleting a given plot (when hiding, may be in the middle);
> * [clear]: deleting all the plots (because e.g. of a new page).

Sounds ok now.

> Of course, if you explain that it is convenient for animations to have
> a [Managed] state, that can be introduced too.  There is one
> fundamental difference though: before tags were integers which means
> we had to keep all plots for the viewport (even hidden) for fear they
> would be re-plotted.  Now, only visible plots will be hold.  If the
> user wants to re-plot a previously hidden tag, the tag itself (of type
> [plotitem]) will hold the (shared) data.  If the tag becomes
> inaccessible (and no other plot/tag uses the same data), the plot data
> will be deleted.

This whole thing look quite appealing, but a difference to what I proposed is that now.
the same decorated plotitems can be plotted on two viewports.
And if it is removed from one of them, then we shouldn't delete the data (cause it may need
to replot on another). But the data is not 'shared' between two plotitems but it
is the very same plotitem (included in the viewport's history).
The general problem is that we don't only need to keep track of (refcount?) shared data
every time a plotitem is cloned but also every time it is displayed.
(and I haven't even thought of having the same plotitem twice on the plotlist of one
viewport).
This is surely only a problem if we want to close (and delete) our temp files.
Can the garbage collector not be said to do special destroy operations before
freeing a (our special type of) filehandle?
Sorry if I sound like coming from the moon...

If you think we can solve this, I am generally very simpathetic with this design.

Sum:
- plot items created with decoration from the start
- plotitems with immutable style attributes.
- cloning a plotitem with data sharing possibility and changing style (cloning is a bad name then :-)
Problems:
- how exactly styles are passed (specified) independent of handle and wihtout
annoying hundreds of optional args: [decoration] type.
- how can we determine if (shared) data can be destroyed?

Best
Viktor




>
>> But if plotitems can be sequences of atomic plots, this is
>> equivalent to having tags. Is it not?
>
> Exactly.  Like you said, the user can do that easily with lists.  But
> since we need anyway to have a module with the above functions, it may
> be convenient to expose them for the user.  An additional benefit is
> that groups of plots created with these functions would themselves be
> of type [plotitem] thus allowing easy group manipulations.  Functions
> like [show] would still take a list of plotitems because it is heavy
> to group plots in such a way if one does not need to manipulate the
> group later.
>
> ChriS
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Ocaml-gnuplot-devel mailing list
> Oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-gnuplot-devel

Hi Viktor,

Good to read you again!

On Thu, 12 Aug 2004, Viktor Tron <v....@ed...> wrote:
> 
> On Wed, 11 Aug 2004 16:03:33 +0200 (CEST), Christophe TROESTLER <chr...@us...> wrote:
> 
> > It as also good practice for the one who will interpret the plots
> > because it creates visual unity.
> ??

What I meant is that by default pltting the same data with the same
style is what an author should want because the style will be the
visual identity of the data across possibly different plots.
Therefore, plotting-data-with-the-same-style should be straightforward
while one can require a bit more verbosity for style changes.

> > An intermediate solution would be to create a [decorations]
> > (independent of the [handle]) type that would be passed around.
> > But maybe this is a bit overkill...
> 
> This is the only 'normal' solution I can see at the moment.

So let's dig a bit more that idea.  The good side is more referential
transparency and the fact that one can now add an optional argument to
[tics], [border],... to easily set their style (it was possible but
maybe a bit cumbersome before).  The problem is: how do we create
these and are they mutable?  Do we write

  let st = P.pen ~st 3 in

(where [st] is an optioal argument that defaults to a "default style"
-- thus allowing the creation of new styles without needing new
commands) or

  P.pen st 3

which requires a [let st = Style.create() in] to be issued before?

> >> ON TAGS
> It has to be mutable since they are remembered by viewports?

Yes.  If it is not mutable, viewports will have to replace the old
plotitem list by the new one.

> This whole thing look quite appealing, but a difference to what I
> proposed is that now.  the same decorated plotitems can be plotted
> on two viewports.  And if it is removed from one of them, then we
> shouldn't delete the data (cause it may need to replot on another).

That's right but in order to be able to replot the data, the handle
will keep a "reference" to it so it (or its name in case of files)
will still be accessible (hidden in the [handle] data-structure).

> But the data is not 'shared' between two plotitems but it is the
> very same plotitem (included in the viewport's history).

The point is: the data is reachable.  If you read the info for
[Gc.finalise], you will see that in order for the finalisation
function to be called, the value must become unreachable first.  The
idea is to use the data string (or the filename string) as the
finaliser holder.

There is a difficulty though.  The data is not linked anymore to
session [handle]s, so when a session closes, one cannot remove the
data files.  Thus a cleaning function will need to be registered
[at_exit].  But the problem is that we cannot use a global
data-structure (or else with mutexes) since I want the library to be
thread safe...  But maybe a global variable with mutexes is the way to
go because one would also like to create new directories every 10000
files or such for speed (worth of that to be confirmed).

ChriS