matplotlib-devel Mailing List for matplotlib

I have been using matplotlib a few days now and think I it is great
but recently I have gotten hung up on a problem plotting negative
numbers.
I am trying to plot data where the y values are all negative. When I
do this I get the No positive data to plot error. I have tracked it
down to the following two line is
/matplotlib/ticker.py:
 if minpos<=3D0:=20
 raise RuntimeError('No positive data to plot')
It looks like for some reason Matplotlib wants positive values when it
does the axis scaling. I commented out the two lines and it works
like a charm now. My question is, do these two lines of code serve a
useful purpose. Does commenting them out break something else or is
this a change that can be incorporated back into the matplotlib
source?
Full stack trace=20
---> 33 splot.plot(x1, y1, "g", x2, y2, "r")
/home/tdennist/lib/python/matplotlib/axes.py in plot(self, *args, **kwargs)
 2524 lines.append(line)
 2525 lines =3D [line for line in lines] # consume the generator
-> 2526 self.autoscale_view()
 2527 return lines
 2528
/home/tdennist/lib/python/matplotlib/axes.py in autoscale_view(self)
 783
 784 locator =3D self.yaxis.get_major_locator()
--> 785 self.set_ylim(locator.autoscale())
 786
 787
/home/tdennist/lib/python/matplotlib/ticker.py in autoscale(self)
 819
 820 if minpos<=3D0:
--> 821 raise RuntimeError('No positive data to plot')
 822 if vmin<=3D0:
 823 vmin =3D minpos
RuntimeError: No positive data to plot
In [50]: exampleReturns.logHistogramPlot([1,2,3,4,0], 100)

On Thu, 2005年06月23日 at 10:58 -0600, Fernando Perez wrote:
> Nicholas Young wrote:
> > On Wed, 2005年06月22日 at 11:45 -0600, Fernando Perez wrote:
> > 
> >>os.environ['TEXMFOUTPUT'] = '/some/path'
> > 
> > 
> > According to the online docs
> > (http://docs.python.org/lib/os-procinfo.html) setting os.environ isn't
> > safe/available for all platforms. You can use the subprocess module to
> > set the environment of a subprocess under python 2.4 but I don't think
> > there's a simple way to do this and capture the output for earlier
> > versions.
> 
> Well, after reading that I get that os.environ _is_ writable everywhere, it's 
> just that it may leak memory in OSX/BSD. What's not always available is the 
> putenv() call, but python will find its way around it if needed.
To quote "If putenv() is not provided, this mapping may be passed to the
appropriate process-creation functions to cause child processes to use a
modified environment.". To me this implies that you have to pass
os.environ to a process-creation function supporting the env keyword
(os.execve, etc.) none of which seem to support capturing output. On
the other hand does anyone actually run mpl on a platform which doesn't
support putenv?
> Since this would be a once-only call, I think that leaking a few bytes is an 
> acceptable price to pay to prevent a crash if the user happens to be 
> positioned on a non-writable dir.
After reading an online copy of the freebsd man putenv it actually reads
"Successive calls to setenv() or putenv() assigning a differently sized
value to the same name will result in a memory leak." so setting this
once wouldn't be a problem.
So I was wrong and setting os.environ seems reasonable in this case -
but it seems sensible to be aware of the potential for causing problems
if anyone trys to get mpl working on an odd platform.
Nick