matplotlib-users Mailing List for matplotlib

Agreed; this is a band-aid at best.
On Sun, Jan 9, 2011 at 5:23 PM, Benjamin Root <ben...@ou...> wrote:
> On Sun, Jan 9, 2011 at 4:15 PM, Daniel Hyams <dh...@gm...> wrote:
>
>> Fix (and it looks like this would need to be fixed in 1.0.1 as well):
>>
>> A few lines up in draw() (line 183 in axis3d.py) there is a filter for
>> throwing out grid lines that are outside the axis limits. In
>> exceptional cases though, "interval" has a greater number listed first,
>> then the smaller. That in and of itself might warrant
>> further investigation, but simply replacing:
>>
>> majorLocs = [loc for loc in majorLocs if \
>> interval[0] <= loc <= interval[1]]
>>
>> with:
>> if interval[0] > interval[1]: interval[1],interval[0] =
>> interval[0],interval[1]
>> majorLocs = [loc for loc in majorLocs if \
>> interval[0] <= loc <= interval[1]]
>>
>> seems to solve the problem at hand.
>>
>>
> Hmm, I would rather investigate the cause of this instead. Also, messing
> around with the contents of the interval array might have implications
> elsewhere. As I noted in my previous email, there are still other problems
> with mplot3d zooming that I would hardly call it "fiixed" at this point.
>
> Good catch though, and it gives me a good starting place to examine this
> further.
>
> Ben Root
>
>
-- 
Daniel Hyams
dh...@gm...

On Sun, Jan 9, 2011 at 4:15 PM, Daniel Hyams <dh...@gm...> wrote:
> Fix (and it looks like this would need to be fixed in 1.0.1 as well):
>
> A few lines up in draw() (line 183 in axis3d.py) there is a filter for
> throwing out grid lines that are outside the axis limits. In
> exceptional cases though, "interval" has a greater number listed first,
> then the smaller. That in and of itself might warrant
> further investigation, but simply replacing:
>
> majorLocs = [loc for loc in majorLocs if \
> interval[0] <= loc <= interval[1]]
>
> with:
> if interval[0] > interval[1]: interval[1],interval[0] =
> interval[0],interval[1]
> majorLocs = [loc for loc in majorLocs if \
> interval[0] <= loc <= interval[1]]
>
> seems to solve the problem at hand.
>
>
Hmm, I would rather investigate the cause of this instead. Also, messing
around with the contents of the interval array might have implications
elsewhere. As I noted in my previous email, there are still other problems
with mplot3d zooming that I would hardly call it "fiixed" at this point.
Good catch though, and it gives me a good starting place to examine this
further.
Ben Root

On Sun, Jan 9, 2011 at 3:55 PM, Daniel Hyams <dh...@gm...> wrote:
> Fairly easy to demonstrate; run the code below, and press the right mouse
> button in the middle of the box somewhere,
> and rapidly zoom in/out. It might take a few seconds, but I end up with an
> exception on both Windows and OSX. If it doesn't
> give you an exception within a few seconds, let go of the right mouse
> button, and zoom more. I just push the mouse to and fro
> a few times, and it does it for me.
>
> File "C:\Python26\lib\site-packages\mpl_toolkits\mplot3d\axis3d.py", line
> 233, in draw
> newval = get_flip_min_max(xyz1[0], newindex, mins, maxs)
> IndexError: list index out of range
>
> I'm working on trying to fix, but I don't know enough about the code to be
> confident that what I do won't break something else.
>
> --------------------------- cut ------------------------------------
>
> from mpl_toolkits.mplot3d import Axes3D
> from matplotlib.ticker import LinearLocator, FixedLocator,
> FormatStrFormatter
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
> plt.show()
>
> --
> Daniel Hyams
> dh...@gm...
>
>
Technically speaking, axes3d zoom feature is very experimental (and
temperamental as you have discovered). In particular, I have noticed issues
for having multiple subplots, parts of the zoomed in figure will show up on
the neighboring subplots.
What would probably be the best way to "fix" this problem would be to
re-implement zooming so that it simply changes the limits of the displayed
3d domain. I currently do not like how zooming also zooms the entire
display (thereby losing sight of the axes labels and such). This approach
would fix that issue as well.
Ben Root

