matplotlib-devel Mailing List for matplotlib (Page 499)

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, It looks like you are referring to bugs in the
    Eric> Colormap.__call__ method that were introduced when I added
    Eric> support for masked values out-of-bounds values.  I have
    Eric> committed a change that fixes the bugs I could find there
    Eric> (as tested with examples/image_masked.py), so that the
    Eric> colormap call produces exactly the same output with scipy as
    Eric> with Numeric or numarray--the same rgba values.
    Eric> Unfortunately, although that demo now runs with all three,
    Eric> it produces different plots.  It appears that somewhere else
    Eric> in the code--I'm pretty sure it is not within colors.py--the
    Eric> floating point rgba values are getting rounded or, more
    Eric> likely, truncated, when using scipy.

Hey Eric,

Thanks for taking a look at this.  The only other logical place for a
problem to reside is in colors.normalize, since the pipleline is

  rgba = cmap(normalize(X))

The relevant bit of code is here -- if you or anyone else sees an
obvious candidate that might cause this truncation, let me know....  


class normalize:
    def __init__(self, vmin=None, vmax=None, clip = True):
        """
        Normalize a given value to the 0-1 range

        If vmin or vmax is not given, they are taken from the input's
        minimum and maximum value respectively.  If clip is True and
        the given value falls outside the range, the returned value
        will be 0 or 1, whichever is closer. Returns 0 if vmin==vmax.
        Works with scalars or arrays, including masked arrays.  If clip
        is True, masked values on input will be set to 1 on output; if
        clip is False, the mask will be propagated to the output.
        """
        self.vmin = vmin
        self.vmax = vmax
        self.clip = clip

    def __call__(self, value):

        if isinstance(value, (int, float)):
            vtype = 'scalar'
            val = ma.array([value])
        else:
            vtype = 'array'
            val = ma.asarray(value)

        self.autoscale(val)
        vmin, vmax = self.vmin, self.vmax
        if vmin > vmax:
            raise ValueError("minvalue must be less than or equal to maxvalue")
        elif vmin==vmax:
            return 0.*value
        else:
            if self.clip:
                val = clip(val.filled(vmax), vmin, vmax)
            result = (1.0/(vmax-vmin))*(val-vmin)
        if vtype == 'scalar':
            result = result[0]
        return result

    def autoscale(self, A):
        if not self.scaled():
            if self.vmin is None: self.vmin = ma.minimum(A)
            if self.vmax is None: self.vmax = ma.maximum(A)

    def scaled(self):
        'return true if vmin and vmax set'
        return (self.vmin is not None and self.vmax is not None)


JDH

John,

It looks like you are referring to bugs in the Colormap.__call__ method 
that were introduced when I added support for masked values 
out-of-bounds values.  I have committed a change that fixes the bugs I 
could find there (as tested with examples/image_masked.py), so that the 
colormap call produces exactly the same output with scipy as with 
Numeric or numarray--the same rgba values.  Unfortunately, although that 
demo now runs with all three, it produces different plots.  It appears 
that somewhere else in the code--I'm pretty sure it is not within 
colors.py--the floating point rgba values are getting rounded or, more 
likely, truncated, when using scipy.

Eric

John Hunter wrote:
> I just committed some changes to fix the scipy core patch.  The
> problem was that Daishi apparently had the full scipy installed, so
> many of the imports that worked in his tests did not work for scipy
> core.
> 
> Most things seem to be working, but there is a problem in the
> colormapping code in colors.py.  The index into the LUT, which should
> be an integer array, is coming out as a float array for scipy core.
> I'm not sure why.  Perry wrote this section of the code so he has a
> better understanding of it than I do (around line 240 in colors.py),
> this line is failing
> 
>         #print 'types', typecode(self._lut), typecode(xa), xa.shape
>         rgba = take(self._lut, xa)
> 
> There may be other problems, but this is the only one I know of
> currently.  
> 
> A number of the symbols in numerix.mlab that Daishi originally defined
> were from various scipy (non-core) proper modules and I could not find
> these in the core.  Will scipy core not be providing the equivalent of
> MLab.py?  There are a few of these functions used in matplotlib, and I
> just redefined them manually for now in numerix.mlab.  Eg, mean, std,
> hanning, and a few more.  Others, like cov, I buried the import into
> the function that needs them, eg in matplotlib.mlab in the
> detrend_linear function.  If these aren't going to be in the core,
> what do people suggest we do for numerix.mlab.
> 
> If anyone has any suggestions for help on the colormap LUT problem
> referenced above, that would be great.
> 
> Thanks,
> JDH
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I just committed some changes to fix the scipy core patch.  The
problem was that Daishi apparently had the full scipy installed, so
many of the imports that worked in his tests did not work for scipy
core.

Most things seem to be working, but there is a problem in the
colormapping code in colors.py.  The index into the LUT, which should
be an integer array, is coming out as a float array for scipy core.
I'm not sure why.  Perry wrote this section of the code so he has a
better understanding of it than I do (around line 240 in colors.py),
this line is failing

        #print 'types', typecode(self._lut), typecode(xa), xa.shape
        rgba = take(self._lut, xa)

There may be other problems, but this is the only one I know of
currently.  

