From: Andrea Riciputi <ariciputi@pi...>  20050124 11:31:47

Hi, I was trying a simple plot, when I realized that PyX doesn't allow to plot horizontal line expressed as analitic function. Here it is a simple example: > In [197]: h = pyx.graph.graphxy(width = 10, height = 10, x = > pyx.graph.axis.lin(min = 0, max = 10), y = pyx.graph.axis.lin(min = 0, > max = 10)) > > In [198]: h.plot(pyx.graph.data.function("y = x")) > Out[198]: <pyx.graph.graph.plotitem instance at 0x6e80558> > > In [199]: h.plot(pyx.graph.data.function("y = 2")) >  >  > ValueError Traceback (most recent call > last) > > /Users/andrea/Documents/Dottorato/Working/<console> > > /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in plot(self, data, > styles) > 231 plotitems = [] > 232 for d in usedata: > > 233 plotitems.append(plotitem(self, d, styles)) > 234 self.plotitems.extend(plotitems) > 235 if singledata: > > /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in __init__(self, > graph, data, styles) > 170 > 171 # perform setcolumns to all styles > > 172 self.data.initplotitem(self, graph) > 173 columns = self.data.getcolumnnames(self) > 174 usedcolumns = [] > > /sw/lib/python2.3/sitepackages/pyx/graph/data.py in > initplotitem(self, plotitem, graph) > 617 raise ValueError("multiple variables > found") > 618 if self.xname is None: > > 619 raise ValueError("no variable found") > 620 plotitem.columns = {self.xname: 0, self.yname: 1} > 621 > > ValueError: no variable found There is a trick that I can use to get the desired result? Could this feature be embeded in a future version of PyX? Thanks, Andrea. 
From: Markus Meyer <meyer@me...>  20050124 11:42:51

Sorry, OT, but how do you get that cool stack trace with values in it and context information? My Python 2.4 / Linux just shows very limited information in a stack trace. Markus Andrea Riciputi schrieb: > Hi, > I was trying a simple plot, when I realized that PyX doesn't allow to > plot horizontal line expressed as analitic function. Here it is a > simple example: > >> In [197]: h = pyx.graph.graphxy(width = 10, height = 10, x = >> pyx.graph.axis.lin(min = 0, max = 10), y = pyx.graph.axis.lin(min = >> 0, max = 10)) >> >> In [198]: h.plot(pyx.graph.data.function("y = x")) >> Out[198]: <pyx.graph.graph.plotitem instance at 0x6e80558> >> >> In [199]: h.plot(pyx.graph.data.function("y = 2")) >>  >>  >> ValueError Traceback (most recent >> call last) >> >> /Users/andrea/Documents/Dottorato/Working/<console> >> >> /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in plot(self, >> data, styles) >> 231 plotitems = [] >> 232 for d in usedata: >> > 233 plotitems.append(plotitem(self, d, styles)) >> 234 self.plotitems.extend(plotitems) >> 235 if singledata: >> >> /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in __init__(self, >> graph, data, styles) >> 170 >> 171 # perform setcolumns to all styles >> > 172 self.data.initplotitem(self, graph) >> 173 columns = self.data.getcolumnnames(self) >> 174 usedcolumns = [] >> >> /sw/lib/python2.3/sitepackages/pyx/graph/data.py in >> initplotitem(self, plotitem, graph) >> 617 raise ValueError("multiple variables >> found") >> 618 if self.xname is None: >> > 619 raise ValueError("no variable found") >> 620 plotitem.columns = {self.xname: 0, self.yname: 1} >> 621 >> >> ValueError: no variable found > > > There is a trick that I can use to get the desired result? Could this > feature be embeded in a future version of PyX? > > Thanks, > Andrea. > > > >  > This SF.Net email is sponsored by: IntelliVIEW  Interactive Reporting > Tool for open source databases. Create drag&drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > PyXuser mailing list > PyXuser@... > https://lists.sourceforge.net/lists/listinfo/pyxuser > 
From: Andrea Riciputi <ariciputi@pi...>  20050124 11:50:19

