matplotlib-devel Mailing List for matplotlib

Tony S Yu wrote:
> I was using pcolor with very large numbers and a small vrange (vmax - 
> vmin), and ran into a float to integer conversion problem. Large numbers 
> get converted to *negative* integers by astype (see numpy thread 
> <http://projects.scipy.org/pipermail/numpy-discussion/2008-October/038159.html>) in 
> colors.Colormap.__call__.
> 
> I'm not sure if this is even worth fixing since almost no one would run 
> into this problem (unless you were doing something stupid, like trying 
> to use pcolor as a 2D zero finder :). For the error to occur, you have 
> to set vmin/vmax values (otherwise, the data is properly normalized 
> before converting to integers), and your data has to greatly exceed 
> these limits.
Tony,
Thank you.
I committed the change; it looks like the cost of the extra clip is 
negligible, and it is nice to make the behavior correct even under 
extreme conditions.
Eric
> 
> Cheers,
> -Tony
> 
> 
> ------------------------------------------------------------------------
> 
> 
> Example of the problem:
> #~~~~~~~~~~~~~
> import matplotlib.pyplot as plt
> import numpy as np
> 
> cmap = plt.cm.gray
> cmap.set_over('r', 1.0)
> cmap.set_under('g', 1.0)
> cmap.set_bad('b', 1.0)
> 
> eps = 1E-8
> 
> A = np.arange(100).reshape(10, 10)
> plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
> # the plot should be about half red and half green (plus a black square)
> # without patch, some of the red squares are filled green
> plt.show()
> #~~~~~~~~~~~~~
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Manuel Metz wrote:
> Please see the end of the mail for the important point !!!
Thank you--I see you are way ahead of me on this. See comments below.
> 
> Eric Firing wrote:
>> Manuel,
>>
>> Although it doesn't hurt, I don't think it is worthwhile changing range 
>> to xrange. From the 2.5 docs:
> [...snip...]
>> Note "minimal" advantage. xrange was intended for special-case use, not 
>> general use.
> 
> Eric,
> 
> yes, I absolutely agree with you that this is only a small (minimal)
> advantage, probably not worth to worry about. Nevertheless ...
> 
>> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
>> xrange() renamed to range(), so range() will no longer produce a list 
>> but an iterable yielding integers when iterated over.
> 
> Python 3.0 will use xrange() by default, but it is then named range(),
> so from that _I_ conclude that xrange() should be used by default. You
> can also see the difference by using 2to3:
> 
> """
> for i in range(10): print i
> for i in xrange(10): print i
> """
> 
> gets converted to:
> 
> """
> for i in range(10): print i
> for i in range(10): print i
> """
> 
> That is, because 2to3 is a clever program. But:
> 
> """
> a = range(10)
> b = xrange(10)
> for i in a: print i
> for i in b: print i
> """
> 
> gets converted to
> 
> """
> a = list(range(10))
> b = range(10)
> for i in a: print(i)
> for i in b: print(i)
> """
> 
> ;-)
> 
> As you said, it's only a minimal advantage and 2to3 is a clever code!!!
> 
I am glad you brought the above to my attention--it completely changes 
my point of view. It does appear that changing to xrange now, whenever 
it will work (that is, when one does not *need* a list) will make the 
transition to Python 3 more efficient and has no disadvantage with 
present code.
> 
> (THE IMPORTANT POINT)
> 
> But this brings me to another, more important point: In the axes hist()
> method, a keyword named "range" is used that is passed to the numpy
> histogram() function, which has the kwarg 'range'. Now, this is not a
> problem as long as the range() builtin function is not used in the
> hist() method. But there are a few loops in this method that use
> xrange(), so this code will be translated to range() in py3 -- and that
> will be a problem. A basic example with a pseudo-code:
> 
> """
> def foo(x, range=(1,10)):
> print range
> for i in xrange(x): print i
> foo(10)
> """
> 
> with 2to3 -->
> 
> """
> def foo(x, range=(1,10)):
> print(range)
> for i in range(x): print(i)
> foo(10)
> """
> which then fails.
> 
> One solution would be to use a different keyword argument, maybe
> "binrange" instead of "range" and to throw a deprecated warning for the
> old keyword ???
> 
Yes, I think the use of any builtin as a kwarg is a bug that should be 
squashed via a new kwarg with a deprecation. Similarly, use of any 
builtin as in internal variable should be considered a latent bug and fixed.
Unfortunately, in this case, the badly-named kwarg is in numpy.histogram 
as well. The best thing would be to try to get the same change made in 
numpy so that mpl hist and numpy.histogram kwargs would stay in sync.
To make matters worse, histogram has evolved in such a way that its 
kwargs are a confusing mess. It is too bad that when the "new" syntax 
was developed, the "range" kwarg was not changed at the same time. I 
don't know whether any more changes would be accepted now.
If there is to be a new kwarg, I think I would call it "cliprange", 
since it is essentially used to clip the input--unless "new" is not 
True. It is not really a "bin range", because it can be set 
independently of the bins. (I have not traced the code; I am basing my 
statement on the docstring, so I could be wrong about what the code 
actually does.)
Eric
> Manuel
> 
>> This implies to me that range is the preferred form, and xrange is 
>> intended to go away.
>>
>> Eric
>>
> [...snip...]
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Sorry, I attached the wrong file:
On Oct 18, 2008, at 11:23 AM, Tony S Yu wrote:
> I was using pcolor with very large numbers and a small vrange (vmax 
> - vmin), and ran into a float to integer conversion problem. Large 
> numbers get converted to *negative* integers by astype (see numpy 
> thread) in colors.Colormap.__call__.
>
> I'm not sure if this is even worth fixing since almost no one would 
> run into this problem (unless you were doing something stupid, like 
> trying to use pcolor as a 2D zero finder :). For the error to occur, 
> you have to set vmin/vmax values (otherwise, the data is properly 
> normalized before converting to integers), and your data has to 
> greatly exceed these limits.
>
> Cheers,
> -Tony
> <clip_vs_putmask.py>
>
> Example of the problem:
> #~~~~~~~~~~~~~
> import matplotlib.pyplot as plt
> import numpy as np
>
> cmap = plt.cm.gray
> cmap.set_over('r', 1.0)
> cmap.set_under('g', 1.0)
> cmap.set_bad('b', 1.0)
>
> eps = 1E-8
>
> A = np.arange(100).reshape(10, 10)
> plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
> # the plot should be about half red and half green (plus a black 
> square)
> # without patch, some of the red squares are filled green
> plt.show()
> #~~~~~~~~~~~~~
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win 
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in 
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I was using pcolor with very large numbers and a small vrange (vmax - 
vmin), and ran into a float to integer conversion problem. Large 
numbers get converted to *negative* integers by astype (see numpy 
thread) in colors.Colormap.__call__.
I'm not sure if this is even worth fixing since almost no one would 
run into this problem (unless you were doing something stupid, like 
trying to use pcolor as a 2D zero finder :). For the error to occur, 
you have to set vmin/vmax values (otherwise, the data is properly 
normalized before converting to integers), and your data has to 
greatly exceed these limits.
Cheers,
-Tony
Example of the problem:
#~~~~~~~~~~~~~
import matplotlib.pyplot as plt
import numpy as np
cmap = plt.cm.gray
cmap.set_over('r', 1.0)
cmap.set_under('g', 1.0)
cmap.set_bad('b', 1.0)
eps = 1E-8
A = np.arange(100).reshape(10, 10)
plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)
# the plot should be about half red and half green (plus a black square)
# without patch, some of the red squares are filled green
plt.show()
#~~~~~~~~~~~~~