A number of the symbols in numerix.mlab that Daishi originally defined
were from various scipy (non-core) proper modules and I could not find
these in the core.  Will scipy core not be providing the equivalent of
MLab.py?  There are a few of these functions used in matplotlib, and I
just redefined them manually for now in numerix.mlab.  Eg, mean, std,
hanning, and a few more.  Others, like cov, I buried the import into
the function that needs them, eg in matplotlib.mlab in the
detrend_linear function.  If these aren't going to be in the core,
what do people suggest we do for numerix.mlab.

If anyone has any suggestions for help on the colormap LUT problem
referenced above, that would be great.

Thanks,
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I just updated from cvs (Dec 3, 2:56 EST) and got the
    Darren> following errors when I tried to build:

    Darren> /usr/lib64/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py:13155:
    Darren> UserWarning: wxPython/wxWidgets release number mismatch
    Darren> warnings.warn("wxPython/wxWidgets release number
    Darren> mismatch") Traceback (most recent call last): File
    Darren> "setup.py", line 257, in ?  template =
    Darren> file('matplotlibrc.template').read() IOError: [Errno 2] No
    Darren> such file or directory: 'matplotlibrc.template'

Try again -- I forgot to commit this.  I decided to use a rc template
file that would insert the numerix and backend found at build time.

JDH

I just updated from cvs (Dec 3, 2:56 EST) and got the following errors when I 
tried to build:

/usr/lib64/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py:13155: 
UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
  File "setup.py", line 257, in ?
    template = file('matplotlibrc.template').read()
IOError: [Errno 2] No such file or directory: 'matplotlibrc.template'

The wxWidgets error is probably an issue with my system. Did someone forget to 
add matplotlibrc.template during a recent commit?

Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I suggest backing out the patch, removing the changes to
    Eric> "resize", and putting the modified version back.

I've been working on this in my local tree and need just a few more
modifications before committing.  I already made this change, as well
as making all three packages supported.  There are additional issues
to fix, eg the scipy.fftpack import is broken if only scipy core is
installed and not the full scipy, and Robert has been helping me a bit
with these.

JDH

I don't understand the rationale for defining these functions, and in 
particular the "resize" function that is causing problems.  It looks to 
me like all three numeric packages include both resize functions and 
resize methods, with the latter differing in that they work in place and 
require contiguous arrays.  What your patch is doing is removing access 
to the resize function, so there is no way to resize a noncontiguous array.

I suggest backing out the patch, removing the changes to "resize", and 
putting the modified version back.

Eric



da...@eg... wrote:
> On Nov 30, 2005, at 2:24 PM, John Hunter wrote:
> 
>>>>>>> "John" == John Hunter <jdh...@ac...> writes:
>>
>>
>>     John> I just committed Daishi's patch to CVS, with Fernando's
>>     John> modification to catch the new scipy versus old scipy.
>>
>> Seems there is a problem with "resize"
> 
> 
> 
> Hi John,
> 
> Sorry the patch is causing problems.
> I'm not exactly sure how the resize
> problem is coming up, however - all
> I did for those things is:
> 
> --- numerix/__init__.py:
> if (which[0] == 'numarray' or
>     which[0] == 'numeric'):
>     def typecode(a):
>         return a.typecode()
>     def iscontiguous(a):
>         return a.iscontiguous()
>     def byteswapped(a):
>         return a.byteswapped()
>     def itemsize(a):
>         return a.itemsize()
>     def resize(a, shape):
>         return a.resize(shape)
> ---
> 
> and then replace what used to be
> a.resize(shape) calls to resize(a, shape).
> 
> So aside from the extra function call
> overhead I don't see how the semantics
> would have changed (perhaps I missed
> some substitutions? I did a simple grep
> on the source tree to find occurrences
> and edited manually, so I may have just
> oops-ed a couple of them).
> 
> I'm also happy to fix the numarray&(numeric|scipy)
> thing, although it would basically just be a
> cut&paste job in setupext.py. (I'm in the middle
> of some other things right now so it may be
> a week or so before I get to this, however).
> 
> d
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 12/1/05, Charlie Moad <cw...@gm...> wrote:
>      It would help if you were more specific.  Are you referring to
> animation or static images?  I can generate a million point scatter
> plot in under a minute, and I would consider this pretty good for a
> general purpose plotting package.

Hi matplotlib'ers!
while the end result in matplotlib is starting to "get there", the speed is
not yet where it has to be to be useful IMO. I hereby post a little challen=
ge
for the matplotlib developers;

get the actual plotting time (from the first plot command until show is don=
e)
on the below dataset down to less than a second,(including the quiver
command in the plot.py file).

download the 3 files here (ca 600kb in total)

http://www.ii.uib.no/~avle/slow1/

execfile('plot.py') to plot the dataset (works for me with cvs as of today)=
.
 the first part of the file is just some convenience funcs for loading
the data. the plotting happen near the end.

this is a moderately sized grid, 433x560 cells (those of you into
oceanography may recognize the area). what I observe on my pentium
2.54ghz linux box:

-after "data ok" on screen, it takes ca15s to render. pygist uses < 0.5s
-zoom operations take ca 5s. pygist is "instant".
-you don't want to wait for an additional quiver layer. it must take
minutes to finish. pygist is instant. with quiver, also zooming is
equally slow, the ui freeze for ages.
-often one wants to add contours from other fields on top of this, in
pygist this adds no
 visible delay, matplotlib easily doubles the rendering time.

typical usage for me is to load many such datasets, and do a lot of
zoom in/out/pan to various features, modify colors/levels, add
velocity vectors etc. currently this is quite
painful in matplotlib, as one zoom operation on realistic datasets
easily takes 10 seconds on a multi ghz machine. pygist is very fast,
even on a 400mhz laptop, memory usage is also a lot lower.

so, I think matplotlib is a great effort, and shows a lot of promise, but
for realistic use, it is (at least for me) still far too slow!

Helge

No problem -- I'm pleased to contribute.  I'll check out mpl from CVS
and test it out, and I'll submit a patch for the release notes and
htdocs.

Rob

On 11/30/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Rob" =3D=3D Rob McMullen <rob...@gm...> writes:
>
>     Rob> Oh, and I didn't say so in the patch itself, but I'm happy to
>     Rob> donate the patch to matplotlib under the default matplotlib
>     Rob> license.
>
> Great Rob -- thanks.  This was the first I've heard of EMF but I read
> through your web page and it looks interesting.  I don't have time
> right now to install the prereqs and test, but you may want to grab
> the latest CVS mpl and make sure everything is working for you.
>
> You may also want to write a blurb for the release notes, and add a
> patch against the matplotlib CVS htdocs and or users guide to explain
> EMF and provide pointers to your web site on the mpl site.
>
> Checking in matplotlib/backends/backend_emf.py;
> /cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_emf.py,v  =
<--  backend_emf.py
> initial revision: 1.1
> done
>
> Thanks again,
> JDH
>

On Nov 30, 2005, at 2:24 PM, John Hunter wrote:
>>>>>> "John" == John Hunter <jdh...@ac...> writes:
>
>     John> I just committed Daishi's patch to CVS, with Fernando's
>     John> modification to catch the new scipy versus old scipy.
>
> Seems there is a problem with "resize"


Hi John,

Sorry the patch is causing problems.
I'm not exactly sure how the resize
problem is coming up, however - all
I did for those things is:

--- numerix/__init__.py:
if (which[0] == 'numarray' or
     which[0] == 'numeric'):
     def typecode(a):
         return a.typecode()
     def iscontiguous(a):
         return a.iscontiguous()
     def byteswapped(a):
         return a.byteswapped()
     def itemsize(a):
         return a.itemsize()
     def resize(a, shape):
         return a.resize(shape)
---

and then replace what used to be
a.resize(shape) calls to resize(a, shape).

So aside from the extra function call
overhead I don't see how the semantics
would have changed (perhaps I missed
some substitutions? I did a simple grep
on the source tree to find occurrences
and edited manually, so I may have just
oops-ed a couple of them).

I'm also happy to fix the numarray&(numeric|scipy)
thing, although it would basically just be a
cut&paste job in setupext.py. (I'm in the middle
of some other things right now so it may be
a week or so before I get to this, however).

d

>>>>> "Alex" == Alex Gontmakher <gs...@cs...> writes:

    Alex> Currently implemented for PostScript backend only - the rest
    Alex> ignore the command.  I tried to make it in the same style as
    Alex> the rest of Matplotlib iface: 'x' does bidiagonal hatching
    Alex> '/' does diagonal, '-' does horizontal, and so on.
    Alex> Repeating the hatching symbol increases the density of
    Alex> hatching.

    Alex> Attached is the diff for version 0.85.  Is there a chance
    Alex> for this thing to be included into the source?

Thanks Alex -- I'm happy to include this but am having trouble
applying your patch.  Could you get a fresh CVS checkout, reapply your
changes, and do a 'cvs diff'?

Thanks,
JDH

    Alex> Only in matplotlib-0.85.new: build diff -r
    Alex> matplotlib-0.85/lib/matplotlib/backend_bases.py
    Alex> matplotlib-0.85.new/lib/matplotlib/backend_bases.py 389a390
    >> self._hatch = None
    Alex> 401a403
    >> self._hatch = gc._hatch
    Alex> 549c551,558 < ---
    >>  def set_hatch(self, hatch): """ Sets the hatch style for
    >> filling """ self._hatch = hatch def get_hatch(self): return
    >> self._hatch
    Alex> Only in matplotlib-0.85.new/lib/matplotlib:
    Alex> backend_bases.py~ diff -r
    Alex> matplotlib-0.85/lib/matplotlib/backends/backend_ps.py
    Alex> matplotlib-0.85.new/lib/matplotlib/backends/backend_ps.py
    Alex> 148a149,150
    >> self.hatch = None self.hatch_func = False
    Alex> 195a198,260
    >> def set_hatch(self, hatch): """ hatch can be one of: / -
    >> diagonal hatching \ - back diagonal | - vertical - - horizontal
    >> # - crossed X - crossed diagonal letters can be combined, in
    >> which case all the specified hatchings are done if same letter
    >> repeats, it increases the density of hatching in that direction
    >> """ hatches = {'horiz':0, 'vert':0, 'diag1':0, 'diag2':0}
    >> 
    >> for letter in hatch: if (letter == '/'): hatches['diag2'] += 1
    >> elif (letter == '\\'): hatches['diag1'] += 1 elif (letter ==
    >> '|'): hatches['vert'] += 1 elif (letter == '-'):
    >> hatches['horiz'] += 1 elif (letter == '+'): hatches['horiz'] +=
    >> 1 hatches['vert'] += 1 elif (letter == 'x'): hatches['diag1']
    >> += 1 hatches['diag2'] += 1
    >> 
    >> def do_hatch(angle, density): if (density == 0): return "" orig
    >> = """ gsave eoclip %s rotate 0.0 0.0 0.0 0.0 setrgbcolor 0
    >> setlinewidth /gap %d def pathbbox /b exch def /r exch def /t
    >> exch def /l exch def l cvi gap idiv gap mul gap r cvi gap idiv
    >> gap mul {t moveto 0 b t sub rlineto} for stroke grestore """ %
    >> (angle, 12/density) return """ gsave eoclip %s rotate 0.0 0.0
    >> 0.0 0.0 setrgbcolor 0 setlinewidth /hatchgap %d def pathbbox
    >> /hatchb exch def /hatchr exch def /hatcht exch def /hatchl exch
    >> def hatchl cvi hatchgap idiv hatchgap mul hatchgap hatchr cvi
    >> hatchgap idiv hatchgap mul {hatcht moveto 0 hatchb hatcht sub
    >> rlineto} for stroke grestore """ % (angle, 12/density)
    >> self._pswriter.write("gsave\n")
    >> self._pswriter.write(do_hatch(0, hatches['horiz']))
    >> self._pswriter.write(do_hatch(90, hatches['vert']))
    >> self._pswriter.write(do_hatch(45, hatches['diag1']))
    >> self._pswriter.write(do_hatch(-45, hatches['diag2']))
    >> self._pswriter.write("grestore\n")
    >> 
    Alex> 771,772c836,837 < write(ps.strip()) < write("\n") ---
    >> write(ps.strip()) write("\n")
    Alex> 778a844,847
    >> hatch = gc.get_hatch() if (hatch): self.set_hatch(hatch)
    >> 
    Alex> Only in matplotlib-0.85.new/lib/matplotlib/backends:
    Alex> backend_ps.py~ diff -r
    Alex> matplotlib-0.85/lib/matplotlib/patches.py
    Alex> matplotlib-0.85.new/lib/matplotlib/patches.py 30a31
    >> hatch = None,
    Alex> 44a46
    >> self.hatch = hatch
    Alex> 53a56
    >> self.set_hatch(other.get_hatch())
    Alex> 114a118,128
    >> def set_hatch(self, h): """ Set the hatching pattern
    >> 
    >> ACCEPTS: string (can be one of "|,/,\,x,+", or combinations
    >> thereof") """ self.hatch = h
    >> 
    >> def get_hatch(self): 'return the current hatch pattern' return
    >> self.hatch
    Alex> 127a142,143
    >> if self.hatch != None: gc.set_hatch(self.hatch)
    Alex> Only in matplotlib-0.85.new/lib/matplotlib: patches.py~ Only
    Alex> in matplotlib-0.85.new: setupext.pyc Only in
    Alex> matplotlib-0.85/src: _na_backend_agg.cpp Only in
    Alex> matplotlib-0.85/src: _na_backend_gdk.c Only in
    Alex> matplotlib-0.85/src: _na_cntr.c Only in matplotlib-0.85/src:
    Alex> _na_image.cpp Only in matplotlib-0.85/src:
    Alex> _na_transforms.cpp Only in matplotlib-0.85/src:
    Alex> _nc_backend_agg.cpp Only in matplotlib-0.85/src:
    Alex> _nc_backend_gdk.c Only in matplotlib-0.85/src: _nc_cntr.c
    Alex> Only in matplotlib-0.85/src: _nc_image.cpp Only in
    Alex> matplotlib-0.85/src: _nc_transforms.cpp

>>>>> "Rob" == Rob McMullen <rob...@gm...> writes:

    Rob> Oh, and I didn't say so in the patch itself, but I'm happy to
    Rob> donate the patch to matplotlib under the default matplotlib
    Rob> license.

Great Rob -- thanks.  This was the first I've heard of EMF but I read
through your web page and it looks interesting.  I don't have time
right now to install the prereqs and test, but you may want to grab
the latest CVS mpl and make sure everything is working for you.

You may also want to write a blurb for the release notes, and add a
patch against the matplotlib CVS htdocs and or users guide to explain
EMF and provide pointers to your web site on the mpl site.

Checking in matplotlib/backends/backend_emf.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_emf.py,v  <--  backend_emf.py
initial revision: 1.1
done

Thanks again,
JDH

John,


> I am weakly inclined to support all three rather than one or the other
> in the interim, if only because it is a nice way to profile scipy core
> versus the old Numeric and because it may be easier to debug what is
> going on when we hit user level snags.  But since this is only an
> interim solution I'm not strongly wedded to any approach.

I agree.  I think the testing and transition will be easier if all three 
are supported for now.  I don't see much downside to doing this.

Eric

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> I just committed Daishi's patch to CVS, with Fernando's
    John> modification to catch the new scipy versus old scipy.

Seems there is a problem with "resize"

peds-pc311:~/python/projects/matplotlib/examples> python contour_demo.py --Numeric --verbose-helpful
matplotlib data path /usr/share/matplotlib
$HOME=/home/jdhunter
CONFIGDIR=/home/jdhunter/.matplotlib
loaded rc file /home/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.85.1.cvs
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 24.0b2
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend GTKAgg version 2.6.1
Traceback (most recent call last):
  File "contour_demo.py", line 29, in ?
    clabel(CS, inline=1, fontsize=10)
  File "/home/jdhunter/debs/matplotlib/usr//lib/python2.4/site-packages/matplotlib/pylab.py", line 1783, in clabel
    ret =  gca().clabel(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1264, in clabel
    return CS.clabel(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 121, in clabel
    self.labels(inline)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 338, in labels
    x,y, rotation, ind  = self.locate_label(slc, lw)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 291, in locate_label
    XX = resize(array(linecontour)[:,0],(xsize, ysize))
  File "/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py", line 87, in resize
    return a.resize(shape)
ValueError: resize only works on contiguous arrays


and for numarray


peds-pc311:~/python/projects/matplotlib/examples> python contour_demo.py --numarray --verbose-helpful
matplotlib data path /usr/share/matplotlib
$HOME=/home/jdhunter
CONFIGDIR=/home/jdhunter/.matplotlib
loaded rc file /home/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.85.1.cvs
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.3.3
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend GTKAgg version 2.6.1
Traceback (most recent call last):
  File "contour_demo.py", line 29, in ?
    clabel(CS, inline=1, fontsize=10)
  File "/home/jdhunter/debs/matplotlib/usr//lib/python2.4/site-packages/matplotlib/pylab.py", line 1783, in clabel
    ret =  gca().clabel(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1264, in clabel
    return CS.clabel(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 121, in clabel
    self.labels(inline)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 338, in labels
    x,y, rotation, ind  = self.locate_label(slc, lw)
  File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line 291, in locate_label
    XX = resize(array(linecontour)[:,0],(xsize, ysize))
  File "/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py", line 87, in resize
    return a.resize(shape)
  File "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/generic.py", line 891, in resize
    self.ravel()
  File "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/generic.py", line 922, in ravel
    self.setshape((self.nelements(),))
  File "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/generic.py", line 680, in setshape
    raise TypeError("Can't reshape non-contiguous numarray")
TypeError: Can't reshape non-contiguous numarray


Ditto on finance_demo....

JDH

I just committed Daishi's patch to CVS, with Fernando's modification
to catch the new scipy versus old scipy.

Those of you with semi-pristine boxes might want to try it out to make
sure it is working.

One issue: the patch builds either numarray (if found) and
scipy|numeric (if found but not both) with precedence given to
numeric.  Shouldn't it be the other way around, with precedence to
scipy_core over Numeric since if someone has the new scipy presumably
it's an upgrade and should take precedence.

I am weakly inclined to support all three rather than one or the other
in the interim, if only because it is a nice way to profile scipy core
versus the old Numeric and because it may be easier to debug what is
going on when we hit user level snags.  But since this is only an
interim solution I'm not strongly wedded to any approach.

Please test and report.

Checking in lib/matplotlib/numerix/__init__.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/numerix/__init__.py,v  <--  __init__.py
new revision: 1.6; previous revision: 1.5

or later.

JDH

>>>>> "James" == James Casbon <ca...@gm...> writes:

    James> Hi, The logic for displaying a figure on the interactive
    James> backends (eg qt) seems a little strange to me.  I imagine
    James> that normally the screen is used as a preview for a figure
    James> that is going to be output on paper, or to png or some
    James> permanent store.  Therefore, the interactive output should
    James> resemble the permanent output as much as possible.

    James> Now, when using the QtAgg backend (sorry no time to play
    James> with other backends) setting the figure height or width has
    James> no effect on the size of the figure displayed with show().
    James> It always comes out at 600x400.

Typically you want saved images to be at a higher resolution than the
one on the screen, since most screens are less than 1500x1500 and
often you want a higher resolution setting.  That is why the savefig
command takes a dpi parameter, which default to the settin in your rc
file.  You could make the screen dpi and the savefig dpi the same in
rc if you want.

I find that when I resize a figure in the GUI window, the aspect ratio
*is* preserved when I save, so the suggestion above should suffice for
you.

JDH

I'm having some trouble with unpickled scipy arrays. The issue shows up when I 
try to plot in matplotlib, but I think it is a scipy problem.

import pickle
import scipy
import pylab

a = scipy.arange(10)
pickle.dump(a,file('temp.p','w'))
b = pickle.load(file('temp.p'))
print type(b), type(scipy.array(b))
pylab.plot(scipy.array(b)) # no error here
pylab.plot(b) # error here

Traceback (most recent call last):
  File "pickletest.py", line 8, in ?
    pylab.plot(b)
  File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line 2055, in 
plot
    ret =  gca().plot(*args, **kwargs)
  File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 2636, in 
plot
    for line in self._get_lines(*args, **kwargs):
  File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 267, in 
_grab_next_args
    yield self._plot_1_arg(remaining[0], **kwargs)
  File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 189, in 
_plot_1_arg
    markerfacecolor=color,
  File "/usr/lib64/python2.4/site-packages/matplotlib/lines.py", line 209, in 
__init__
    self.set_data(xdata, ydata)
  File "/usr/lib64/python2.4/site-packages/matplotlib/lines.py", line 265, in 
set_data
    y = ma.ravel(y)
  File "/usr/lib64/python2.4/site-packages/Numeric/MA/MA.py", line 1810, in 
ravel
    d = Numeric.ravel(filled(a))
  File "/usr/lib64/python2.4/site-packages/Numeric/MA/MA.py", line 222, in 
filled
    return Numeric.array(a)
ValueError: cannot handle misaligned or not writeable arrays.


Darren

Eric Firing wrote:
> John,
>
> I have committed to CVS a set of changes that I think will address 
> recent requests by Jordan and Gerald, and will be of more general use 
> as well.  From the CHANGELOG:
>
> 2005-11-27 Multiple changes in cm.py, colors.py, figure.py, image.py,
>            contour.py, contour_demo.py; new _cm.py, 
> examples/image_masked.py.
>            1) Separated the color table data from cm.py out into
>            a new file, _cm.py, to make it easier to find the actual
>            code in cm.py and to add new colormaps.  Also added
>            some line breaks to the color data dictionaries. Everything
>            from _cm.py is imported by cm.py, so the split should be
>            transparent.
>            2) Enabled automatic generation of a colormap from
>            a list of colors in contour; see modified
>            examples/contour_demo.py.
>            3) Support for imshow of a masked array, with the
>            ability to specify colors (or no color at all) for
>            masked regions, and for regions that are above or
>            below the normally mapped region.  See
>            examples/image_masked.py.
>            4) In support of the above, added two new classes,
>            ListedColormap, and no_norm, to colors.py, and modified
>            the Colormap class to include common functionality. Added
>            a clip kwarg to the normalize class.  Reworked color
>            handling in contour.py, especially in the ContourLabeller
>            mixin.
>
> With one very subtle exception, I don't think any default behaviors 
> have been changed, so the changes should be entirely non-disruptive.
>
> That one exception is that in the original color mapping scheme, the 
> last color was essentially never used.  Consider an extreme case: a 
> colormap with two entries.  Suppose the image data ranged from 0 to 1. 
> All values except exactly 1.0 were mapped to the first color, and only 
> that upper limit value was mapped to the second color.  As I have 
> changed colors.py, values from 0.0 up to 0.5 will get the first color, 
> and values from 0.5 through 1.0 will get the second.  I think this is 
> what a user would expect, and the only reason it hasn't mattered is 
> that with 256 colors in a continuous range, one can't see the difference.
>
> The request from Jordan that is addressed here is the desire for 
> precise color control in filled contouring.  Now one can specify a 
> list of colors in the "colors" kwarg, and they will be used to 
> generate a colormap, which will then be used by colorbar.  This is 
> shown in a second plot added to examples/contourf_demo.py.  (Jordan 
> suggested a more extensive refactoring, which may indeed be a good 
> idea; but I wanted to make these simpler changes before trying to 
> think about anything more drastic.)
>
> The request from Gerald was for easy handling of masked arrays in 
> imshow.  It was in the context of basemap, which I have not tested 
> yet; but at least for pylab.imshow, the situation is now easy to 
> handle.  If changes to basemap are needed, they should be very simple, 
> and I can do them later as needed.  I think that the changes to 
> colormapping that I made to support this will be useful much more 
> widely, but I have made no attempt to track down the places where 
> changes will be in order.  I may make additional changes to contour, 
> and I know I will need to change colorbar to fully support this.  I 
> think colorbar needs some more refactoring anyway, but I can't do it 
> immediately, and I did not want to delay getting the other changes out 
> for testing and, hopefully, productive use.
>
> Eric

Eric:  Tried the masked imshow with basemap and it seems to work fine 
(without any modifications to basemap).  I've added a new example, 
plotmap_masked.py, that shows how to use mask out the oceans on a map 
using imshow and pcolor.  Thanks again!

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Using the 0.85 package for ubuntu, I get the following error when I run my
application:

 

?

    from matplotlib.dates import date2num, num2date, DateFormatter,
IndexDateFormatter

  File
"/home/jdhunter/debs/matplotlib/usr/lib/python2.4/site-packages/matplotlib/d
ates.py", line 88, in ?

ImportError: No module named pytz

 

Any ideas?

 

Thanks,

 

VJ

Eric,

I played with the changes you've made and the results look great!

Thanks,

Gerald

Eric Firing wrote:
> John,
> 
> I have committed to CVS a set of changes that I think will address 
> recent requests by Jordan and Gerald, and will be of more general use as 
> well.  From the CHANGELOG:
> 
> 2005-11-27 Multiple changes in cm.py, colors.py, figure.py, image.py,
>            contour.py, contour_demo.py; new _cm.py, 
> examples/image_masked.py.
>            1) Separated the color table data from cm.py out into
>            a new file, _cm.py, to make it easier to find the actual
>            code in cm.py and to add new colormaps.  Also added
>            some line breaks to the color data dictionaries. Everything
>            from _cm.py is imported by cm.py, so the split should be
>            transparent.
>            2) Enabled automatic generation of a colormap from
>            a list of colors in contour; see modified
>            examples/contour_demo.py.
>            3) Support for imshow of a masked array, with the
>            ability to specify colors (or no color at all) for
>            masked regions, and for regions that are above or
>            below the normally mapped region.  See
>            examples/image_masked.py.
>            4) In support of the above, added two new classes,
>            ListedColormap, and no_norm, to colors.py, and modified
>            the Colormap class to include common functionality. Added
>            a clip kwarg to the normalize class.  Reworked color
>            handling in contour.py, especially in the ContourLabeller
>            mixin.
> 
> With one very subtle exception, I don't think any default behaviors have 
> been changed, so the changes should be entirely non-disruptive.
> 
> That one exception is that in the original color mapping scheme, the 
> last color was essentially never used.  Consider an extreme case: a 
> colormap with two entries.  Suppose the image data ranged from 0 to 1. 
> All values except exactly 1.0 were mapped to the first color, and only 
> that upper limit value was mapped to the second color.  As I have 
> changed colors.py, values from 0.0 up to 0.5 will get the first color, 
> and values from 0.5 through 1.0 will get the second.  I think this is 
> what a user would expect, and the only reason it hasn't mattered is that 
> with 256 colors in a continuous range, one can't see the difference.
> 
> The request from Jordan that is addressed here is the desire for precise 
> color control in filled contouring.  Now one can specify a list of 
> colors in the "colors" kwarg, and they will be used to generate a 
> colormap, which will then be used by colorbar.  This is shown in a 
> second plot added to examples/contourf_demo.py.  (Jordan suggested a 
> more extensive refactoring, which may indeed be a good idea; but I 
> wanted to make these simpler changes before trying to think about 
> anything more drastic.)
> 
> The request from Gerald was for easy handling of masked arrays in 
> imshow.  It was in the context of basemap, which I have not tested yet; 
> but at least for pylab.imshow, the situation is now easy to handle.  If 
> changes to basemap are needed, they should be very simple, and I can do 
> them later as needed.  I think that the changes to colormapping that I 
> made to support this will be useful much more widely, but I have made no 
> attempt to track down the places where changes will be in order.  I may 
> make additional changes to contour, and I know I will need to change 
> colorbar to fully support this.  I think colorbar needs some more 
> refactoring anyway, but I can't do it immediately, and I did not want to 
> delay getting the other changes out for testing and, hopefully, 
> productive use.
> 
> Eric
> 
> 
> 

