Thread: [Ocaml-gnuplot-devel] plotitems, tags and global style setting
Status: Beta
Brought to you by:
chris_77
From: Viktor T. <v....@ed...> - 2004-08-10 17:57:03
|
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 |
From: Christophe T. <chr...@us...> - 2004-08-11 14:04:00
|
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 |
From: Viktor T. <v....@ed...> - 2004-08-12 14:48:09
|
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 |
From: Christophe T. <chr...@us...> - 2004-08-12 16:52:42
|
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 |