Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Alan G Isaac <aisaac@am...>  20060224 21:36:33

On Thu, 23 Feb 2006, Andre Wobst apparently wrote: > The bar style needs a bar position as provided by the > barpos style. Unfortunately this style by default always > start bars at the baseline. Perfect fix. But the default is verys surprising. Cheers, Alan Isaac 
From: Markus Meyer <meyer@me...>  20060223 13:58:38

Hi list, I'd like to have a bargraph which has a line for y=0 in the middle, and bars above and under the line. However, a small test for this functionality looks totally wrong. What gives? from pyx import * g = graph.graphxy(width=8, x=graph.axis.bar()) g.plot(graph.data.list([(0,2), (1, 3), (2, 5), (3, 4)], xname=0, y=2), [graph.style.bar()]) g.writePDFfile("bar") Markus 
From: Andre Wobst <wobsta@us...>  20060223 14:10:31

Hi Markus, On 23.02.06, Markus Meyer wrote: > I'd like to have a bargraph which has a line for y=0 in the middle, and > bars above and under the line. However, a small test for this > functionality looks totally wrong. What gives? The bar style needs a bar position as provided by the parpos style. Unfortunately this style by default always start bars at the baseline. Thus you have to do: > from pyx import * > > g = graph.graphxy(width=8, x=graph.axis.bar()) > g.plot(graph.data.list([(0,2), (1, 3), (2, 5), (3, 4)], xname=0, y=2), > [graph.style.bar()]) [graph.style.barpos(fromvalue=0), graph.style.bar()]) > g.writePDFfile("bar") HTH, André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Markus Meyer <meyer@me...>  20060223 15:11:25

Andre Wobst schrieb: >Hi Markus, > >On 23.02.06, Markus Meyer wrote: > > >>I'd like to have a bargraph which has a line for y=0 in the middle, and >>bars above and under the line. However, a small test for this >>functionality looks totally wrong. What gives? >> >> > >The bar style needs a bar position as provided by the parpos style. >Unfortunately this style by default always start bars at the baseline. > > Works like a charm, thank you! Another question: I want to add a custom axis to the bar graph, so that the axis shows a continuous value and not the bar's names. I tried the following: from pyx import * import random g = graph.graphxy(width=8, x=graph.axis.bar(painter=None), x3=graph.axis.lin(min=0, max=10, title="$t [s]$")) g.plot(graph.data.list([(i,random.random()) for i in xrange(0,20)], xname=0, y=2), [graph.style.bar()]) g.writePDFfile("bar") Can I change this so the x3 axis is drawn where normally the bar axis would be? TIA Markus 
From: Andre Wobst <wobsta@us...>  20060223 15:34:36

On 23.02.06, Markus Meyer wrote: > Another question: I want to add a custom > axis to the bar graph, so that the axis shows a continuous value and not > the bar's names. I tried the following: > > from pyx import * > import random > > g = graph.graphxy(width=8, > x=graph.axis.bar(painter=None), > x3=graph.axis.lin(min=0, max=10, title="$t [s]$")) > g.plot(graph.data.list([(i,random.random()) for i in xrange(0,20)], > xname=0, y=2), [graph.style.bar()]) > g.writePDFfile("bar") > > Can I change this so the x3 axis is drawn where normally the bar axis > would be? The distances between axes is a global graph property. (Maybe that's a bad decision and should be changed, but it's this way ever since I started the graph module (really a long time ago) and nobody *ever* complained so far.) So just add "axesdist=0" to the graph constructor and be happy ... ;) BTW: You will not get a linked axis x4 (containing the ticks). Unfortunately where is no easy way in PyX 0.8.1 (and below) to do this, but in the current CVS head we can easily create all kind of linked axes within a graph, cyclic between graphs etc. Another note: I urgently request you do differentiate between bar graphs and histograms. Bar graphs "live" on a discrete axis and histograms on a continuous axis. While we didn't had a histrogram style for some time while already having bar graphs, people started to missuse bar graphs for histograms. It works in the sense that you can create whatever output you want, but I don't like it at all. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Alan G Isaac <aisaac@am...>  20060224 21:36:33

On Thu, 23 Feb 2006, Andre Wobst apparently wrote: > The bar style needs a bar position as provided by the > barpos style. Unfortunately this style by default always > start bars at the baseline. Perfect fix. But the default is verys surprising. Cheers, Alan Isaac 
From: Gary <pajer@in...>  20060226 16:40:40

