From: Simon B. <si...@ar...> - 2006-02-15 01:26:32
|
Here is my script: from pyx import * g = graph.graphxy( width=16, x=graph.axis.log(title="size of training set"), y=graph.axis.log(title="CPU time"), ) d = graph.data.list([ (1000, 0.247), (3000, 5.1), (10000, 27.5), (30000, 4*60+24), ], x=1, y=2) g.plot(d, styles = [graph.style.symbol.diamond]) g.finish() g.writeEPSfile("checkers_cpu") Here is my error: Traceback (most recent call last): File "./mk_graph.py", line 21, in ? g.plot(d, styles = [graph.style.symbol.diamond]) File "/home/users/simonb/site-packages/pyx/graph/graph.py", line 150, in plot plotitems.append(plotitem(self, d, styles)) File "/home/users/simonb/site-packages/pyx/graph/graph.py", line 57, in __init__ for n in s.needsdata: AttributeError: changelist instance has no attribute 'needsdata' ? -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
From: Gert I. <Gert.Ingold@Physik.Uni-Augsburg.DE> - 2006-02-15 06:31:33
|
Hi Simon, > g.plot(d, styles =3D [graph.style.symbol.diamond]) try=20 g.plot(d, [graph.style.symbol(graph.style.symbol.diamond)]) instead Best regards, Gert --=20 Gert-Ludwig Ingold email: Gert.Ingold@Physik.Uni-Augsburg.DE Institut f=FCr Physik Phone: +49-821-598-3234 Universit=E4t Augsburg Fax : +49-821-598-3222 D-86135 Augsburg WWW : www.physik.uni-augsburg.de/theo1/ingold Germany PGP : 86FF5A93, key available from homepage |
From: Andre W. <wo...@us...> - 2006-02-15 06:35:17
|
Hi Simon, On 15.02.06, Simon Burton wrote: > ... > > g.plot(d, styles = [graph.style.symbol.diamond]) PyX is more verbose: g.plot(d, styles = [graph.style.symbol(symbol=graph.style.symbol.diamond)]) Still, I kind of like graph.style.symbol.diamond to be used as a style directly. We do similar things elsewhere (like deco.earrow.Large), which is a specific deco instance and still can be modified by __call__. I have to think about this a bit. Its a very interesting idea (and that obvious, that it's really strange, that we didn't discussed that already). André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Simon B. <si...@ar...> - 2006-02-16 06:34:58
|
On Wed, 15 Feb 2006 07:35:04 +0100 Andre Wobst <wo...@us...> wrote: > I have to think about this a bit. Its a very interesting > idea (and that obvious, that it's really strange, that we didn't > discussed that already). Thanks for your help. I just found it now it the FAQ. Can I suggest a couple of things: A) yes, it looks like PyX is great, powerful, etc. The examples show this off, but they are 90% useless (who needs curvey axes ???). They should be renamed "screenshots". B) how to plot diamonds should not be in the FAQ, it's either in the examples or in a cookbook. The FAQ (or at least the graph section) is not an FAQ at all, it's a cookbook. C) examples should actually cover 90% of what people want to do. Not gee-whiz demos that nobody can understand anyway. I don't mean to sound harsh here, but it's been 12months since i last used PyX and I am hit again with exactly the same impression as I was last time. I can't make any sense of the architecture of PyX. If that's the way it's going to be (powerful but difficult to use) then you need a _lot_ of basic cookbook/example's that people can take and modify to suite. Thanks anyway, I hope I can promote PyX more in the future !! Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
From: Gert I. <Gert.Ingold@Physik.Uni-Augsburg.DE> - 2006-02-16 07:15:29
|
Dear Simon, > B) how to plot diamonds should not be in the FAQ, it's either in > the examples or in a cookbook. The FAQ (or at least the graph section) > is not an FAQ at all, it's a cookbook. as the person managing the FAQ, I am of course very much interested in your ideas concerning the FAQ. Does your objection mainly concern the name of the FAQ, i.e. do you feel that it does not appear natural to look there for certain problems even though the answer can be found there? Or do you have suggestions how to improve the FAQ to make it more useful to potential users? As background information: I started the FAQ simply because using PyX not o= n a daily basis it could serve to assist my short-time memory. Therefore, quite a few code snippets are included in the FAQ which can be used by copy-paste. Still being in the process of learning PyX myself (a process which will probably not come to an end soon, I am afraid), I thought it useful to shar= e=20 also some of my understanding with other users having the same problems.=20 As you might expect, I heavily profited from the input of the experts (Andre, J=F6rg, Michael) who also give there feedback if answers are unsatisfying.=20 Basically, I think that a cookbook, i.e. a sort of merger of the present FAQ and the examples, would probably be most helpful for many users. The=20 problem is that to do a good job, one needs a fairly good understanding of= =20 the examples and on the other hand some time to work on explanations. But= =20 this is certainly something which needs to be pursued and as far as I=20 understand, some preliminary work has been done already (Andre knows more= =20 about this). Best regards, Gert --=20 Gert-Ludwig Ingold email: Gert.Ingold@Physik.Uni-Augsburg.DE Institut f=FCr Physik Phone: +49-821-598-3234 Universit=E4t Augsburg Fax : +49-821-598-3222 D-86135 Augsburg WWW : www.physik.uni-augsburg.de/theo1/ingold Germany PGP : 86FF5A93, key available from homepage |
From: Simon B. <si...@ar...> - 2006-02-16 22:09:26
|
On Thu, 16 Feb 2006 08:15:17 +0100 Gert Ingold <Gert.Ingold@Physik.Uni-Augsburg.DE> wrote: > Dear Simon, > > > B) how to plot diamonds should not be in the FAQ, it's either in > > the examples or in a cookbook. The FAQ (or at least the graph section) > > is not an FAQ at all, it's a cookbook. > > as the person managing the FAQ, I am of course very much interested in your > ideas concerning the FAQ. Does your objection mainly concern the name of > the FAQ, i.e. do you feel that it does not appear natural to look there for > certain problems even though the answer can be found there? Yes, that's correct. ... > Basically, I think that a cookbook, i.e. a sort of merger of the present > FAQ and the examples, would probably be most helpful for many users. The > problem is that to do a good job, one needs a fairly good understanding of > the examples and on the other hand some time to work on explanations. But > this is certainly something which needs to be pursued and as far as I > understand, some preliminary work has been done already (Andre knows more > about this). > Would a wiki approach work for this ? I don't think explanations are that important; once the user sees a use case they will know what the type-signature is and be able to experiment from there. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com |
From: Andre W. <wo...@us...> - 2006-02-17 07:45:32
|
Hey, On 17.02.06, Simon Burton wrote: > > Basically, I think that a cookbook, i.e. a sort of merger of the present > > FAQ and the examples, would probably be most helpful for many users. The > > problem is that to do a good job, one needs a fairly good understanding of > > the examples and on the other hand some time to work on explanations. But > > this is certainly something which needs to be pursued and as far as I > > understand, some preliminary work has been done already (Andre knows more > > about this). > > > > Would a wiki approach work for this ? In some sense I like the wiki approch very much in that it would allow our users to improve the situation in a way it helps *the* *users*. However, I think in the end we do not want some arbitrary list of comments. An editorial board which steamlines the descriptions would be best. For that I've started (well, several months ago) a system to provide descriptions to the examples. I would like to make the examples more cookbook-like. This doesn't really mean, that we need to change much in what the examples show, but we need to explain, what is going on. Most of the examples really have some deeper meaning, and my discussions (for example with Gert) have shown me several times, that it's very difficult for our users to look thru an example and really understand, what we want to show there. A cookbook doesn't necessarily show you everything. And it's also only a partial source for copy'n'paste code. But you can learn so much when some code really is explained. You may have a look at http://www.wobsta.de/pyxtest/examples/graphs/lissajous.html to see what I mean. And the idea is to make it easy (for us) to manage the descriptions in order we really can do some editing. (Maybe somebody even want's to join us here ... this would be great!) The descriptions are very easy to write down (in a wiki-like style). Have a look at http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/examples/graphs/lissajous.txt?rev=1.1&view=markup for the source of the description of the webpage cited above. That's the direction I do have in mind. Comments are welcome. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael J G. <mic...@fa...> - 2006-02-27 18:06:31
|
Andre Wobst venit, vidit, dixit 2006-02-17 08:45: > Hey, > > On 17.02.06, Simon Burton wrote: >>> Basically, I think that a cookbook, i.e. a sort of merger of the present >>> FAQ and the examples, would probably be most helpful for many users. The >>> problem is that to do a good job, one needs a fairly good understanding of >>> the examples and on the other hand some time to work on explanations. But >>> this is certainly something which needs to be pursued and as far as I >>> understand, some preliminary work has been done already (Andre knows more >>> about this). >>> >> Would a wiki approach work for this ? > > In some sense I like the wiki approch very much in that it would allow > our users to improve the situation in a way it helps *the* *users*. > However, I think in the end we do not want some arbitrary list of > comments. An editorial board which steamlines the descriptions would > be best. For that I've started (well, several months ago) a system to > provide descriptions to the examples. I would like to make the > examples more cookbook-like. This doesn't really mean, that we need to > change much in what the examples show, but we need to explain, what > is going on. Most of the examples really have some deeper meaning, and > my discussions (for example with Gert) have shown me several times, > that it's very difficult for our users to look thru an example and > really understand, what we want to show there. > > A cookbook doesn't necessarily show you everything. And it's also only > a partial source for copy'n'paste code. But you can learn so much when > some code really is explained. You may have a look at > http://www.wobsta.de/pyxtest/examples/graphs/lissajous.html to see > what I mean. And the idea is to make it easy (for us) to manage the > descriptions in order we really can do some editing. (Maybe somebody > even want's to join us here ... this would be great!) The descriptions > are very easy to write down (in a wiki-like style). Have a look at > http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/examples/graphs/lissajous.txt?rev=1.1&view=markup > for the source of the description of the webpage cited above. > > That's the direction I do have in mind. Comments are welcome. Following up on this discussion I'm moving this thread to a new one. I do remember I offered help with the documentation quite a while ago, and it didn't happen - for lack of time, but also for lack of coordination. I'm still interested in helping out. I like the new style of the examples a lot, especially the idea of having one minimal example per section. I'm not sure if the set of examples is compact or convex (attention: mathematician joking), but I strongly feel there should be at least one minimal example per section. The Lissajous example perfectly demonstrates how much one can learn from concise code with a detailed description. Maybe one can add a little more structure to the format of the examples, including something like keyword subheadings ("paramfunction, context") which could be indexed automatically. A good, structured set of examples in this style would serve as the best tutorial one could imagine for the intended audience - after all, PyX users are python programmers, whether they got hooked on python by PyX or not. Also, the moderated wiki Andre mentions seems to be the best compromise between openness to contributors and the goal of achieving a well structured tutorial by examples. I only suggest substituting the steamlining editors by streamlining ones ;) (sorry, couldn't resist...) Remains to see what to do with the FAQ and manual. Obviously, the list of FAQ is organically grown. Some of the questions are "typical FAQ questions". Part of the material from section 4 (plotting of graphs) might rather be transferred to the examples. As for the manual I'm somewhat ambiguous. My personal experience is: When I'm trying to understand concepts I find the section intros too short and the list of methods and parameters overwhelming. When I try to understand the details about how things fit together then I don't find enough information in the manual. Most of the time I end up heeding Obi Wan Kenobi's advice: "Use the source, Luke!" So, for the manual I suggest either restricting it to an API reference listing the methods and parameters, or to extend the descriptions of concepts. I think it's basically a matter of whether we want the overall concepts (drawing is done on a graph instance, how do units work, paths, decorators and deformers, ...) to be explained in the manual or in the tutorial by examples. Cheers, Michael |
From: Arnd B. <arn...@we...> - 2006-02-27 23:13:34
|
Moin, [ ... I tried to shorten some parts to keep this bounded from above ...] On Mon, 27 Feb 2006, Michael J Gruber wrote: > Andre Wobst venit, vidit, dixit 2006-02-17 08:45: [ ... cookbook = FAQ + examples suggestion ...] > >> Would a wiki approach work for this ? > > > > In some sense I like the wiki approch very much in that it would allow > > our users to improve the situation in a way it helps *the* *users*. > > However, I think in the end we do not want some arbitrary list of > > comments. An editorial board which steamlines the descriptions would > > be best. For that I've started (well, several months ago) a system to > > provide descriptions to the examples. I would like to make the > > examples more cookbook-like. This doesn't really mean, that we need to > > change much in what the examples show, but we need to explain, what > > is going on. Most of the examples really have some deeper meaning, and > > my discussions (for example with Gert) have shown me several times, > > that it's very difficult for our users to look thru an example and > > really understand, what we want to show there. > > A cookbook doesn't necessarily show you everything. And it's also only > > a partial source for copy'n'paste code. But you can learn so much when > > some code really is explained. You may have a look at > > http://www.wobsta.de/pyxtest/examples/graphs/lissajous.html to see This is extremely nice and helpful! (and will be quite some work to do for all examples ...) > > what I mean. And the idea is to make it easy (for us) to manage the > > descriptions in order we really can do some editing. (Maybe somebody > > even want's to join us here ... this would be great!) The descriptions > > are very easy to write down (in a wiki-like style). Have a look at > > http://cvs.sourceforge.net/viewcvs.py/pyx/pyx/examples/graphs/lissajous.txt?rev=1.1&view=markup > > for the source of the description of the webpage cited above. > > > > That's the direction I do have in mind. Comments are welcome. Looks very nice - `lissajous.txt` almost looks like ReSt. (http://docutils.sourceforge.net/rst.html) But why not include this directly in lissajous.py as a doc-string (see also below). Then one has just one source and even when being off-line one has access to the full information? [...] > Also, the moderated wiki Andre mentions seems to be the best compromise > between openness to contributors and the goal of achieving a well > structured tutorial by examples. I only suggest substituting the > steamlining editors by streamlining ones ;) (sorry, couldn't resist...) ;-) Wikis tend to have the problem of getting unstructured, so this seems reasonable. On the other hand Wikis work because it is so easy to add things. Maybe one can introduce a staging area like WorkInProgress/Unfinished etc. to which anyone can add stuff. If something is considered to be good enough it gets integrated into the main Wiki structure. > Remains to see what to do with the FAQ and manual. Obviously, the list > of FAQ is organically grown. Some of the questions are "typical FAQ > questions". Part of the material from section 4 (plotting of graphs) > might rather be transferred to the examples. Getting the FAQ into the Wiki might lead to more people adding their tricks etc. It might also make moving things from FAQ to examples easier. > As for the manual I'm somewhat ambiguous. My personal experience is: > When I'm trying to understand concepts I find the section intros too > short and the list of methods and parameters overwhelming. When I try to > understand the details about how things fit together then I don't find > enough information in the manual. Most of the time I end up heeding Obi > Wan Kenobi's advice: "Use the source, Luke!" > > So, for the manual I suggest either restricting it to an API reference > listing the methods and parameters, or to extend the descriptions of > concepts. I think it's basically a matter of whether we want the overall > concepts (drawing is done on a graph instance, how do units work, paths, > decorators and deformers, ...) to be explained in the manual or in the > tutorial by examples. Presumably that is difficult to decide because both a manual and an API reference have their place. Have you thought about automatic API extraction from the source using doc-strings (maybe written in ReSt)? This brings me to another point: For any python library I am trying to use/understand I use the interactive capabilites a lot. Eg., with IPython In [1]: import pyx In [2]: pyx? [ ... doc-string snipped ...] In [3]: pyx.graph? <no docstring> In [4]: pyx.graph.graphxy? <no docstring> It would be nice if PyX would make more use of doc-strings. (For example, the description of graphxy in sec. 4.3 could essentially be copied/moved straight to the doc-string.) Best, Arnd |