I finally tracked down another flipy type bug.  The TkAgg blitting
should be rock solid now.

Thanks,
     Charlie

On 11/22/05, Charlie Moad <cw...@gm...> wrote:
> Arg!  One petty thing after another.  Here is a simple script
> demonstrating that the last row does not render the SpanSelector, yet
> the callback works fine???
>
> ------------------------------------
> import matplotlib
> from matplotlib.widgets import SpanSelector
> matplotlib.use('TkAgg')
> from pylab import *
>
> s =3D 3
> axs =3D [subplot(s,s,i) for i in xrange(1,s**2+1)]
> def onselect(x, y): print x, y
> [SpanSelector(a, onselect, 'vertical', useblit=3DTrue) for a in axs]
> show()
> ------------------------------------
>
> Any clues as to where to look for this bug?  Sorry to be a hassle, but
> I need this specifically to embed in a Tk only app.
>
> Thanks,
>      Charlie
>
> On 11/19/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> >     Charlie> Awesome, thanks!  Out of curiousity... did you figure
> >     Charlie> this out visually or by comparing with something?
> >
> > Let's just say I've encountered the flipy bug before :-)
> >
> > JDH
> >
>

Eric Firing wrote:
> John,
>
> I have committed to CVS a set of changes that I think will address 
> recent requests by Jordan and Gerald, and will be of more general use 
> as well.  From the CHANGELOG:
>
> 2005-11-27 Multiple changes in cm.py, colors.py, figure.py, image.py,
>            contour.py, contour_demo.py; new _cm.py, 
> examples/image_masked.py.
>            1) Separated the color table data from cm.py out into
>            a new file, _cm.py, to make it easier to find the actual
>            code in cm.py and to add new colormaps.  Also added
>            some line breaks to the color data dictionaries. Everything
>            from _cm.py is imported by cm.py, so the split should be
>            transparent.
>            2) Enabled automatic generation of a colormap from
>            a list of colors in contour; see modified
>            examples/contour_demo.py.
>            3) Support for imshow of a masked array, with the
>            ability to specify colors (or no color at all) for
>            masked regions, and for regions that are above or
>            below the normally mapped region.  See
>            examples/image_masked.py.
>            4) In support of the above, added two new classes,
>            ListedColormap, and no_norm, to colors.py, and modified
>            the Colormap class to include common functionality. Added
>            a clip kwarg to the normalize class.  Reworked color
>            handling in contour.py, especially in the ContourLabeller
>            mixin.
>
> With one very subtle exception, I don't think any default behaviors 
> have been changed, so the changes should be entirely non-disruptive.
>
> That one exception is that in the original color mapping scheme, the 
> last color was essentially never used.  Consider an extreme case: a 
> colormap with two entries.  Suppose the image data ranged from 0 to 1. 
> All values except exactly 1.0 were mapped to the first color, and only 
> that upper limit value was mapped to the second color.  As I have 
> changed colors.py, values from 0.0 up to 0.5 will get the first color, 
> and values from 0.5 through 1.0 will get the second.  I think this is 
> what a user would expect, and the only reason it hasn't mattered is 
> that with 256 colors in a continuous range, one can't see the difference.
>
> The request from Jordan that is addressed here is the desire for 
> precise color control in filled contouring.  Now one can specify a 
> list of colors in the "colors" kwarg, and they will be used to 
> generate a colormap, which will then be used by colorbar.  This is 
> shown in a second plot added to examples/contourf_demo.py.  (Jordan 
> suggested a more extensive refactoring, which may indeed be a good 
> idea; but I wanted to make these simpler changes before trying to 
> think about anything more drastic.)
>
> The request from Gerald was for easy handling of masked arrays in 
> imshow.  It was in the context of basemap, which I have not tested 
> yet; but at least for pylab.imshow, the situation is now easy to 
> handle.  If changes to basemap are needed, they should be very simple, 
> and I can do them later as needed.  I think that the changes to 
> colormapping that I made to support this will be useful much more 
> widely, but I have made no attempt to track down the places where 
> changes will be in order.  I may make additional changes to contour, 
> and I know I will need to change colorbar to fully support this.  I 
> think colorbar needs some more refactoring anyway, but I can't do it 
> immediately, and I did not want to delay getting the other changes out 
> for testing and, hopefully, productive use.
>
> Eric
>
Eric:  This is fantastic - thanks!  I'll try imshow with masked arrays 
and let you know if there are any problems.  Should be very useful for 
projections which have some parts hidden, such as orthographic.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

