matplotlib-devel Mailing List for matplotlib

I think I actually got the new api working with draw_markers and draw_lines in 
backend_ps. The transforms are done by passing the results of 
transform.as_vec6_val to postscript. I would appreciate it if someone would 
test it out and give me feedback. In order to do so, update from svn and 
unmask backend_ps.RendererPS._draw_markers (not _draw_markers_old) by 
removing the leading underscore. Try plotting things like
plot([0,1,2,3,4],'-o'); savefig('linear.eps')
plot([0,1,nan,3,4],'-o'); savefig('linear_nan.eps') # Not possible with the 
old API
semilogy([0,1,2,3,4],'-o'); savefig('nonlinear.eps')
semilogy([0,1,nan,3,4],'-o'); savefig('nonlinear_nan.eps') # Not possible with 
the old API
Are there other methods that need to be updated to use the new API? There are 
a bunch of unused methods in RendererPS that I will clean up once things have 
settled, please ignore them for now.
Darren

All,
Motivated in part by an old patch (1233294) submitted to sourceforge by 
Nikolai Hlubek, I took a look at how aspect ratio is handled in mpl, and 
concluded it wasn't quite right:
1) The aspect='preserve' kwarg in image caused the image to retain its 
aspect ratio only with some resize events, not with all. The 
implementation in the image.py code does not look right to me.
2) The aspect='equal' kwarg in axes.py did not respond to resize events 
at all.
3) I could not understand why there should be separate "aspect" kwargs 
for image and for axes.
Therefore I have reworked the aspect-handling code in axes.py, and I 
think it is working reasonably well. Indeed, I don't see any remaining 
need for an "aspect" kwarg in image.py, and I would like to take it out 
unless someone raises an objection.
I have also changed the aspect-related API to make it more flexible and 
self-explanatory:
 def set_aspect(self, aspect='auto', fixLimits=None,
 aspect_adjusts='position'):
 """
 aspect:
 'auto' - automatic; fill position rectangle with data
 'normal' - same as 'auto'; deprecated
 'equal' - same scaling from data to plot units for x and y
 A - a circle will be stretched such that the height
 is A times the width. aspect=1 is the same as
 aspect='equal'.
 aspect_adjusts:
 'position' - change width or height of bounding rectangle;
 keep it centered.
 'box_size' - as above, but anchored to lower left
 'datalim' - change xlim or ylim
 fixLimits: deprecated; False is aspect_adjusts='datalim';
 True is aspect_adjusts='position'
 ACCEPTS: ['auto' | 'equal' | aspect_ratio]
...
 def set_aspect_adjusts(self, aspect_adjusts = 'position'):
 """
 Must be called after set_aspect.
 ACCEPTS: ['position' | 'box_size' | 'datalim']
...
Anticipating that some additional work will need to be done, I have not 
yet made an entry in the CHANGELOG or API_CHANGES.
In addition to removing the aspect kwarg from image.py, I would like to 
take fixLimits out of set_aspect (above). No code in mpl or its 
examples depends on it, but this might break some user code, so for the 
present I have maintained compatibility.
One question: is there an easy way to automatically trigger a redraw in 
an interactive backend (e.g. ipython with gtkagg) at the end of the 
set_aspect() method, for example? The way it works now is that one can 
make a plot, call the set_aspect() method on the resulting axes object, 
and the result will appear as soon as the window is manipulated with the 
mouse; but this manipulation is needed to trigger a redraw.
Eric

On Sunday 19 March 2006 3:14 pm, Andrew Straw wrote:
> Darren Dale wrote:
> >For backend_ps, we want to make use of the transform's numerix methods.
> >
> > if transform.need_nonlinear():
> > x,y,mask =3D transform.nonlinear_only_numerix(x, y,
> > returnMask=3D1) else:
> > mask =3D ones(x.shape)
> > x,y =3D transform.numerix_x_y(x, y)
> >
> >If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do
> >semilogy([1,2,nan,4]), I would have expected a mask that looked like
> >[1,1,0,1], but it returns [1,1,1,1].
>
> I just committed a patch that should make this work. nan support is done
> in a case-by-case basis at the C level. So this is another case.
>
> >Wouldnt it make life easy if
> >transform.nonlinear_only_numerix and transform.numerix_x_y both returned=
 a