Fix (and it looks like this would need to be fixed in 1.0.1 as well):
A few lines up in draw() (line 183 in axis3d.py) there is a filter for
throwing out grid lines that are outside the axis limits. In
exceptional cases though, "interval" has a greater number listed first, then
the smaller. That in and of itself might warrant
further investigation, but simply replacing:
 majorLocs = [loc for loc in majorLocs if \
 interval[0] <= loc <= interval[1]]
with:
 if interval[0] > interval[1]: interval[1],interval[0] =
interval[0],interval[1]
 majorLocs = [loc for loc in majorLocs if \
 interval[0] <= loc <= interval[1]]
seems to solve the problem at hand.
On Sun, Jan 9, 2011 at 4:55 PM, Daniel Hyams <dh...@gm...> wrote:
> Fairly easy to demonstrate; run the code below, and press the right mouse
> button in the middle of the box somewhere,
> and rapidly zoom in/out. It might take a few seconds, but I end up with an
> exception on both Windows and OSX. If it doesn't
> give you an exception within a few seconds, let go of the right mouse
> button, and zoom more. I just push the mouse to and fro
> a few times, and it does it for me.
>
> File "C:\Python26\lib\site-packages\mpl_toolkits\mplot3d\axis3d.py", line
> 233, in draw
> newval = get_flip_min_max(xyz1[0], newindex, mins, maxs)
> IndexError: list index out of range
>
> I'm working on trying to fix, but I don't know enough about the code to be
> confident that what I do won't break something else.
>
> --------------------------- cut ------------------------------------
>
> from mpl_toolkits.mplot3d import Axes3D
> from matplotlib.ticker import LinearLocator, FixedLocator,
> FormatStrFormatter
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
> plt.show()
>
> --
> Daniel Hyams
> dh...@gm...
>
-- 
Daniel Hyams
dh...@gm...

Fairly easy to demonstrate; run the code below, and press the right mouse
button in the middle of the box somewhere,
and rapidly zoom in/out. It might take a few seconds, but I end up with an
exception on both Windows and OSX. If it doesn't
give you an exception within a few seconds, let go of the right mouse
button, and zoom more. I just push the mouse to and fro
a few times, and it does it for me.
 File "C:\Python26\lib\site-packages\mpl_toolkits\mplot3d\axis3d.py", line
233, in draw
 newval = get_flip_min_max(xyz1[0], newindex, mins, maxs)
IndexError: list index out of range
I'm working on trying to fix, but I don't know enough about the code to be
confident that what I do won't break something else.
--------------------------- cut ------------------------------------
from mpl_toolkits.mplot3d import Axes3D
from matplotlib.ticker import LinearLocator, FixedLocator,
FormatStrFormatter
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.gca(projection='3d')
plt.show()
-- 
Daniel Hyams
dh...@gm...

On Sun, Jan 9, 2011 at 11:34 AM, Adam Mercer <ram...@gm...> wrote:
> Hi
>
> In one of my codes I need to plot several time series from different
> files, the files are of the form
>
> 20100118 10
> 20100119 12
> 20100120 14
> 20100121 16
> 20100126 18
> 20100221 25
> 20100222 25
> 20100227 26
> 20100228 30
>
> I use something like the following to plot these:
>
> morning = numpy.loadtxt(morning_file, converters={0: dates.datestr2num})
> morning_plot = date_axes.plot_date(morning[:,0], morning[:,1], 'bo-', ms=4)
>
> However sometimes these files only contain a single line and my script
> fails with an error:
>
> Traceback (most recent call last):
> File "./plot.py", line 119, in <module>
> morning_plot = date_axes.plot_date(morning[:,0], morning[:,1], 'ro-',
> ms=4)
> IndexError: invalid index
>
> Is there a way that I can plot these files regardless of whether they
> contain multiple or single lines?
>
> Cheers
>
> Adam
>
>
Adam,
You have run into a peculiar numpy bug that I have reported several months
ago. Essentially, np.loadtxt() does a squeeze() on the data right before
returning it. Therefore, if there is only one line, the array returned is a
1-d array rather than your expected 2d array.
You can mitigate this by using np.atleast_2d() on the returned array. This
will guarantee that your 'morning' array will always be 2d.
I hope that helps!
Ben Root

Hi
In one of my codes I need to plot several time series from different
files, the files are of the form
20100118 10
20100119 12
20100120 14
20100121 16
20100126 18
20100221 25
20100222 25
20100227 26
20100228 30
I use something like the following to plot these:
morning = numpy.loadtxt(morning_file, converters={0: dates.datestr2num})
morning_plot = date_axes.plot_date(morning[:,0], morning[:,1], 'bo-', ms=4)
However sometimes these files only contain a single line and my script
fails with an error:
Traceback (most recent call last):
 File "./plot.py", line 119, in <module>
 morning_plot = date_axes.plot_date(morning[:,0], morning[:,1], 'ro-', ms=4)
IndexError: invalid index
Is there a way that I can plot these files regardless of whether they
contain multiple or single lines?
Cheers
Adam

Dear Benjamin,
thank you very much for your explanations, it really helped me to get
a better understanding of what's going on!
I've now tried to reverse the zpos list, i.e. instead of using
[0,1,2,3,4] as the z-value for the collections I tried to plot them as
[4,3,2,1,0] but this didn't help either...
I recall that the wrong stacking has been an issue for longer, this is
why I used a transparency setting in order to "hide" this bug.
Yet, the other bug with the wrongfully closed polygons is new: I
didn't have this a couple months back, when I created this plot for
the first time, see attachments.
Again, any help is deeply appreciated!
Best regards, Daniel
2011年1月8日 Benjamin Root <ben...@ou...>:
> On Sat, Jan 8, 2011 at 4:07 PM, Daniel Mader
> <dan...@go...> wrote:
>>
>> Hello,
>>
>> I have a problem with the 3D plotting of PolyCollections with
>> python-matplotlib-1.0.0 (on openSUSE 11.3 x86_64):
>>
>> instead of being correctly stacked as in the example
>> http://matplotlib.sourceforge.net/examples/mplot3d/polys3d_demo.html,
>> the plots are weirdly overlapping. The example works OK for me but I
>> need a PolyCollection in order to plot the results of a couple of FEM
>> simulations...
>>
>> Code is attached which demonstrates the problem. Any help is deeply
>> appreciated!
>>
>> Thanks a million times in advance,
>> best regards from Salzburg, Austria,
>>
>> Daniel
>>
>
> Daniel,
>
> The stacking problem is fairly well known (although not very well
> documented). However, this is not your bug.
>
> I haven't exactly figure out what is wrong, but it appears that a fifth
> polygon is being drawn or something that is connecting back to the (0, 0)
> point. If you redefine your polygons a bit, you will see what I mean:
>
> vertsQuad = [ [ (0,0), (0,1), (1,1), (1,0) ],
>      [ (4,1), (2,3), (2,2), (3,1)],
>      [ (0,1), (2,3), (2,2), (1,1)],
>      [ (3,0), (3,1), (4,1), (4,0)]]
>
> As an additional note, your for-loop later in the code is a bit wrong:
>
> zpos = [0, 1, 2, 3, 4]
> for i in zpos :
>   ...
>   zs = [zpos[i]]*len(vertsQuad)
>
> In this case, you are using the values of zpos as both the z-location values
> *and* as an index back to itself. Try something like this:
>
> zpos = [0, 1, 2, 3, 4]
> for zval in zpos :
>   ...
>   zs = [zval]*len(vertsQuad)
>
> That way, the values in zpos can be any numerical value, in any order, and
> it makes for easier reading.
>
> I will look a little bit further for the cause of your problem, but you can
> at least partly mitigate it by closing your polygon paths (this shouldn't be
> necessary, but go figure...):
>
> vertsQuad = [ [ (0,0), (0,1), (1,1), (1,0), (0,0) ],
>      [ (4,1), (2,3), (2,2), (3,1), (4,1)],
>      [ (0,1), (2,3), (2,2), (1,1), (0,1)],
>      [ (3,0), (3,1), (4,1), (4,0), (3,0)]]
>
> I hope this helps!
> Ben Root
>

I think this is a bug in the ghostscript (which I believe that has
been fixed recently). If you turn off antialiasing, the hatches come
out fine. Did you use "round" join-style to create this output? My
recollection is that this bug (of ghostscript) only happen when ghost
script does antialiasing for paths with "round" join style.
Regards,
-JJ
On Tue, Jan 4, 2011 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Dec 28, 2010 at 8:25 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> Benjamin,
>> Can you post the eps file?
>>
>> With matplotlib from the svn, everything is fine in my system.
>>
>> Regards,
>>
>> -JJ
>>
>>
>
> JJ,
>
> Attached is my eps file produced from the latest svn. I am using evince
> 2.30.3 to view it.
>
> Ben Root
>