With a clear checkout building the docs fails:
[...]
Sphinx v0.4.2, building html
trying to load pickled env... not found
building [html]: targets for 348 source files that are out of date
updating environment: 348 added, 0 changed, 0 removed
reading... api/afm_api api/artist_api Exception occurred:
 File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
 fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'../mpl_examples/pylab_examples/findobj_demo.py'
The full traceback has been saved in /tmp/sphinx-err-X12gbJ.log, if you
want to report the issue to the author.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Send reports to sph...@go.... Thanks!
Building HTML failed.

Please see the end of the mail for the important point !!!
Eric Firing wrote:
> Manuel,
> 
> Although it doesn't hurt, I don't think it is worthwhile changing range 
> to xrange. From the 2.5 docs:
[...snip...]
> Note "minimal" advantage. xrange was intended for special-case use, not 
> general use.
Eric,
yes, I absolutely agree with you that this is only a small (minimal)
advantage, probably not worth to worry about. Nevertheless ...
> And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
> xrange() renamed to range(), so range() will no longer produce a list 
> but an iterable yielding integers when iterated over.
Python 3.0 will use xrange() by default, but it is then named range(),
so from that _I_ conclude that xrange() should be used by default. You
can also see the difference by using 2to3:
"""
for i in range(10): print i
for i in xrange(10): print i
"""
gets converted to:
"""
for i in range(10): print i
for i in range(10): print i
"""
That is, because 2to3 is a clever program. But:
"""
a = range(10)
b = xrange(10)
for i in a: print i
for i in b: print i
"""
gets converted to
"""
a = list(range(10))
b = range(10)
for i in a: print(i)
for i in b: print(i)
"""
;-)
As you said, it's only a minimal advantage and 2to3 is a clever code!!!
(THE IMPORTANT POINT)
But this brings me to another, more important point: In the axes hist()
method, a keyword named "range" is used that is passed to the numpy
histogram() function, which has the kwarg 'range'. Now, this is not a
problem as long as the range() builtin function is not used in the
hist() method. But there are a few loops in this method that use
xrange(), so this code will be translated to range() in py3 -- and that
will be a problem. A basic example with a pseudo-code:
"""
def foo(x, range=(1,10)):
 print range
 for i in xrange(x): print i
foo(10)
"""
with 2to3 -->
"""
def foo(x, range=(1,10)):
 print(range)
 for i in range(x): print(i)
foo(10)
"""
which then fails.
One solution would be to use a different keyword argument, maybe
"binrange" instead of "range" and to throw a deprecated warning for the
old keyword ???
Manuel
> This implies to me that range is the preferred form, and xrange is 
> intended to go away.
> 
> Eric
> 
[...snip...]