matplotlib-users Mailing List for matplotlib

Darren,
This works great for me - thanks!
I should have said this earlier, but matplotlib is excellent! Thank you 
to everyone who works on it.
John
Darren Dale wrote:
>On Wednesday 16 March 2005 07:59 pm, Darren Dale wrote:
> 
>
>>I suggest making the following change to ticker.py, starting
>>at line 501 in version 0.72.1:
>>
>> def le(self, x):
>> 'return the largest multiple of base <= x'
>> d,m = divmod(x, self._base)
>> if closeto(m/self._base,1): # was closeto(m, self._base)
>> #looks like floating point error
>> return (d+1)*self._base
>> else:
>> return d*self._base
>>
>> 
>>
>
>I was testing this bugfix with plot([1.4e-12,3.0e-12]), and noticed that the 
>1.4e-12 ticklabel was being dropped.
>
>In ticker.py, I suggest replacing Base.ge with:
>
> def ge(self, x):
> 'return the largest multiple of base >= x'
> d,m = divmod(x, self._base)
> if closeto(m,0) and not closeto(m/self._base,1): return x
> return (d+1)*self._base
>
>The fourth line used to be if m==0: return x, which fails sometimes due to 
>floating point inaccuracy. John, remember I was complaining about how certain 
>ticklabels wouldnt get rendered in the new scalarformatter I posted a couple 
>weeks ago? This was the problem.
>
>Darren
>
> 
>

Hello Andrea,
and...@ti... a écrit :
> That does not depend on Numeric, numarray or Matlab. Is your data. If you
> try, in Matlab, to see how polyfit works (type polyfit), you will see with
> a simple trial that your data are bad conditioned. As an example, if x,
> y are the 2 rows of your data:
> 
> In fact, try to take a look at the condition number of your matrix R:
> 
> condest(R)
> 
> ans =
> 
> 3.89823249817041e+025
> 
> That's too high. Neither Matlab, Python or whatever software will give you
> a result on which you can rely. Maybe at a first glance Matlab seems to
> be more powerful (and, in general, this is the case), but be aware that
> you should not trust on results that are affected by so bad conditioning
> number/numerical errors.
> Try to reduce the number of points (some of them are too close), or try
> a non-linear regression (as lsqnonlin), even if you should not need such
> a tool in order to do the job.
I totally agree to the fact that my problem is highly badly conditioned. 
But as this may not always be the case, I would have preferred polyfit 
to give reliable results without having to track the condition number. 
Do you know how to get it from within Python?
Indeed I do not use the fitted polynomials directly but their
derivatives. Doing so, fitting errors are increased and I noticed that
Matlab keeps providing reliable results for the few input data I tested.
This is not the case with Numeric or numarray.
JM.

On Thursday 17 March 2005 10:05 am, Vinj Vinj wrote:
> I'm getting the followign exception on fedora core3.
> Any suggestions. This code works on windows:
>
> from matplotlib.matlab import *
> File
> "/usr/lib/python2.3/site-packages/matplotlib/matlab.py",
> line 12, in ?
> from matplotlib.pylab import *
> File
> "/usr/lib/python2.3/site-packages/matplotlib/pylab.py",
> line 722, in ?
> figimage.__doc__ = Figure.figimage.__doc__ + """
> TypeError: unsupported operand type(s) for +:
> 'NoneType' and 'str'
Hi Vinj,
What version of MPL are you using? Have you tried to remove your 
site-packages/matplotlib directory, and install from a fresh tarball (or are 
you using rpm)?
By the way, "from matplotlib.matlab import" statements are deprecated. You 
should start using "fom matplotlib.pylab import ..." or simply "from pylab 
import ..." 
Darren

 Hi,
 I am having a problem with legend recognizing the labelsep 
kwarg. It recognizes and makes changes according to the other kwargs (i.e. 
handlelen, handletextsep, axespad, pad, etc.), but when I adjust the number 
for labelsep, nothing happens. The default is 0.005 and I have tried 
numbers between 100000 and 0.0000001 with no change. I am currently using 
Python 2.3.5, TK version 8.4 and running my scripts in IDLE 1.0.5 with the 
GTKAgg backend. The problem I want to fix is to put more space between my 
legend labels so that when I print out the figure in a report, the labels 
don't overlap each other. The actual legend command I am using is shown 
below. Appreciate the help.
legend(('TC1','TC2','TC3',TC4','TC5','TC6'),loc=4,labelsep=0.05)
 Scott

I'm getting the followign exception on fedora core3.
Any suggestions. This code works on windows:
 from matplotlib.matlab import *
 File
"/usr/lib/python2.3/site-packages/matplotlib/matlab.py",
line 12, in ?
 from matplotlib.pylab import *
 File
"/usr/lib/python2.3/site-packages/matplotlib/pylab.py",
line 722, in ?
 figimage.__doc__ = Figure.figimage.__doc__ + """
 TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'

John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> John, I've been caught out a few times with this too! I
> Steve> think we should change it so -d<nonexistentbackend> raises
> Steve> an error, what do you think?
> 
> I'm inclined to leave it as is though, and deal with it as a annoying
> problem. Users who are passing -dBackend flags are probably
> sophisticated enough to survive this annoyance. But if you have a
> clean solution, I'm open to it.
Deprecate -d<backend> and introduce --mpl.backend=<backend>? Perhaps 
extend to allow overriding all .matplotlibrc directives, so you can do 
--mpl.verbose.level=debug and so on?
I think that would be clean, and if you like the idea I can create a 
patch for it. But I saw -d mentioned as matlab compatible, so if that is 
important then maybe not.
-j.
PS. my excuses for not preserving CCs earlier.

Hello Andrea,
and...@ti... a écrit :
> That does not depend on Numeric, numarray or Matlab. Is your data. If you
> try, in Matlab, to see how polyfit works (type polyfit), you will see with
> a simple trial that your data are bad conditioned. As an example, if x,
> y are the 2 rows of your data:
> 
> In fact, try to take a look at the condition number of your matrix R:
> 
> condest(R)
> 
> ans =
> 
> 3.89823249817041e+025
> 
> That's too high. Neither Matlab, Python or whatever software will give you
> a result on which you can rely. Maybe at a first glance Matlab seems to
> be more powerful (and, in general, this is the case), but be aware that
> you should not trust on results that are affected by so bad conditioning
> number/numerical errors.
> Try to reduce the number of points (some of them are too close), or try
> a non-linear regression (as lsqnonlin), even if you should not need such
> a tool in order to do the job.
I totally agree to the fact that my problem is highly bad conditionned. 
But as this may not always be the case and I would have preferred 
polyfit to give reliable results without having to track the condition 
number. Do you know how to get it from within Python?
Indeed I do not use the fitted polynomials directly but their 
derivatives. Doing so, fitting errors are increased and I notice that 
Matlab keeps providing reliable results for the few input data I tested. 
This is not the case with Numeric or numarray.
JM.

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> John, I've been caught out a few times with this too! I
 Steve> think we should change it so -d<nonexistentbackend> raises
 Steve> an error, what do you think?
I've been caught many times too. We used t raise on nonexistant
backend strings, but we were rightly yelled at because mpl is a
library, and users often want to pass other -d flags to their
programs, eg -debug. So now it fails silently, which is bad, but may
be better than the alternative of blocking all other -d flags.
One possible solution is to warn, but allow the user to turn off the
warning with an rc param.
I'm inclined to leave it as is though, and deal with it as a annoying
problem. Users who are passing -dBackend flags are probably
sophisticated enough to survive this annoyance. But if you have a
clean solution, I'm open to it.
JDH

On Wed, 2005年03月16日 at 16:59 -0800, matplotlib-users-
re...@li... wrote:
> > Joachim B Haga <cj...@st...> 
> > writes:
> > 
> > >> You may have something there. I tested different backends:
> > >> 
> > >> These show the problem: While these work fine:
> > >> 
> > >> GtkAgg WX 
> > >> QtAgg WXAgg 
> > >> CairoAgg GTK 
> > >> GtkCairo (yes, really) TkAgg 
> > 
> > Forget this list. I just discovered that -d<nonexistentbackend> 
> > silently defaults to GtkAgg, at least on my install (debian). So the
> > "problem" list probably boils down to GtkAgg. Maybe you knew that.
John, I've been caught out a few times with this too! I think we should
change it so -d<nonexistentbackend> raises an error, what do you think?
> > Steve Chaplin <ste...@ya...> writes:
> > > I've just fixed it in CVS, it should appear in the next matplotlib
> > > version. Or try installing from CVS if you need the fix now, and would
> > > like to test it.
> > 
> > Excellent! I'll wait; or, if you want me to test, tell me which file and
> > version it is so I can patch my install with the relevant changes.
Its the file lib/matplotlib/backends/backend_gtkagg.py version 1.10,
it may also need lib/matplotlib/backends/backend_gtk.py version 1.80
Steve

On Wed, 2005年03月16日 at 09:00 -0600, John Hunter wrote:
> I looked at this briefly and am a little confused by something. The
> base class FigureCanvasGTK.expose_event has this in the doc string
> 
> """Expose_event for all GTK backends
> Should not be overridden.
> 
> but then the derived class 
> 
> class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg):
> 
> does in fact override it.
A while ago I started updating the GTK backends to be more consistent
(by using the same draw(), expose_event() etc methods) and also so they
create just one Renderer instance and reuse it for all drawing. I
completed doing this for GTK and GTKCairo. With GTKAgg, it looked a bit
more complicated, and seeing that GTKAgg was already working quite well
I decided to leave it and come back to it later.
So my intention was to have all GTK backends using a standard draw() and
expose_event() from the base class and just have a specific
_renderer_init() to set their own renderer. To make this work by reusing
one Renderer instance I needed to add new methods to each Renderer:
 def _set_pixmap(self, pixmap):
 def _set_width_height(self, width, height):
which are called by _render_figure().
I still think this approach is a good idea, but it may need to be
modified to allow it to work with GTKAgg.
The patch I committed to CVS does the first part (using standard draw()
and expose()), but not the second part - GTKAgg still uses multiple
Renderer instances.
The patch also fixes another little problem that GTKAgg has. If you
display a figure, then obscure the window and expose the window (without
resizing it), GTKAgg will completely redraw the window, which may give a
flicker in the obscured/exposed area for a complicated figure, whereas
GTK and GTKCairo will redraw the original figure from the double-
buffered memory, which is much faster and flicker-free.
> I inserted a debug print statement into
> FigureCanvasGTKAgg.expose_event and it is not called until the loop is
> over. I think this is because the call to sleep is preventing the
> idle handler from ever getting engaged.
I think Joachim just used the sleep call just to make the problem
obvious, and that the problem is there even if sleep is not called,
except that it may flash so quickly you can not be sure what you saw.
> Perhaps Joachim would be better off using a gtk timer to handle his
> animation. Basically, matplotlib tries to provide a GUI neutral way
> to do animation (eg anim.py) but if you want to do something
> semi-sophisticated like alter the timing between draws, you should use
> the GUI specific functionality for this, eg gtk timers.
> 
> Here is an example
> [...]
Thats works OK, but requires that users write their own animation draw()
routines, whereas using double-buffering for GTKAgg makes it available
to all GTKAgg users for free. I think double-buffering is generally what
you want to use for flicker-free drawing, and there does not seem to be
any performance penalty from the few tests I made.
Steve

On Wednesday 16 March 2005 07:59 pm, Darren Dale wrote:
> I suggest making the following change to ticker.py, starting
> at line 501 in version 0.72.1:
>
> def le(self, x):
> 'return the largest multiple of base <= x'
> d,m = divmod(x, self._base)
> if closeto(m/self._base,1): # was closeto(m, self._base)
> #looks like floating point error
> return (d+1)*self._base
> else:
> return d*self._base
>
I was testing this bugfix with plot([1.4e-12,3.0e-12]), and noticed that the 
1.4e-12 ticklabel was being dropped.
In ticker.py, I suggest replacing Base.ge with:
 def ge(self, x):
 'return the largest multiple of base >= x'
 d,m = divmod(x, self._base)
 if closeto(m,0) and not closeto(m/self._base,1): return x
 return (d+1)*self._base
The fourth line used to be if m==0: return x, which fails sometimes due to 
floating point inaccuracy. John, remember I was complaining about how certain 
ticklabels wouldnt get rendered in the new scalarformatter I posted a couple 
weeks ago? This was the problem.
Darren

Hi John,
It is a bug. I suggest making the following change to ticker.py, starting at 
line 501 in version 0.72.1:
 def le(self, x):
 'return the largest multiple of base <= x'
 d,m = divmod(x, self._base)
 if closeto(m/self._base,1): # was closeto(m, self._base)
 #looks like floating point error
 return (d+1)*self._base
 else:
 return d*self._base
Darren
On Wednesday 16 March 2005 06:26 pm, John Pyle wrote:
> Hello,
>
> When I run:
>
> from pylab import *
> data = [1.6e-012, 3.0e-012]
> plot(data)
>
> the y axis autoscales to 1.8e-12 - 3.2e-12. I get the same behavior when
> I run in interactive mode or save the figure to png.
>
> Does anyone know if this is a bug or if there's something I can do to
> make the autoscaling work out?
>
> Thanks,
> John
>
>
> P.S. Here's the output from the --verbose-helpful flag:
>
> matplotlib data path c:\pyle\python23\share\matplotlib
> loaded rc file c:\pyle\python23\share\matplotlib\.matplotlibrc
> matplotlib version 0.72.1
> verbose.level helpful
> interactive is False
> platform is win32
> numerix numarray 1.2.2
> font search path ['c:\\pyle\\python23\\share\\matplotlib']
> loaded ttfcache file C:/msys/1.0/home/artsys\.ttffont.cache
> backend Agg version v2.2
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Darren