Simple, use IPython. It is invaluable!! Look at: <http://ipython.scipy.org/>; Cheers, Andrea. On 24 Jan 2005, at 12:47, Markus Meyer wrote: > Sorry, OT, but how do you get that cool stack trace with values in it > and context information? My Python 2.4 / Linux just shows very limited > information in a stack trace. > > > Markus > > > Andrea Riciputi schrieb: > >> Hi, >> I was trying a simple plot, when I realized that PyX doesn't allow to >> plot horizontal line expressed as analitic function. Here it is a >> simple example: >> >>> In [197]: h = pyx.graph.graphxy(width = 10, height = 10, x = >>> pyx.graph.axis.lin(min = 0, max = 10), y = pyx.graph.axis.lin(min = >>> 0, max = 10)) >>> >>> In [198]: h.plot(pyx.graph.data.function("y = x")) >>> Out[198]: <pyx.graph.graph.plotitem instance at 0x6e80558> >>> >>> In [199]: h.plot(pyx.graph.data.function("y = 2")) >>>  >>>   >>> ValueError Traceback (most recent >>> call last) >>> >>> /Users/andrea/Documents/Dottorato/Working/<console> >>> >>> /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in plot(self, >>> data, styles) >>> 231 plotitems = [] >>> 232 for d in usedata: >>> > 233 plotitems.append(plotitem(self, d, styles)) >>> 234 self.plotitems.extend(plotitems) >>> 235 if singledata: >>> >>> /sw/lib/python2.3/sitepackages/pyx/graph/graph.py in __init__(self, >>> graph, data, styles) >>> 170 >>> 171 # perform setcolumns to all styles >>> > 172 self.data.initplotitem(self, graph) >>> 173 columns = self.data.getcolumnnames(self) >>> 174 usedcolumns = [] >>> >>> /sw/lib/python2.3/sitepackages/pyx/graph/data.py in >>> initplotitem(self, plotitem, graph) >>> 617 raise ValueError("multiple variables >>> found") >>> 618 if self.xname is None: >>> > 619 raise ValueError("no variable found") >>> 620 plotitem.columns = {self.xname: 0, self.yname: 1} >>> 621 >>> >>> ValueError: no variable found >> >> >> There is a trick that I can use to get the desired result? Could this >> feature be embeded in a future version of PyX? >> >> Thanks, >> Andrea. >> >> >> >>  >> This SF.Net email is sponsored by: IntelliVIEW  Interactive >> Reporting >> Tool for open source databases. Create drag&drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> PyXuser mailing list >> PyXuser@... >> https://lists.sourceforge.net/lists/listinfo/pyxuser >> > 
From: Joerg Lehmann <joergl@us...>  20050124 11:43:37

On 24.01.05, Andrea Riciputi wrote: > Hi, > I was trying a simple plot, when I realized that PyX doesn't allow to > plot horizontal line expressed as analitic function. Here it is a > simple example: > > >In [197]: h = pyx.graph.graphxy(width = 10, height = 10, x = > >pyx.graph.axis.lin(min = 0, max = 10), y = pyx.graph.axis.lin(min = 0, > >max = 10)) > > > >In [198]: h.plot(pyx.graph.data.function("y = x")) > >Out[198]: <pyx.graph.graph.plotitem instance at 0x6e80558> > > > >In [199]: h.plot(pyx.graph.data.function("y = 2")) You have to use h.plot(pyx.graph.data.function("y = 2 + 0*x")) because otherwise PyX cannot determine the name of the independent variable. Jörg 
From: Andrea Riciputi <ariciputi@pi...>  20050124 11:53:05

Thanks J=F6rg. But I find it awkward... Perhaps it could be usefull to=20= implement a default indipendent variable if none is present... Andrea. On 24 Jan 2005, at 12:43, Joerg Lehmann wrote: > You have to use > > h.plot(pyx.graph.data.function("y =3D 2 + 0*x")) > > because otherwise PyX cannot determine the name of the independent > variable. > > J=F6rg 
From: Joerg Lehmann <joergl@us...>  20050124 12:01:07