John,

I think that the following change, from API_CHANGES, is causing trouble:

     made pos=None the default for tick formatters rather than 0 to
     indicate "not supplied"

The symptom is that running (for example) contour_demo.py from the 
command line with gtkagg backend, I often, but not always, get a blast 
of errors like this:

Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 188, in motion_notify_event
     FigureCanvasBase.motion_notify_event(self, x, y)
   File "/usr/lib/python2.4/site-packages/matplotlib/backend_bases.py", 
line 797, in motion_notify_event
     func(event)
   File "/usr/lib/python2.4/site-packages/matplotlib/backend_bases.py", 
line 1085, in mouse_move
     try: s = event.inaxes.format_coord(event.xdata, event.ydata)
   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 612, 
in format_coord
     ys = self.format_ydata(y)
   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 605, 
in format_ydata
     val =  func(y)
   File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
152, in format_data
     return self.__call__(value)
   File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
178, in __call__
     else: return self.seq[pos]
TypeError: list indices must be integers


pos=None would certainly cause this...but I haven't checked it.

(System is stock Mandriva 2006; mpl is CVS.)

Eric

John,

I have committed to CVS a set of changes that I think will address 
recent requests by Jordan and Gerald, and will be of more general use as 
well.  From the CHANGELOG:

2005-11-27 Multiple changes in cm.py, colors.py, figure.py, image.py,
            contour.py, contour_demo.py; new _cm.py, 
