From: Tom B. <cyg...@ma...> - 2006-09-10 03:06:52
|
I have some data with x- & y-errors but can find no examples on the site examples, GNUplot tutorial or in the mailing list for plotting x-axis or 2-axis errors. data=graph.data.file("data.txt",p=2,ep=3,pdot=4,epdot=5,px=8,epx=9, x="3260.0/$8",y="$4/$2",dy="1e-12",dx="3260.0*$9/$8/ $8",title='title') g.plot(data,styles=[graph.style.errorbar(errorbarattrs=[color.rgb(1.0,0. 0,1.0)]), graph.style.symbol(symbolattrs=[color.rgb(1.0,0.0,1.0)])]) Any way to do this? The plot option doesn't seem to distinguish the axis for the error bars. Tom -- W.T. Bridgman, Ph.D. Physics & Astronomy |
From: Tom B. <cyg...@ma...> - 2006-09-10 16:20:10
|
Opps! I found some older code where x-axis errors are plotted with no problem. The issue is probably a bad data point in my dx calculation (as it runs fine without the error bars). Unfortunately, the program runs to completion and I don't see indication of an error until the eps or PDF file fails to load. I'll need to check each point. Is there a flag that can activate more robust checking in the data side of the plotting process or is there another clever solution to catch these before the file is written? Tom On Sep 9, 2006, at 11:06 PM, Tom Bridgman wrote: > I have some data with x- & y-errors but can find no examples on the > site examples, GNUplot tutorial or in the mailing list for plotting > x-axis or 2-axis errors. > > data=graph.data.file("data.txt",p=2,ep=3,pdot=4,epdot=5,px=8,epx=9, > x="3260.0/$8",y="$4/$2",dy="1e-12",dx="3260.0*$9/$8/ > $8",title='title') > > g.plot(data,styles=[graph.style.errorbar(errorbarattrs=[color.rgb(1.0,0 > .0,1.0)]), > graph.style.symbol(symbolattrs=[color.rgb(1.0,0.0,1.0)])]) > > Any way to do this? The plot option doesn't seem to distinguish the > axis for the error bars. -- W.T. Bridgman, Ph.D. Physics & Astronomy |
From: Andre W. <wo...@us...> - 2006-09-15 06:32:47
|
Hi Tom, On 10.09.06, Tom Bridgman wrote: > Opps! I found some older code where x-axis errors are plotted with no > problem. > > The issue is probably a bad data point in my dx calculation (as it runs > fine without the error bars). Unfortunately, the program runs to > completion and I don't see indication of an error until the eps or PDF > file fails to load. I'll need to check each point. Too bad. Can you give us an example showing where PyX accepts everything but the result is broken PostScript and/or PDF? > Is there a flag that can activate more robust checking in the data side > of the plotting process or is there another clever solution to catch > these before the file is written? Originally the idea is that PyX checks everything in form of catching the proper exceptions. It does all the math for the graph that way, that "broken" data points are ignored. For example if you have some data, which is not a float, the data reader keeps it as a string. If you do some math with it, the exceptions raised by Python are catched and the data point is omitted. So far so good ... it's the best we can do without loosing too much performance. In most cases, this works well for say negative values on a logarithmic axes or for marking bad data points by "*" or similar. But for floats it depends on how your floating point unit handles such cases. This is highly plattform dependend (and sometimes even configurable). Python itself does different things on different plattforms (and it's a known "feature" ... the issue has been discussed by the python folks again and again). Try math.sqrt(-1) on an Linux/ia32 and OSX/PPC. IIRC in one case you get an exceptions and in the other an NaN float value *but* no exception. Now the problem is, that when no exception is raised but NaN or +Inf/-Inf occur as floating point values, those values might eventually be written to the final output. This does not only happen in the graph module, but for paths etc. as well. Its not clear how to properly fix that (i.e. in a plattform independend manner and without much overhead in time). This is open for discussion. It's a todo item in our CHANGES file for ages. I would be interested in your case in order to understand whether we can at least improve the situation somehow. Unfortunately my knowledge in this area is quite limited. It might be (I even expect so since I guess quite some subscribers of this list are doing math in Python) that somebody on this list might know how to deal/improve the situation ... 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/ |