From: Brendon H. <blh...@gm...> - 2008-04-18 03:11:51
|
Hello, I'm relatively new to PyX, so forgive me if this has been addressed before, however my searches through the manual, examples, FAQ, and lists were fruitless. Is there a way to specify the plot drawing order independent of the ordering of the entries in the generated key? Here's my situation: I build a plot that has lines (theory calculations) and symbols (experimental data) with error bars on the symbols, for two different sets of data (two different "configurations" of the experiment), on the same graph. First, I'd like the symbols to be drawn overtop of the lines, but on the key, the experimental symbols to be present before the theory lines. I'd also like one configuration to appear before the other in the key, but also for its symbols/lines to be plotted on top of the other pair. As far as I can see, the current status is that key entries appear in the order reverse of that of the most "forward" plot; i.e. first drawn plot gets first place in the key, last drawn plot (overdrawing all other plots) gets last place in the key. This is (in reality not quite) the exact opposite of the order that I'd like. Thus my question: how can I change the ordering of the key without changing the order in which the data is plotted? Is this even possible? (Please tell me it is, somehow. I'm not afraid of digging into PyX code if I have to. ;-) ) For the record, I aim to patch PyXPlot to support this, if it turns out to be possible. Peace, Brendon |
From: Stefan S. <Ste...@ph...> - 2008-04-18 06:26:09
|
Hi, Am Freitag 18 April 2008 05:13 schrieb Brendon Higgins: > Thus my question: how can I change the ordering of the key without > changing the order in which the data is plotted? Is this even possible? > (Please tell me it is, somehow. I'm not afraid of digging into PyX code > if I have to. ;-) ) I'm not sure if this is the most elegant way in PyX, but the following seems to work. from pyx import * g = graph.graphxy(width=8) a = g.plot(graph.data.function("y(x)=sin(x)/x", min=-15, max=15), [graph.style.line([color.cmyk.Red, style.linestyle.dashed])]) b = g.plot(graph.data.function("y(x)=sin(x)/x", min=-15, max=15), [graph.style.line([color.cmyk.Black, style.linestyle.solid])]) g.doplot(b) g.doplot(a) g.writeEPSfile("function") Greetings, Stefan Schenk |
From: Brendon H. <blh...@gm...> - 2008-04-21 04:35:37
Attachments:
pyxkeyitemorder.patch
|
Stefan Schenk wrote (Fri, 18 Apr 2008): > Am Freitag 18 April 2008 05:13 schrieb Brendon Higgins: > > Thus my question: how can I change the ordering of the key without > > changing the order in which the data is plotted? Is this even possible? > > (Please tell me it is, somehow. I'm not afraid of digging into PyX code > > if I have to. ;-) ) > > I'm not sure if this is the most elegant way in PyX, but the following > seems to work. > > [snip] Thanks, Stefan. It works, but unfortunately what you suggested isn't suitable for where I want to put it. There doesn't seem to be an elegant way to solve this problem. So I patched key.py to take a new parameter in the constructor: a list of numbers indicating the zero-indexed order (itemorder). It will then use these to reorder the plotitems list in the paint method. It *might* be a little rough around the edges, considering I'm not too familiar with the code, but it's a pretty small change, and it seems to work. I'd appreciate it if the developers might take a look. Peace, Brendon |
From: Michael J G. <mic...@fa...> - 2008-04-21 14:36:14
|
Brendon Higgins venit, vidit, dixit 21.04.2008 06:36: > Stefan Schenk wrote (Fri, 18 Apr 2008): >> Am Freitag 18 April 2008 05:13 schrieb Brendon Higgins: >>> Thus my question: how can I change the ordering of the key without >>> changing the order in which the data is plotted? Is this even possible? >>> (Please tell me it is, somehow. I'm not afraid of digging into PyX code >>> if I have to. ;-) ) >> I'm not sure if this is the most elegant way in PyX, but the following >> seems to work. >> >> [snip] > > Thanks, Stefan. It works, but unfortunately what you suggested isn't suitable > for where I want to put it. > > There doesn't seem to be an elegant way to solve this problem. So I patched > key.py to take a new parameter in the constructor: a list of numbers > indicating the zero-indexed order (itemorder). It will then use these to > reorder the plotitems list in the paint method. > > It *might* be a little rough around the edges, considering I'm not too > familiar with the code, but it's a pretty small change, and it seems to work. > I'd appreciate it if the developers might take a look. > > Peace, > Brendon > + iorder = [i for i in self.itemorder if 0 <= i and i < len(plotitems)] # ignore ordering indices that are out of range > + plotitems = [plotitems[i] for i in iorder] + plotitems[len(iorder):] # reorder the items It seems you require the itemorder parameter to have a certain form (being a permutation of the first n non-negative integers) which you don't check: Imagine you have 2 plotitems and itemorder = [1]. This results in iorder=[1]. On the right hand side of the second assignment, you will get the following list: [ plotitems[1], plotitems[1] ] This is certainly not what you want. The above code works (gives a permutation of the list items) if, e.g., you require itemorder to be a permutation of the the first few consecutive non-neg. ints. You can check this by checking for set(iorder) == set(range(len(iorder))) after the consistency check that you have already. (This also invalidates input args like [1,1].) An alternative might be: plotitems = [plotitems[i] for i in iorder] + [plotitems[i] for i in set(range(len(plotitems)))-set(iorder)] This would not require the above check. I'm not sure how expensive set operations are, though. Cheers, Michael |
From: Alan G I. <ai...@am...> - 2008-04-21 15:06:29
|
My guess we be that plotitems should have a zorder attribute with a default setting, and that they should be reordered by a stable sort. But I would hope that rather than reinvent the wheel, a successful implementation would be examined. How does Matplotlib handle this? Cheers, Alan Isaac |
From: André W. <wo...@us...> - 2008-04-21 21:42:13
|
Dear all, it's an interesting discussion. However, I'm against any kind of integer defining the ordering. What ordering. The plot ordering? The ordering in the graph key? What else we may think of? The ordering in the changeable attributes? So I'm about to reject anything like a zorder-graph-key attribute in the plotitem or a list of indices of the plotitems to be passed to the graph key. I very much like the possibility using g.doplot(plotitem) introduced (by user request! in PyX 0.10). We clearly should have that for the graph keys as well. As this is trivial to implement, I just did so. See changeset 2983. The only problem I do have is with the naming. We do have g.dodata() and g.doplot(plotitem) and now g.dokey() and g.dokeyitem(plotitem), which are similar in what they supposed to do. However, they are named very differently. Obviously we could rename g.dodata() to g.doplot() and g.doplot(plotitem) to g.doplotitem(plotitem). I guess most of you will complain -- still, I think this change becomes necessary. Any thought? André Am 21.04.2008 um 17:09 schrieb Alan G Isaac: > My guess we be that plotitems should have a zorder > attribute with a default setting, and that they > should be reordered by a stable sort. > > But I would hope that rather than reinvent the wheel, > a successful implementation would be examined. > How does Matplotlib handle this? > > Cheers, > Alan Isaac > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > PyX-user mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-user > -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Joerg L. <jo...@us...> - 2008-04-21 21:55:48
|
Hi André, On 21.04.08, André Wobst wrote: > I very much like the possibility using g.doplot(plotitem) introduced > (by user request! in PyX 0.10). We clearly should have that for the > graph keys as well. As this is trivial to implement, I just did so. > See changeset 2983. +1 > The only problem I do have is with the naming. We do have g.dodata() > and g.doplot(plotitem) and now g.dokey() and g.dokeyitem(plotitem), > which are similar in what they supposed to do. However, they are named > very differently. Obviously we could rename g.dodata() to g.doplot() > and g.doplot(plotitem) to g.doplotitem(plotitem). I guess most of you > will complain -- still, I think this change becomes necessary. Any > thought? Makes sense, I would add a deprecation warning, though, at least for the dodata call. It has been documented in the examples for quite some time and it's also obscure enough to confuse people if it does not exist anymore. Jörg |
From: Michael S. <m-s...@us...> - 2008-04-21 23:02:02
|
Hello André, On 21.04.08, Joerg Lehmann wrote: > On 21.04.08, André Wobst wrote: > > I very much like the possibility using g.doplot(plotitem) introduced > > (by user request! in PyX 0.10). We clearly should have that for the > > graph keys as well. As this is trivial to implement, I just did so. > > See changeset 2983. > > +1 +1 also from me for this type of solution. > > The only problem I do have is with the naming. We do have g.dodata() > > and g.doplot(plotitem) and now g.dokey() and g.dokeyitem(plotitem), > > which are similar in what they supposed to do. However, they are named > > very differently. Obviously we could rename g.dodata() to g.doplot() > > and g.doplot(plotitem) to g.doplotitem(plotitem). I guess most of you > > will complain -- still, I think this change becomes necessary. Any > > thought? It is good to be consequent here. However, being really consequent, the whole graph/plot naming comes into question. A "graph" in mathematical terminology is the graphical representation of a function or the solution of an equation. In my personal naming scheme what is a "graph" in PyX would rather be a figure or a plot. Then, one would create a graph in a plot and not plot in a graph, as it is at the moment. ;-) Just a nightly thought. Michael |
From: André W. <wo...@us...> - 2008-04-22 08:11:31
|
Hi Michael, Am 22.04.2008 um 01:01 schrieb Michael SCHINDLER: > It is good to be consequent here. However, being really consequent, > the whole graph/plot naming comes into question. A "graph" in > mathematical terminology is the graphical representation of a function > or the solution of an equation. In my personal naming scheme what is a > "graph" in PyX would rather be a figure or a plot. Then, one would > create a graph in a plot and not plot in a graph, as it is at the > moment. ;-) Just a nightly thought. This would be very disruptive. We should not do that without a lengthly discussion. For the moment a historic note you may not be aware of as you started with PyX without the pre-PyX-phase at Uni Augsburg. We have been gle users (http://glx.sourceforge.net) where you have begin graph / end graph blocks. Maybe a native speaker wants to comment this. André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Alan G I. <ai...@am...> - 2008-04-22 14:05:08
|
> Michael wrote: >> In my personal naming scheme what is a "graph" in PyX >> would rather be a figure or a plot. Then, one would >> create a graph in a plot and not plot in a graph, as it >> is at the moment. On Tue, 22 Apr 2008, André Wobst apparently wrote: > This would be very disruptive. We should not do that without a > lengthly discussion. For the moment a historic note you may not be > aware of as you started with PyX without the pre-PyX-phase at Uni > Augsburg. We have been gle users (http://glx.sourceforge.net) where > you have begin graph / end graph blocks. > Maybe a native speaker wants to comment this. Both ways of speaking are possible, unfortunately. Verbs: plot, graph, chart, diagram Nouns: plot, graph, chart, diagram Exceptions (nouns only): figure, canvas I would say that 'figure' is the most general term for a canvas+drawing. After that comes chart, and then graph. I call a figure by other names depending on what I draw on it. If I plot/graph a function (with axes), I create a graph containing one plot. If I plot/graph another function, I add one more plot to this graph. Of course it is true that this plot is a visual representation of part of the graph of the function, using math terminology. But it would sound very odd to say that I add one more graph to this plot. So I cannot agree with Michael. Cheers, Alan Isaac |
From: Alan G I. <ai...@am...> - 2008-04-22 01:19:08
|
On Mon, 21 Apr 2008, André Wobst apparently wrote: > Any thought? Sooner is better than later. :-) Cheers, Alan Isaac |
From: André W. <wo...@us...> - 2008-04-22 07:59:21
|
Am 22.04.2008 um 03:22 schrieb Alan G Isaac: > On Mon, 21 Apr 2008, André Wobst apparently wrote: >> Any thought? > > Sooner is better than later. :-) -> today. (changeset 2985) André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: André W. <wo...@us...> - 2008-04-22 23:33:23
|
Alan, Am 22.04.2008 um 16:08 schrieb Alan G Isaac: > ... > If I plot/graph a function (with axes), I create a graph containing > one plot. > If I plot/graph another function, I add one more plot to this graph. > ... So the naming we're currently using does make sense and it does not break regular english wording. Thanks a lot for your answer! André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: William H. <w.h...@as...> - 2008-04-23 00:47:30
|
On Tue, Apr 22, 2008 at 6:33 PM, André Wobst <wo...@us...> wrote: > Alan, > > Am 22.04.2008 um 16:08 schrieb Alan G Isaac: > > ... > > > If I plot/graph a function (with axes), I create a graph containing > > one plot. > > If I plot/graph another function, I add one more plot to this graph. > > ... > > So the naming we're currently using does make sense and it does not > break regular english wording. > > Thanks a lot for your answer! > Just to add an extra data point from a native English speaker... I generally agree with Alan. The current terminology used by PyX is perfectly fine. A graph in the coloquial scientific sense would include the axes, labels, and (optionally) key, as does pyx.graph.graphxy. Wikipedia also gives this as the first meaning (among many) of "graph", which is described under the main heading of "chart". A graph in this sense may contain visualizations (via lines, points, or whatever) of one or more discrete datasets or continuous functions. A figure may consist of more than one graph (for example, inset or side-by-side). In PyX, a figure would just be an instance of pyx.canvas I think that Michael's strict mathematical interpretation of the word "graph" is not a common one (at least among scientists). HTH Will -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia |