matplotlib-devel Mailing List for matplotlib

On 09/18/2011 11:15 AM, John Hunter wrote:
> On Sun, Sep 18, 2011 at 4:02 PM, Eric Firing<ef...@ha...> wrote:
>> There is a way to deal with this now: define our own copyto which uses
>> np.copyto if it exists, and falls back on putnav otherwise. I think this
>> can be done with reasonable safety and no loss of performance. The only
>> question is where to put our copyto. I think a new compat.py would make
>> sense as a home for this sort of version compatibility interface code. We
>> may need a lot more in the future as numpy evolves.
>
> We used to put these in cbook I believe; eg functions that existed in
> python2.3 that we wanted to use but weren't defined in python2.2 which
> we supported. We could prefix them with a leading underscore to steer
> users away from them
>
> def _copyto(...):
> # temporary function to use numpy's copyto if it is defined, else
> putmask; this function will be deprecated when we support only numpy
> 2.0 and later
> ...
>
> I'd be in favor of doing this, because deprecations warnings are a nuisance.
>
> JDH
See
https://github.com/matplotlib/matplotlib/pull/480
Eric

On 09/18/2011 09:30 AM, Christoph Gohlke wrote:
> Hello,
>
> matplotlib uses int(x*255) or np.array(x*255, np.uint8) to quantize
> normalized floating point numbers x in the range [0.0 to 1.0] to
> integers in the range [0 to 255]. This way only 1.0 is mapped to 255,
> not for example 0.999. Is this really intended or would not the largest
> floating point number below 256.0 be a better scale factor than 255? The
> exact factor depends on the floating point precision (~255.999992 for
> np.float32, ~255.93 for np.float16).
>
> Christoph
Christoph,
It's a reasonable question; but do you have use cases in mind where it 
actually makes a difference?
The simple scaling with truncation is used in many places, both in the 
python and the c++ code.
Eric

On Sun, Sep 18, 2011 at 2:02 PM, Eric Firing <ef...@ha...> wrote:
> There is a way to deal with this now: define our own copyto which uses
> np.copyto if it exists, and falls back on putnav otherwise. I think
> this can be done with reasonable safety and no loss of performance. The
> only question is where to put our copyto. I think a new compat.py would
> make sense as a home for this sort of version compatibility interface
> code. We may need a lot more in the future as numpy evolves.
If you want to just silence this particular warning, it can be done
with this code:
import warnings
warnings.filterwarnings('ignore', 'putmask has been deprecated',
 DeprecationWarning)
That would be enough to keep numpy quiet about this for now...
Cheers,
f

On Sun, Sep 18, 2011 at 4:02 PM, Eric Firing <ef...@ha...> wrote:
> There is a way to deal with this now: define our own copyto which uses
> np.copyto if it exists, and falls back on putnav otherwise. I think this
> can be done with reasonable safety and no loss of performance. The only
> question is where to put our copyto. I think a new compat.py would make
> sense as a home for this sort of version compatibility interface code. We
> may need a lot more in the future as numpy evolves.
We used to put these in cbook I believe; eg functions that existed in
python2.3 that we wanted to use but weren't defined in python2.2 which
we supported. We could prefix them with a leading underscore to steer
users away from them
def _copyto(...):
 # temporary function to use numpy's copyto if it is defined, else
putmask; this function will be deprecated when we support only numpy
2.0 and later
 ...
I'd be in favor of doing this, because deprecations warnings are a nuisance.
JDH

On 09/18/2011 09:46 AM, Fernando Perez wrote:
> On Sun, Sep 18, 2011 at 12:41 PM, John Hunter<jd...@gm...> wrote:
>>
>> I'm on 11.04, 64 bit also.
>>
>> What does this give you?
>>
>> > ython -c 'import numpy as np; print np.__version__; x =
>> np.random.rand(10); np.putmask(x, x<0.5, 0.)'
>>
>> I only get the version string 2.0.0.dev-aded70c, no warning.
>
> It seems to be python version-dependent, my system python is 2.6 and I
> get the warning:
>
> (master)dreamweaver[matplotlib]> python -c 'import numpy as np; print
> np.__version__; x = np.random.rand(10); np.putmask(x, x<0.5, 0.)'
> 2.0.0.dev-aded70c
> -c:1: DeprecationWarning: putmask has been deprecated. Use copyto with
> 'where' as the mask instead
>
> but with 2.7 I don't:
>
> (master)dreamweaver[matplotlib]> python2.7 -c 'import numpy as np;
> print np.__version__; x = np.random.rand(10); np.putmask(x, x<0.5,
> 0.)'
> 2.0.0.dev-aded70c
Right.
http://docs.python.org/dev/whatsnew/2.7.html explains the change in 
handling DeprecationWarning.
Eric
>
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 09/18/2011 09:54 AM, John Hunter wrote:
>> putmask was deprecated in favor of copyto only 2 months ago; copyto
>> didn't even exist before that. So we certainly can't replace putmask
>> with copyto in mpl.
>>
>> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b
>
>
> The putmasks in colors.py are simple and could be replaced by a simple
> boolean, mask eg replace
>
> np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
>
> with
>
> xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.
>
> In quiver.py, there appear to be some broadcasting shape issues that
> make this trickier, eg in
>
> short = np.repeat(length< minsh, 8, axis=1)
> # Now select X0, Y0 if short, otherwise X, Y
> np.putmask(X, short, X0)
>
> Since much of quiver.py is your code I believe Eric, maybe you can
> come up with something that doesn't rely on putmasking and just uses
> plain vanilla boolean arrays of the right shape?
>
> JDH
John,
There is a way to deal with this now: define our own copyto which uses 
np.copyto if it exists, and falls back on putnav otherwise. I think 
this can be done with reasonable safety and no loss of performance. The 
only question is where to put our copyto. I think a new compat.py would 
make sense as a home for this sort of version compatibility interface 
code. We may need a lot more in the future as numpy evolves.
Eric

On 09/18/2011 09:54 AM, John Hunter wrote:
>> putmask was deprecated in favor of copyto only 2 months ago; copyto
>> didn't even exist before that. So we certainly can't replace putmask
>> with copyto in mpl.
>>
>> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b
>
>
> The putmasks in colors.py are simple and could be replaced by a simple
> boolean, mask eg replace
>
> np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
>
> with
>
> xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.
>
> In quiver.py, there appear to be some broadcasting shape issues that
> make this trickier, eg in
>
> short = np.repeat(length< minsh, 8, axis=1)
> # Now select X0, Y0 if short, otherwise X, Y
> np.putmask(X, short, X0)
>
> Since much of quiver.py is your code I believe Eric, maybe you can
> come up with something that doesn't rely on putmasking and just uses
> plain vanilla boolean arrays of the right shape?
I really don't want to mess with this now; putmask was used because it 
is *much* faster than boolean indexing (after I supplied the 
fast_putmask code to numpy back in 2007). And I did that because it 
removed a genuine, significant bottleneck in mpl. Now, with Mark 
Wiebe's modifications to numpy, putmask is obsolete. His copyto is as 
fast, and boolean indexing might even be good enough now. But the next 
mpl release is not targeted at numpy 2.0. It will be used with older 
versions as well, and probably most often.
We will need to deal with the deprecation of putmask, but this is not 
the time to do it, unless there is a way to do it that does *not* change 
the present actual *use* of putmask, but merely tells numpy to shut up 
about it. I don't know why it is complaining; I don't think that it is 
normal procedure to start issuing warnings the minute a replacement 
(copyto) appears.
We are trying to get a release out without introducing major breakage. 
It is a bad time to muck around with internals like the use of putmask.
Eric
>
> JDH

> putmask was deprecated in favor of copyto only 2 months ago; copyto
> didn't even exist before that. So we certainly can't replace putmask
> with copyto in mpl.
>
> http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b
The putmasks in colors.py are simple and could be replaced by a simple
boolean, mask eg replace
 np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
with
 xa[xa==1.0] = 0.9999999 #Treat 1.0 as slightly less than 1.
In quiver.py, there appear to be some broadcasting shape issues that
make this trickier, eg in
 short = np.repeat(length < minsh, 8, axis=1)
 # Now select X0, Y0 if short, otherwise X, Y
 np.putmask(X, short, X0)
Since much of quiver.py is your code I believe Eric, maybe you can
come up with something that doesn't rely on putmasking and just uses
plain vanilla boolean arrays of the right shape?
JDH

On Sun, Sep 18, 2011 at 12:41 PM, John Hunter <jd...@gm...> wrote:
>
> I'm on 11.04, 64 bit also.
>
> What does this give you?
>
> > ython -c 'import numpy as np; print np.__version__; x =
> np.random.rand(10); np.putmask(x, x<0.5, 0.)'
>
> I only get the version string 2.0.0.dev-aded70c, no warning.
It seems to be python version-dependent, my system python is 2.6 and I
get the warning:
(master)dreamweaver[matplotlib]> python -c 'import numpy as np; print
np.__version__; x = np.random.rand(10); np.putmask(x, x<0.5, 0.)'
2.0.0.dev-aded70c
-c:1: DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
but with 2.7 I don't:
(master)dreamweaver[matplotlib]> python2.7 -c 'import numpy as np;
print np.__version__; x = np.random.rand(10); np.putmask(x, x<0.5,
0.)'
2.0.0.dev-aded70c
Cheers,
f

On 09/18/2011 09:24 AM, Fernando Perez wrote:
> On Sun, Sep 18, 2011 at 12:05 PM, John Hunter<jd...@gm...> wrote:
>> I can fix these putmask calls, but strangely I am not seeing the
>> deprecation warning on numpy and mpl HEAD
putmask was deprecated in favor of copyto only 2 months ago; copyto 
didn't even exist before that. So we certainly can't replace putmask 
with copyto in mpl.
http://currents.soest.hawaii.edu/hgstage/numpy_from_git/rev/26533521322b
Eric
>>
>> In [1]: print np.__version__
>> 2.0.0.dev-aded70c
>>
>> In [2]: print matplotlib.__version__
>> 1.1.0
>>
>> In [3]: imshow(rand(10,10))
>> Out[3]:<matplotlib.image.AxesImage at 0x48ff8d0>
>
> Weird, I'm on the same; I just did a clean git pull right before building:
>
> In [1]: np.__version__
> Out[1]: '2.0.0.dev-aded70c'
>
> In [2]: matplotlib.__version__
> Out[2]: '1.1.0'
>
> (master)dreamweaver[matplotlib]> git log --oneline | head -1
> fcc8039 axisartist: implement LocatorDM, LocatorD, LocatorHM, LocatorH
> and update FormatterHMS and FormaterDMS
>
>
> This is on a linux 10.10 box, 64-bit just in case it matters. I
> haven't tested it on 32-bits. The problem also appears (at least for
> me) on my office box that you have access to.
>
> Happy to test further...
>
> f
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,
matplotlib uses int(x*255) or np.array(x*255, np.uint8) to quantize 
normalized floating point numbers x in the range [0.0 to 1.0] to 
integers in the range [0 to 255]. This way only 1.0 is mapped to 255, 
not for example 0.999. Is this really intended or would not the largest 
floating point number below 256.0 be a better scale factor than 255? The 
exact factor depends on the floating point precision (~255.999992 for 
np.float32, ~255.93 for np.float16).
Christoph

On Sun, Sep 18, 2011 at 12:05 PM, John Hunter <jd...@gm...> wrote:
> I can fix these putmask calls, but strangely I am not seeing the
> deprecation warning on numpy and mpl HEAD
>
> In [1]: print np.__version__
> 2.0.0.dev-aded70c
>
> In [2]: print matplotlib.__version__
> 1.1.0
>
> In [3]: imshow(rand(10,10))
> Out[3]: <matplotlib.image.AxesImage at 0x48ff8d0>
Weird, I'm on the same; I just did a clean git pull right before building:
In [1]: np.__version__
Out[1]: '2.0.0.dev-aded70c'
In [2]: matplotlib.__version__
Out[2]: '1.1.0'
(master)dreamweaver[matplotlib]> git log --oneline | head -1
fcc8039 axisartist: implement LocatorDM, LocatorD, LocatorHM, LocatorH
and update FormatterHMS and FormaterDMS
This is on a linux 10.10 box, 64-bit just in case it matters. I
haven't tested it on 32-bits. The problem also appears (at least for
me) on my office box that you have access to.
Happy to test further...
f