> >mask with zeros where x or y is a nan or inf?
>
> I'm not sure this is the right thing to do for inf (or -inf) -- I can
> imagine transforms that accept inf and return something useful (such as
> a reciprocal transform). Maybe we don't use any such transforms
> currently, but that doesn't mean we should prevent that case in the
> future. Is the inf case important for you?
I don't know. For a reciprocal transform, I suppose inf shouldn't effect th=
e=20
mask, but then we can plot the results of the transform. If we can't plot t=
he=20
transformed value, I think the mask should reflect it.
Moving on, I've been trying to follow John's work in __draw_lines_hide (you=
=20
masked that sucker twice, is it that bad?). Help me understand this, are we=
=20
allowed to use transform.numerix_x_y in the new API, or do we have to use=20
transform.as_vec6_val? If I can use the former:
=A0 =A0 =A0 =A0 print x,y
=A0 =A0 =A0 =A0 if transform.need_nonlinear():
=A0 =A0 =A0 =A0 =A0 =A0 x,y,mask =3D transform.nonlinear_only_numerix(x, y,=
 returnMask=3D1)
=A0 =A0 =A0 =A0 =A0 =A0 print x, y
=A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 mask =3D ones(x.shape)
=A0 =A0 =A0 =A0 x, y =3D transform.numerix_x_y(x, y)
=A0 =A0 =A0 =A0 print x, y=20
that returns a "ValueError: Domain error on Transformation::numerix_x_y"=20
message when I try to do semilog plots. Linear plots look fine.
If I should be using the latter, well, I'm playing with it, but I'm spillin=
g=20
blue ink all over the place.

Darren Dale wrote:
>For backend_ps, we want to make use of the transform's numerix methods.
>
> if transform.need_nonlinear():
> x,y,mask = transform.nonlinear_only_numerix(x, y, returnMask=1)
> else:
> mask = ones(x.shape)
> x,y = transform.numerix_x_y(x, y)
>
>If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do 
>semilogy([1,2,nan,4]), I would have expected a mask that looked like 
>[1,1,0,1], but it returns [1,1,1,1]. 
>
I just committed a patch that should make this work. nan support is done
in a case-by-case basis at the C level. So this is another case.
>Wouldnt it make life easy if 
>transform.nonlinear_only_numerix and transform.numerix_x_y both returned a 
>mask with zeros where x or y is a nan or inf? 
>
I'm not sure this is the right thing to do for inf (or -inf) -- I can
imagine transforms that accept inf and return something useful (such as
a reciprocal transform). Maybe we don't use any such transforms
currently, but that doesn't mean we should prevent that case in the
future. Is the inf case important for you?
Cheers!
Andrew

I'm playing with the new API in backend_ps today. I'm trying to make 
draw_markers work:
On Tuesday 14 March 2006 1:38 pm, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
> Eric> Here is a simple illustration of the problem and
> Eric> inconsistency, using just the first few points in
> Eric> Tennessee's plot and a few lines from his script. With a
> Eric> log scale for y, the Agg backends are leaving gaps (breaking
> Eric> the line) at the points where y==0; the PS and SVG backends
> Eric> are removing those points, but *not* breaking the line. I
> Eric> think the Agg behavior is much better. But maybe it would
> Eric> be better yet to raise an exception, forcing the user to
> Eric> deal with the error explicitly. For example, the user might
> Eric> want to change the zero values to a very small number, and
> Eric> then explicitly set the y range to exclude the small
> Eric> numbers. This is illustrated in the second subplot.
>
> This issue has a long history, which I'll summarize here. In the old
> days, we raised an exception when non-positive numbers were passed to
> log plotting. Most people found this objectionable, and prefer to see
> the valid points plotted rather than nothing (though a warning would
> be nice). This is what matlab does. I needed to make some
> architectural changes to support this, because the transformations
> happened in the lines class which passed the transformed data to the
> backend.
>
> I looked into filtering the data in the lines class (basically what
> you did for ma data) but did not think it would be fast enough,
> because we potentially would have had to create a lot of line
> segments.
>
> So I changed the backend API and modified draw_lines to take the
> transformation as an argument. Then the backend can do the following
> (eg _backend_agg)
>
> if (needNonlinear)
> try {
> 	mpltransform->nonlinear_only_api(&thisx, &thisy);
> }
> catch (...) {
> 	moveto = true;
> 	continue;
> }
>
> Ie if there is a nonlinear transformation that raises an exception,
> the path state is changed from lineto to moveto. This is very fast,
> at least an order of magnitude faster than trying to compute the
> segments at the python level I suspect.
For backend_ps, we want to make use of the transform's numerix methods.
 if transform.need_nonlinear():
 x,y,mask = transform.nonlinear_only_numerix(x, y, returnMask=1)
 else:
 mask = ones(x.shape)
 x,y = transform.numerix_x_y(x, y)