Newbie, here. Consider the script below. I expected the second line, the one to x1,y1, to hit the circle due west of center. When I run the script, the end of the line is far above the circle. What am I misunderstanding? Also, let me know if there is a more elegant syntax. thanks, gary  from pyx import * from math import pi c = canvas.canvas() circle = path.circle(2,2,.2) x, y = circle.at(0.) x1, y1 = circle.at(pi) c.stroke(path.path(path.moveto(0,0), path.lineto(x, y))) c.stroke(path.path(path.moveto(0,0), path.lineto(x1, y1))) c.stroke(circle) c.writeEPSfile("test") 
From: Michael Schindler <mschindler@us...>  20060226 17:02:27

Hello Gary, On 26.02.06, Gary wrote: > Consider the script below. I expected the second line, the one to > x1,y1, to hit the circle due west of center. When I run the script, the > end of the line is far above the circle. > > What am I misunderstanding? > > Also, let me know if there is a more elegant syntax. > > thanks, > gary > >  > from pyx import * > from math import pi > > c = canvas.canvas() > > circle = path.circle(2,2,.2) > > x, y = circle.at(0.) > x1, y1 = circle.at(pi) The circle is a general path at this point, thus not parameterised by an angle but by either the arclength or by the generic parameters of the Bezier curves it consists of. What happened, is that the "arclength" 3.1415 you inserted above, is bigger than the total arclength of 1.25 of the circle. Therefore, you get a point that is extrapolated from the very last path element the circle consists of (This is probably a short closing line) This is what you wanted: x, y = circle.at(0.) x1, y1 = circle.at(0.5*circle.arclen()) because the standard parameterisation is in arclength. > c.stroke(path.path(path.moveto(0,0), path.lineto(x, y))) > c.stroke(path.path(path.moveto(0,0), path.lineto(x1, y1))) > c.stroke(circle) > > c.writeEPSfile("test") > Best, Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Alan G Isaac <aisaac@am...>  20060226 18:09:34

On Sun, 26 Feb 2006, Michael Schindler apparently wrote: > What happened, is that the "arclength" 3.1415 you inserted > above, is bigger than the total arclength of 1.25 of the > circle. Therefore, you get a point that is extrapolated > from the very last path element the circle consists of > (This is probably a short closing line) This might best, but with circles I guess I would have expected to wrap around (mod arclength). > This is what [Gary] wanted: > x, y = circle.at(0.) > x1, y1 = circle.at(0.5*circle.arclen()) > because the standard parameterisation is in arclength. Suggestion: a convenience method 'at_degress' or 'at_radians' for circles. (Might be nice for arcs too ...) Cheers, Alan Isaac 
From: Gary <pajer@in...>  20060226 18:28:49

Michael Schindler wrote: >Hello Gary, > >On 26.02.06, Gary wrote: > > >>Consider the script below. I expected the second line, the one to >>x1,y1, to hit the circle due west of center. When I run the script, the >>end of the line is far above the circle. >> >>What am I misunderstanding? >> >>Also, let me know if there is a more elegant syntax. >> >>thanks, >>gary >> >> >>from pyx import * >>from math import pi >> >>c = canvas.canvas() >> >>circle = path.circle(2,2,.2) >> >>x, y = circle.at(0.) >>x1, y1 = circle.at(pi) >> >> > >The circle is a general path at this point, thus not parameterised by >an angle but by either the arclength or by the generic parameters of >the Bezier curves it consists of. > >What happened, is that the "arclength" 3.1415 you inserted above, is >bigger than the total arclength of 1.25 of the circle. Therefore, you >get a point that is extrapolated from the very last path element the >circle consists of (This is probably a short closing line) > >This is what you wanted: >x, y = circle.at(0.) >x1, y1 = circle.at(0.5*circle.arclen()) >because the standard parameterisation is in arclength. > > Thank you. Ok, now a few things are falling into place, in particular the discussion of parameters in http://pyx.sourceforge.net/manual/node7.html I understand things a little better now (still more to grok). Does every path have an arclength? Even a compound path? I suppose so, since the circle is a compound path. I think that my confusion was caused in part by the fact that the example at the end of http://pyx.sourceforge.net/manual/node7.html uses a unit circle, so the arclength equals the angle. > > >>c.stroke(path.path(path.moveto(0,0), path.lineto(x, y))) >>c.stroke(path.path(path.moveto(0,0), path.lineto(x1, y1))) >>c.stroke(circle) >> >>c.writeEPSfile("test") >> >> >> > >Best, > Michael. > > > 
From: Joerg Lehmann <joergl@us...>  20060226 19:15:10

Hello Gary, On 26.02.06, Gary wrote: > Does every path have an arclength? Even a compound path? I suppose so, > since the circle is a compound path. Yes, every path has an arclength. > I think that my confusion was caused in part by the fact that the > example at the end of > http://pyx.sourceforge.net/manual/node7.html > uses a unit circle, so the arclength equals the angle. Ok, I generalized the example a little bit to prevent future confusion Thanks for the feedback, Jörg 
Sign up for the SourceForge newsletter:
No, thanks