On 24.01.05, Andrea Riciputi wrote: > Thanks Jörg. But I find it awkward... Perhaps it could be usefull to > implement a default indipendent variable if none is present... Yes, i know it's not really pretty and we should really find a better solution. I'll discuss this with André at the next developer meeting. Jörg 
From: Andre Wobst <wobsta@us...>  20050125 07:51:29

Hi, On 24.01.05, Joerg Lehmann wrote: > On 24.01.05, Andrea Riciputi wrote: > > Thanks Jörg. But I find it awkward... Perhaps it could be usefull to > > implement a default indipendent variable if none is present... > > Yes, i know it's not really pretty and we should really find a better > solution. I'll discuss this with André at the next developer meeting. This really is a design problem. I'm not sure on how we should solve that. There are several solutions one could think of: 1) Making "x" to be a default variable within the function. con: The function does not know anything about the axis names and the axis name "x" is not at all special. 2) Let the graph tell the function which axis should be the default variable. con: As above, "x" should not be special, although this solution is less special in that its not a feature of the function anymore. 3) Extend the function syntax to be "y(x)=sin(x)". pro: I kind of like that idea ... ;) con: It's a little unpythonic. At least we could easily make a smooth transition with a deprication warning on the old way of writing for several releases. Probably, there are a lot of other solutions. Note also, that in the paramfunction you need to specify the variable parameter. But I think we sould leave that (and don't do anything like variant 3 for a parametric function) ... André PS: You could stroke a horizontal line by g.stroke(g.xgridpath(<value>)) where g is a graph instance. But this doesn't help out of this design problem we have ...  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Joerg Lehmann <joergl@us...>  20050125 16:51:24

Hi André, On 25.01.05, Andre Wobst wrote: > This really is a design problem. I'm not sure on how we should solve > that. There are several solutions one could think of: [ snip ] > 3) Extend the function syntax to be "y(x)=sin(x)". > pro: I kind of like that idea ... ;) > con: It's a little unpythonic. At least we could easily make a > smooth transition with a deprication warning on the old way of > writing for several releases. Nice idea! Concerning the nonPythonic syntax: y = sin(x) is also not the Python way of defining a function. And remember: Explicit is better than implicit. > Probably, there are a lot of other solutions. Note also, that in the > paramfunction you need to specify the variable parameter. But I think > we sould leave that (and don't do anything like variant 3 for a > parametric function) ... Maybe yes, x(t), y(t) = cos(t), sin(t) looks a bit clumsy. But still... > PS: You could stroke a horizontal line by > g.stroke(g.xgridpath(<value>)) where g is a graph instance. But > this doesn't help out of this design problem we have ... No, this is definitely not the solution. Jörg 
From: Michael Schindler <mschindler@us...>  20050125 20:47:49

Hi André and Jörg, On 25.01.05, Joerg Lehmann wrote: > On 25.01.05, Andre Wobst wrote: > > Probably, there are a lot of other solutions. Note also, that in the > > paramfunction you need to specify the variable parameter. But I think > > we sould leave that (and don't do anything like variant 3 for a > > parametric function) ... > > Maybe yes, x(t), y(t) = cos(t), sin(t) looks a bit clumsy. But > still... clumsy? I think it is a very nice way to write the function  it is rather the the standard way to write a parametric function (e.g. you will find this in many mathematical textbooks). Remember that it is also possible to use other than only x and y axes y = sin(x2) y4 = cos(x1) Unfortunately, we then will also be asked for something crude like y2(x1, x2) = x1 * sin(x2) Does this actually work at the moment? Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Joerg Lehmann <joergl@us...>  20050126 08:19:28

Hi Michael, On 25.01.05, Michael Schindler wrote: > On 25.01.05, Joerg Lehmann wrote: > > On 25.01.05, Andre Wobst wrote: > > > Probably, there are a lot of other solutions. Note also, that in the > > > paramfunction you need to specify the variable parameter. But I think > > > we sould leave that (and don't do anything like variant 3 for a > > > parametric function) ... > > > > Maybe yes, x(t), y(t) = cos(t), sin(t) looks a bit clumsy. But > > still... > > clumsy? I think it is a very nice way to write the function  it is > rather the the standard way to write a parametric function (e.g. you > will find this in many mathematical textbooks). Remember > that it is also possible to use other than only x and y axes > > y = sin(x2) > y4 = cos(x1) For this case, I definitely prefer the variants y(x2) = sin(x2) and y4(x1) = cos(x1), which my "clumsy" didn't refer to. I was just saying that for the parametric functions this notation becomes a bit lengthy. But note that my "but still..." was meant as a +0, maybe even more. > Unfortunately, we then will also be asked for something crude like > > y2(x1, x2) = x1 * sin(x2) > > Does this actually work at the moment? At the moment not, because there is no bracket notation on the left hand side of the equal sign at all. Jörg 
From: Andre Wobst <wobsta@us...>  20050126 10:17:47

Hi, On 26.01.05, Joerg Lehmann wrote: > For this case, I definitely prefer the variants y(x2) = sin(x2) and > y4(x1) = cos(x1), which my "clumsy" didn't refer to. I was just saying > that for the parametric functions this notation becomes a bit lengthy. > But note that my "but still..." was meant as a +0, maybe even more. I suggest to drop this parametric function business (which I raised myself, I know), since it's really not a crucial thing at all. And its a sufficiantly different thing compared to a "normal" function to have a different notation for the parameter here. I give it a 0 for the moment ... > > Unfortunately, we then will also be asked for something crude like > > > > y2(x1, x2) = x1 * sin(x2) > > > > Does this actually work at the moment? > > At the moment not, because there is no bracket notation on the left hand > side of the equal sign at all. At the moment we do not support a two parameter function, since we currently do not have an xyzgraph. Sure we'll add it in the future. And it's likely that the above code will become work, but it'll create something very strange (i.e. looping over x1 and x2 independly). And you'll have trouble getting a style consuming that data (you can write your own one or may be a errorbar or bar like thing would work). Overall I totally dislike this idea (the way you meant it, i.e. x1 and x2 refer to the *same* graph position), since the function will strangely depend on the graph (although it's natural, that the function data depend on the graph since, for example, the range of a function depends on the graph and it differs in several graphs for the very same function instance). What if somehow the axis ranges get changed? No way ... this is really uncontrolable. André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050126 09:59:23

Hi, On 25.01.05, Joerg Lehmann wrote: > > 3) Extend the function syntax to be "y(x)=sin(x)". > > pro: I kind of like that idea ... ;) > > con: It's a little unpythonic. At least we could easily make a > > smooth transition with a deprication warning on the old way of > > writing for several releases. > > Nice idea! Concerning the nonPythonic syntax: y = sin(x) is also not > the Python way of defining a function. And remember: Explicit is better > than implicit. You're right. "y = sin(x)" wasn't pythonic either. With "y(x) = sin(x)" we could think of removing the mathtree completely. We'll not need to find out anything about the variables on the right side. (To not yet question the existance of the mathtree, its definitely the way to go. I kind of like the idea of getting rid of the mathtree (at least in the function concept ... it still will be very usefull for fitting) since I want to get rid of the floatsonly concept in data/function/etc.handling. By that we could better support time axis (i.e. time data structures) and  even more important  it's also the crucial aspect to get rid of the splitaxis in favor of a slightly modified version of the baraxis (i.e. using tuples of an int and a float to access a specific part within a split axis ... and the modification should basically be limited to the painter) ... > > Probably, there are a lot of other solutions. Note also, that in the > > paramfunction you need to specify the variable parameter. But I think > > we sould leave that (and don't do anything like variant 3 for a > > parametric function) ... > > Maybe yes, x(t), y(t) = cos(t), sin(t) looks a bit clumsy. But > still... I would not bother too much. Currently the paramfunction needs three mandatory parameters to get enough information about the parameter of the parametric function (``t'' in the example above). We do have a minimum and maximum as well. Since the parametric function is a "nicetohave" feature, but its always easy to construct it from graph.data.list as well, I would not bother too much ... > > PS: You could stroke a horizontal line by > > g.stroke(g.xgridpath(<value>)) where g is a graph instance. But > > this doesn't help out of this design problem we have ... > > No, this is definitely not the solution. Sure it is a solution for something. But you're right: its not exactly a solution to the question raised. ;) André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ 