matplotlib-devel Mailing List for matplotlib

On 4/19/06, Ken McIvor <mc...@ii...> wrote:
> On 04/19/06 11:09, Charlie Moad wrote:
> > Hmm, not sure.  I will try this when I get home.
>
> If the first patch doesn't work, this one might.  It basically does VC++6=
's
> job for it by expanding the member function templates into polymorphic me=
mber
> functions that call an external function template with a bunch of extra
> arguments (theRenderer and friends).
>
> It costs in terms of flexibility and is an ugly solution but is probably
> preferable to dropping the templates entirely.
>

I just sent the errors for the last 2 patches you posted.  It really
isn't worth all this time and effort, Ken.  I do appreciate the hard
work though.

- Charlie

I have had errors complaining about uint and ushort being defined in  
both types.h and numpy/arrayobject.h.  I fixed this problem by  
commenting out the lines in arrayobject where these things were  
redefined -- matplotlib compiles fine then.  This hack is unnecessary  
on the PPC Mac (as well as other platforms, I imagine).

Will this hack give me trouble with other packages?  Do any of you  
have suggestions for a more permanent fix?

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

On 04/19/06 11:09, Charlie Moad wrote:
> Hmm, not sure.  I will try this when I get home.

If the first patch doesn't work, this one might.  It basically does VC++6's 
job for it by expanding the member function templates into polymorphic member 
functions that call an external function template with a bunch of extra 
arguments (theRenderer and friends).

It costs in terms of flexibility and is an ugly solution but is probably 
preferable to dropping the templates entirely.

Ken

Steven,

thanks for your reply to my rather confusing email.


Steven Chaplin wrote:

>On Tue, 2006-04-18 at 20:11 -0700,
>mat...@li... wrote:
>
>>        [...]       
>>        
>>        So what I would like to propose is a modification of
>>        expose_event 
>>        located in backends/backend_gtk.py to better handle any
>>        exceptions that 
>>        it might trigger.
>>        One not so nice solution of mine was to wrap the method in a 
>>        try...finally statement, which ensures that False is returned
>>        and the 
>>        expose_event is stopped:
>>        
>>        
>>            def expose_event(self, widget, event):
>>                """Expose_event for all GTK backends. Should not be
>>        overridden.
>>                """
>>                if _debug: print 'FigureCanvasGTK.%s' % fn_name()
>>        
>>            try:
>>                if GTK_WIDGET_DRAWABLE(self):
>>                if self._need_redraw:
>>                    x, y, w, h = self.allocation
>>                    self._pixmap_prepare (w, h)
>>                    self._render_figure(self._pixmap, w, h)
>>                    self._need_redraw = False
>>        
>>                x, y, w, h = event.area
>>                self.window.draw_drawable
>>        (self.style.fg_gc[self.state],
>>                               self._pixmap, x, y, x, y, w, h)
>>            finally:
>>                return False  # finish event propagation?
>>        
>>        
>>        Of course, this has the obvious disadvantage, that no
>>        exception is 
>>        triggered at all, which is undesirable.
>>
>I don't understand, the exception is still raised after the 'finally'
>clause.
>
>
Yes, you are right, it _should_ be triggered. However, I have now 
realized that expose_event wasn't the problem at all in my situation:

Consider the following settings for the Axes ax:

ax.set_yscale('log')
ax.set_ylim(min=-5)

and then redraw the axes. The negative minimum value raised an exception 
in my case:

Traceback (most recent call last):
  File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 294, in expose_event
    self._render_figure(self._pixmap, w, h)
  File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 282, in _render_figure
    self.figure.draw (self._renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line 
529, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1469, 
in draw
    self.legend_.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
208, in draw
    self._update_positions(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
574, in _update_positions
    ox, oy = self._find_best_position(w, h)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
444, in _find_best_position
    verts, bboxes, lines = self._auto_legend_data()
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
340, in _auto_legend_data
    xt, yt = trans.numerix_x_y(xdata, ydata)
ValueError: Domain error on Transformation::numerix_x_y

So somehow the _auto_legend_data method would fail in handling the 
negative limit (which of course should not have been there).
This caused my error box to pop up, which would yet again trigger 
another expose_event, which of course would again cause the same 
exception again! My try...finally statement omitted this _somehow_, even 
though I agree with you that the exception should have been triggered 
anyway.

>
>You could simply popup the user-friendly dialog and then kill the
>program after the user has read the message and clicked "OK".
>
No way!

>
>When you use semilogy(), matplotlib ignores the values <= 0 (I'm not
>sure where the code is that does that), I think an application should do
>the same.
>
>If we add try ... finally to expose_event() that would mean we are
>handling application errors within library code, which I don't think is
>right. Also, this problem would affect all backends so it would probably
>be better to handle it (if it is needed) in the Figure.draw() rather
>than having to modify every backend.
>
Basically there are three options:

(1) Leave everything as it is and let matplotlib blame the user/library 
user if he/she set a negative limit for a logarithmic plot.

(2) Catch the ValueError in _auto_legend_data and continue graciously. 
Is there any way to output friendly informative warnings? I did
the following in _auto_legend_data in legend.py:

            if isinstance(handle, Line2D):

                try:
                    xdata = handle.get_xdata(valid_only = True)
                    ydata = handle.get_ydata(valid_only = True)
                    trans = handle.get_transform()
                    xt, yt = trans.numerix_x_y(xdata, ydata)
                except ValueError:
                    pass # maybe output an error message here?
                else:
                    # XXX need a special method in transform to do a 
list of ve$                    averts = [inv(v) for v in zip(xt, yt)]
                    lines.append(averts)

(3) Omit the ValueError: Use 'None' as limit, if we have a logarithmic 
plot and a negative limit. Output a hint. Unfortunately I am too 
unfamiliar with matplotlib to decide where this check should be done.


Best regards,

Niklas Volbers.

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> Hi, I am trying to add a pdf compression level parameter to
    Jouni> the rc file, with possible values 0 (no compression) or 1
    Jouni> to 9 (as in gzip). If I make the default nonzero but set
    Jouni> the value to 0 in my rc file, the default takes over. It
    Jouni> seems to me that the two "if cval" tests in rc_params
    Jouni> should be changed to "if cval is not None"; but would this
    Jouni> have unintended consequences?

I took a quick look, and 'if cval is not None' looks right to me too.

JDH

Charlie,

I've been thinking about ways to preserve the templated-ness of RendererAgg's 
_fill_and_stroke() and _render_lines_path() while placating the VC++6 gods. 
Looking at the situation from a relatively fresh perspective, it seems that 
the simplest solution is to inline the definitions of those member function 
templates inside the class.  However, I cannot for the life of me rember if 
you/I/we already tried this.  Sourceforge's website is down right now and I 
don't have my laptop handy, so I cannot check the archive of matplotlib-devel.

Attached is a patch that inlines the aformentioned methods.  If this is a 
known dead-end and I've forgotten that then please disregard it.  Otherwise, 
please let me know if it does the trick.  I'm going to start working on a more 
complicated and less general solution now.

Ken

Hi,

I am trying to add a pdf compression level parameter to the rc file,
with possible values 0 (no compression) or 1 to 9 (as in gzip). If I
make the default nonzero but set the value to 0 in my rc file, the
default takes over. It seems to me that the two "if cval" tests in
rc_params should be changed to "if cval is not None"; but would this
have unintended consequences?

-- 
Jouni

On Tue, 2006-04-18 at 20:11 -0700,
mat...@li... wrote:
>         Hello everyone,
>         
>         I have the following problem with my application, which allows
>         you to 
>         manipulate some of properties of a plot through the use of a
>         gui-style 
>         property editor:
>         
>         Whenever I set the y-axis scale to logarithmic, but have the y
>         range 
>         include a negative value, I will get a ValueError upon
>         expose_event. The 
>         bad thing is now, that my application catches all exceptions
>         and 
>         displays a user-friendly dialog, explaining or listing the
>         exception and 
>         offering the user to mail the output to the dumb author of the
>         program. 
>         But whenever the user quits the dialog, a new expose event of
>         the canvas 
>         will be triggered, leading to an unstoppable series of
>         exceptions 
>         (except when using xkill of course).
>         
>         So what I would like to propose is a modification of
>         expose_event 
>         located in backends/backend_gtk.py to better handle any
>         exceptions that 
>         it might trigger.
>         One not so nice solution of mine was to wrap the method in a 
>         try...finally statement, which ensures that False is returned
>         and the 
>         expose_event is stopped:
>         
>         
>             def expose_event(self, widget, event):
>                 """Expose_event for all GTK backends. Should not be
>         overridden.
>                 """
>                 if _debug: print 'FigureCanvasGTK.%s' % fn_name()
>         
>             try:
>                 if GTK_WIDGET_DRAWABLE(self):
>                 if self._need_redraw:
>                     x, y, w, h = self.allocation
>                     self._pixmap_prepare (w, h)
>                     self._render_figure(self._pixmap, w, h)
>                     self._need_redraw = False
>         
>                 x, y, w, h = event.area
>                 self.window.draw_drawable
>         (self.style.fg_gc[self.state],
>                                self._pixmap, x, y, x, y, w, h)
>             finally:
>                 return False  # finish event propagation?
>         
>         
>         Of course, this has the obvious disadvantage, that no
>         exception is 
>         triggered at all, which is undesirable.
I don't understand, the exception is still raised after the 'finally'
clause.

>         Are there any better approaches to this?
>         
>         Best regards,
>         
>         Niklas Volbers.

You could simply popup the user-friendly dialog and then kill the
program after the user has read the message and clicked "OK".

When you use semilogy(), matplotlib ignores the values <= 0 (I'm not
sure where the code is that does that), I think an application should do
the same.

If we add try ... finally to expose_event() that would mean we are
handling application errors within library code, which I don't think is
right. Also, this problem would affect all backends so it would probably
be better to handle it (if it is needed) in the Figure.draw() rather
than having to modify every backend.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> Hello, I'm attaching the beginnings of a PDF backend. It
    Jouni> doesn't implement much of the backend protocol yet, but
    Jouni> enough for this script to produce the attached output:

Very nice!  I committed this to svn.  If you would like to work on it
there, send me a sourceforge id and I'll add you to the committers
list.  


JDH

On Wednesday 19 April 2006 1:31 am, Jouni K Seppanen wrote:
> Hello,
>
> I'm attaching the beginnings of a PDF backend. It doesn't implement
> much of the backend protocol yet, but enough for this script to
> produce the attached output:
>
>   import matplotlib
>   matplotlib.use('Pdf')
>   from pylab import *
>   x = arange(0, 10, 0.05)
>   plot(x, sin(x), 'b-', lw=10, alpha=0.8)
>   plot(x, cos(x), 'r-', lw=10, alpha=0.8)
>   plot(x, cos(x+1), 'g-', lw=10, alpha=0.8)
>   savefig('foo.pdf')


Nice work, Jouni.

Hello,

I'm attaching the beginnings of a PDF backend. It doesn't implement
much of the backend protocol yet, but enough for this script to
produce the attached output:

  import matplotlib
  matplotlib.use('Pdf')
  from pylab import *
  x = arange(0, 10, 0.05)
  plot(x, sin(x), 'b-', lw=10, alpha=0.8)
  plot(x, cos(x), 'r-', lw=10, alpha=0.8)
  plot(x, cos(x+1), 'g-', lw=10, alpha=0.8)
  savefig('foo.pdf')

-- 
Jouni

Hi John,

I need to dynamically resize the font depending of the number of panels in a 
ganged plot. I have attached an example of what I have done so far.

You can see that the GHz base value label  isn't scaled. That is why I was 
contemplating a Styler similar to the Formatter class(es). Also at the time 
of setting the fontsize (after calling figure.add_subplot) the number of 
ticks isn't known,  so it scales only the default number of tick labels as 
can be seen in the example plot.
Sorry if my descriptions sounds a bit convoluted, but the example hopefully 
shows my problem.

Cheers
Malte

On Tuesday 18 April 2006 21:28, John Hunter wrote:
> and ditto for yaxis.  Also, if you like to save typing, you can use
> the setp functionality to set multiple properties for multiple objects
> w/o changing the defaults
>
>   setp(ax.get_xticklabels(), fontsize=12, color='red')
>
>
> JDH

>>>>> "Ken" == Ken McIvor <mc...@ii...> writes:

    Ken> John, Is there a reason that the fill_and_stroke() and
    Ken> render_lines_path() methods of RendererAgg need to be
    Ken> templated?  As far as I can tell, the template type is always
    Ken> agg::path_storage.

In RendererAgg::draw_ellipse (unused I think) it's an agg::ellipse.  
It could be use to fill and stroke a transformed path, or a
transformed curve path (for splines).  So it is not needed in the
current implementation, but is generally useful.

If you need to remove the template arg it to make VC6 work, that's
fine.  I would have thought that explicitly passing the instantiation
type would be about the same.

JDH

John,

Is there a reason that the fill_and_stroke() and render_lines_path()  
methods of RendererAgg need to be templated?  As far as I can tell,  
the template type is always agg::path_storage.

Ken