On Sun, Sep 18, 2011 at 1:17 AM, Christoph Gohlke <cg...@uc...> wrote:
> The master branch builds OK on Windows and so far almost everything
> worked well.
>
> I have trouble receiving the sample_data from github via cbook.py. There
> are frequent HTTP 304 (Not Modified) and 500 (Internal Server Error)
> exceptions and redirection to
> <https://raw.github.com/matplotlib/sample_data/master>.
I confirmed this on linux and added an issue on github:
https://github.com/matplotlib/matplotlib/issues/478. I also assigned
a new tag "release_critical" which we should use as we close in on the
release to mark show-stopper issues. I assigned this to Jouni since
he wrote most of the original implementation. Jouni, if you can't get
to this let me know and I'll take a look.
JDH

On Sun, Sep 18, 2011 at 1:44 PM, Fernando Perez <fpe...@gm...> wrote:
> I'm not sure why, but as of a few weeks ago, with recent builds of
> numpy/mpl I always get these warnings:
>
> In [1]: imshow(rand(10,10))
> Out[1]: <matplotlib.image.AxesImage at 0x278f390>
>
> In [2]: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:519:
> DeprecationWarning: putmask has been deprecated. Use copyto with
> 'where' as the mask instead
> np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:531:
> DeprecationWarning: putmask has been deprecated. Use copyto with
> 'where' as the mask instead
> np.putmask(xa, xa<0.0, -1)
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:535:
> DeprecationWarning: putmask has been deprecated. Use copyto with
> 'where' as the mask instead
> np.putmask(xa, xa>self.N-1, self._i_over)
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:536:
> DeprecationWarning: putmask has been deprecated. Use copyto with
> 'where' as the mask instead
> np.putmask(xa, xa<0, self._i_under)
>
>
> It would be nice to have these gone from master before release.
I can fix these putmask calls, but strangely I am not seeing the
deprecation warning on numpy and mpl HEAD
 In [1]: print np.__version__
 2.0.0.dev-aded70c
 In [2]: print matplotlib.__version__
 1.1.0
 In [3]: imshow(rand(10,10))
 Out[3]: <matplotlib.image.AxesImage at 0x48ff8d0>
If I do a simple putmask test I also don't get the warning
 In [4]: x = np.random.rand(10)
 In [5]: np.putmask(x, x<0.5, 0)
Do you have some custom warning or error settings turned on/ What
commit of np are you on?
I like how they have the commit hash in the version number; we need that.

I'm not sure why, but as of a few weeks ago, with recent builds of
numpy/mpl I always get these warnings:
In [1]: imshow(rand(10,10))
Out[1]: <matplotlib.image.AxesImage at 0x278f390>
In [2]: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:519:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
 np.putmask(xa, xa==1.0, 0.9999999) #Treat 1.0 as slightly less than 1.
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:531:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
 np.putmask(xa, xa<0.0, -1)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:535:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
 np.putmask(xa, xa>self.N-1, self._i_over)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/colors.py:536:
DeprecationWarning: putmask has been deprecated. Use copyto with
'where' as the mask instead
 np.putmask(xa, xa<0, self._i_under)
It would be nice to have these gone from master before release.
Cheers,
f

Hello,
there are some scripts in the data/ dir (I'm not even sure they're
needed at all, but they are there) missing the shebang; attached patch
adds it.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sun, Sep 18, 2011 at 16:53, John Hunter <jd...@gm...> wrote:
> Take a look at
>
> https://github.com/matplotlib/basemap/blob/master/README
>
> Does this have everything you need?
Gaah, I was overwhelmed by the third-party tools copyright/licenses I
missed the basemap ones: thanks John!
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sun, Sep 18, 2011 at 9:46 AM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> I'm packaging basemap for Debian, but as you know, we always have some
> problems :)
>
> One important part of Debian packaging is the license/copyright
> checks, but for basemap I can't find any explicit indication of them:
>
> for license I have
>
>  OSI Approved
>
> that doesn't mean anything (legally speaking): for example, is it BSD
> or GPL-3 ? the difference is *huge*
>
> and for copyright I only have the author, but not the years of
> validity, except for a single 2006 reference.
>
> Could you please mention them explicitly with the next release of basemap?
>
> Thanks in advance,
Take a look at
https://github.com/matplotlib/basemap/blob/master/README
Does this have everything you need?

Hi,
when running
 python setup.py clean
nad2bin is compiled. I've just worked around with the attached patch,
so it would be nice if you can integrate it upstream or come up with a
better solution.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello,
I'm packaging basemap for Debian, but as you know, we always have some
problems :)
One important part of Debian packaging is the license/copyright
checks, but for basemap I can't find any explicit indication of them:
for license I have
 OSI Approved