examples/image_masked.py.
            1) Separated the color table data from cm.py out into
            a new file, _cm.py, to make it easier to find the actual
            code in cm.py and to add new colormaps.  Also added
            some line breaks to the color data dictionaries. Everything
            from _cm.py is imported by cm.py, so the split should be
            transparent.
            2) Enabled automatic generation of a colormap from
            a list of colors in contour; see modified
            examples/contour_demo.py.
            3) Support for imshow of a masked array, with the
            ability to specify colors (or no color at all) for
            masked regions, and for regions that are above or
            below the normally mapped region.  See
            examples/image_masked.py.
            4) In support of the above, added two new classes,
            ListedColormap, and no_norm, to colors.py, and modified
            the Colormap class to include common functionality. Added
            a clip kwarg to the normalize class.  Reworked color
            handling in contour.py, especially in the ContourLabeller
            mixin.

With one very subtle exception, I don't think any default behaviors have 
been changed, so the changes should be entirely non-disruptive.

That one exception is that in the original color mapping scheme, the 
last color was essentially never used.  Consider an extreme case: a 
colormap with two entries.  Suppose the image data ranged from 0 to 1. 
All values except exactly 1.0 were mapped to the first color, and only 
that upper limit value was mapped to the second color.  As I have 
changed colors.py, values from 0.0 up to 0.5 will get the first color, 
and values from 0.5 through 1.0 will get the second.  I think this is 
what a user would expect, and the only reason it hasn't mattered is that 
with 256 colors in a continuous range, one can't see the difference.

The request from Jordan that is addressed here is the desire for precise 
color control in filled contouring.  Now one can specify a list of 
colors in the "colors" kwarg, and they will be used to generate a 
colormap, which will then be used by colorbar.  This is shown in a 
second plot added to examples/contourf_demo.py.  (Jordan suggested a 
more extensive refactoring, which may indeed be a good idea; but I 
wanted to make these simpler changes before trying to think about 
anything more drastic.)

The request from Gerald was for easy handling of masked arrays in 
imshow.  It was in the context of basemap, which I have not tested yet; 
but at least for pylab.imshow, the situation is now easy to handle.  If 
changes to basemap are needed, they should be very simple, and I can do 
them later as needed.  I think that the changes to colormapping that I 
made to support this will be useful much more widely, but I have made no 
attempt to track down the places where changes will be in order.  I may 
make additional changes to contour, and I know I will need to change 
colorbar to fully support this.  I think colorbar needs some more 
refactoring anyway, but I can't do it immediately, and I did not want to 
delay getting the other changes out for testing and, hopefully, 
productive use.

Eric

On Wednesday 23 November 2005 19:51, da...@eg... wrote:
> Unfortunately, I can't seem to recreate your problem.

The problem is that I have both Numeric[1] and the new scipy installed. When 
both are installed, the Numeric headers are picked up by default during scipy 
compilation. By forcing them to pick up the scipy headers, the problem was 
resolved. But it is a rather strange coincidence that the error results in 
truncated numbers rather than something drastic.

Ravi

[1] Reason: It will be a while before all my Numeric-based libraries are 
ported to the new scipy; porting is trivial, but regression testing takes 
time, especially given that the new scipy C API is not quite stable yet and 
that I haven't yet ported boost.python.numeric to scipy.