If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do 
semilogy([1,2,nan,4]), I would have expected a mask that looked like 
[1,1,0,1], but it returns [1,1,1,1]. Wouldnt it make life easy if 
transform.nonlinear_only_numerix and transform.numerix_x_y both returned a 
mask with zeros where x or y is a nan or inf? Then I can filter out the 
un-drawable markers with something like
 to_draw = izip(x[start:end],y[start:end],mask[start:end])
 ps = ['%1.3f %1.3f marker' % (xp, yp) for xp, yp, m in to_draw i m]
I could do something similar for draw_lines, using Johns suggestion above. 
This would mask nans, infs and log(x<=0) without the need for masked arrays, 
and would provide an opportunity to issue a warning about the bad values (if 
that is actually desireable).
Darren
(There is a lot going on in the transforms that I'm still trying to wrap my 
head around, so please feel free to correct me where my assumptions are 
incorrect or naive.)

Ahah, I have seen this problem before several times on win32 but never sat
down to
nail down the problem. It also occurs, as described, on win32, mpl 0.86.1fo=
r
py2.3.
After you use the save button the entire axis is forgotten. gca() doesn't
work, xlabel,
or anything.
Mark
Fernando Perez wrote:
In [1]: plot(range(10))
Out[1]: [<matplotlib.lines.Line2D instance at 0x41ccd12c>]
At this point, click on the save button and save the figure to any filename=
.
Do NOT try savefig(), as it does NOT cause the problem.
Now, try
close('all')

Hi all,
I just rebuilt mpl on my ubuntu laptop with current SVN, and noticed a bug 
related to window management. Here's how to reproduce it:
- Backend: TkAgg
- Interactively start ipython -pylab
In [1]: plot(range(10))
Out[1]: [<matplotlib.lines.Line2D instance at 0x41ccd12c>]
At this point, click on the save button and save the figure to any filename. 
Do NOT try savefig(), as it does NOT cause the problem.
Now, try
close('all')
The window doesn't close. In fact, if you type figure(1), you'll get a 
SECOND window named (1). The original figure 1 has become inaccessible. 
Something is getting corrupted in the internal window management lists.
I tried GTKAgg and the problem is not present there, so it seems Tk-specific. 
 In 0.83 (what I have at work), this bug was not present either.
Cheers,
f

John Hunter wrote:
>>>>>>"James" == James Evans <jre...@ea...> writes:
>>>>>> 
>>>>>>
>
> James> The patch is as follows: -- In several places arrays are
> James> initialized with a variable for the length. As per
> James> Stroustrup arrays can only be specified with constants or
> James> using 'new' .
>
>Hey James, I notice you have 3 patches with the title 
>
> Strict C/C++ Conformance
>
>Have all of these been resolved by the patch Andrew applied? If so,
>I'll close them.
> 
>
Hmm, I only applied the one that was emailed to this list. I assume 
you're talking about patches on the SourceForge tracker? I haven't 
touched those...