that doesn't mean anything (legally speaking): for example, is it BSD
or GPL-3 ? the difference is *huge*
and for copyright I only have the author, but not the years of
validity, except for a single 2006 reference.
Could you please mention them explicitly with the next release of basemap?
Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Eric Firing <ef...@ha...> writes:
> image_interp pdf
I bisected this to
79ca159 recover old behavior for 'nearest' interpolation and introduces 'none'. close #83
which changes the meaning of "nearest" interpolation but does not change
the corresponding test. I'll send a pull request to fix this soon.
This reminds me: what's the status of the buildbot? Regular buildbot
runs would have caught this much sooner. If I could find some place to
run buildbot, does the git repository contain all the necessary scripts
and configuration or is it more work to set it up?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 9/17/2011 7:16 PM, Eric Firing wrote:
> On 09/17/2011 12:17 PM, Christoph Gohlke wrote:
>>
>>
>> On 9/17/2011 2:08 PM, Benjamin Root wrote:
>>> I think it will take a declaration of a firm deadline. How about this?
>>>
>>> Cut RC release Friday, Sept 23rd
>>> Release v1.1.0 Friday, Sept. 30th.
>>> (Barring any major significant changes)
>>>
>>> In particular, for the RC, I want to make sure that installation and
>>> documents for the installation is solid. I will have on hand an older,
>>> stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
>>> Leopard (one is 32 bits while the other is 64, I think).
>>>
>>> As a side note, the macbook can be used for automated build/test machine
>>> as it really isn't useful for anything else for me.
>>>
>>> Ben Root
>>>
>>
>> That sounds to me as if the master branch is at release quality, or very
>> close to. I could test it on Windows this weekend if that's true.
>
> Christoph,
>
> It should be close. There are still three test failures, which I noted
> in a separate message to matplotlib-devel.
>
> Eric
>
>>
>> Christoph
>>
The master branch builds OK on Windows and so far almost everything 
worked well.
I have trouble receiving the sample_data from github via cbook.py. There 
are frequent HTTP 304 (Not Modified) and 500 (Internal Server Error) 
exceptions and redirection to 
<https://raw.github.com/matplotlib/sample_data/master>.
Christoph

On 09/17/2011 12:17 PM, Christoph Gohlke wrote:
>
>
> On 9/17/2011 2:08 PM, Benjamin Root wrote:
>> I think it will take a declaration of a firm deadline. How about this?
>>
>> Cut RC release Friday, Sept 23rd
>> Release v1.1.0 Friday, Sept. 30th.
>> (Barring any major significant changes)
>>
>> In particular, for the RC, I want to make sure that installation and
>> documents for the installation is solid. I will have on hand an older,
>> stock Macbook Pro with Snow Leopard and a relatively new iMac with Snow
>> Leopard (one is 32 bits while the other is 64, I think).
>>
>> As a side note, the macbook can be used for automated build/test machine
>> as it really isn't useful for anything else for me.
>>
>> Ben Root
>>
>
> That sounds to me as if the master branch is at release quality, or very
> close to. I could test it on Windows this weekend if that's true.
Christoph,
It should be close. There are still three test failures, which I noted 
in a separate message to matplotlib-devel.
Eric
>
> Christoph
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I tried running the nosetests, and got failures. I put in a pull 
request to take care of one source, but three remain:
symlog2 svg
image_interp pdf
tight_layout5 svg
I have only looked into the last of these, which has nothing to do 
directly with tight_layout; on my system, the svg file is being 
generated with interpolation, even though the call to imshow has 
interpolation="none". I don't know what is going on. When I simply 
make an image with that kwarg and save to svg, it's fine. But it is not 
working that way in the test.
Eric

On Sat, Sep 17, 2011 at 7:01 PM, Benjamin Root <ben...@ou...> wrote:
> Agreed. Let's declare a feature freeze at this point. Unless you already
> have a pull, no new features, and even those with existing pulls need to be
> carefully considered. I already have to make some updates to the "what's
> new" section...
While you are working on 'what's new" could you consider adding a
section on the new sankey module and maybe inline one example from the
api/sankey_demo.py? I think they are pretty snazzy.
https://github.com/matplotlib/matplotlib/pull/465
JDH