Mysterious "ValueError: zero-size array..."

(Pierre GM: are you subscribed to this list? If so, sorry for cc-ing you.)

From: Friedrich Romstedt <friedrichromstedt@...287...>
Subject: Re: [Matplotlib-users] Mysterious "ValueError: zero-size array..."
To: "David Goldsmith" <d_l_goldsmith@...9...>
Date: Friday, March 5, 2010, 10:46 AM
I can reproduce the error with:

>>> argW = numpy.asarray([[0, 1, 2], [3, 4, 5],
[6, 7, 8], [9, 10, 11]])
>>> argW
array([[ 0, 1, 2],
[ 3, 4, 5],
[ 6, 7, 8],
[ 9, 10, 11]])
>>> argW[0:1, 0:0]
array(, shape=(1, 0), dtype=int32)
>>> d1.axes.imshow(argW[0:1, 0:0])
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File
"D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\axes.py",
line 5471, in imshow
im.autoscale_None()
File
"D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\cm.py",
line 148, in autoscale_None
self.norm.autoscale_None(self._A)
File
"D:\Programme\Programmierung\python-2.4.1\lib\site-packages\matplotlib\colors.py",
line 682, in autoscale_None
if self.vmin is None: self.vmin =
ma.minimum(A)
File
"D:\Programme\Programmierung\python-2.4.1\lib\site-packages\numpy\ma\core.py",
line 3042, in __call__
return self.reduce(a)
File
"D:\Programme\Programmierung\python-2.4.1\lib\site-packages\numpy\ma\core.py",
line 3057, in reduce
t = self.ufunc.reduce(target, **kargs)
ValueError: zero-size array to ufunc.reduce without
identity

So it seems to me that you pass in an array with shape <
4 in at least
one of the dimensions?

Thanks for your reply, Friedrich, and for creating the reproducing example!

I think it's a bug in numpy.ma._extrema_operations.reduce (at least Pierre GM couldn't explain it away and instructed me to file a bug ticket on it over there, which I did; w/ your permission, I'll add your code to that ticket?) - at the very least, it should be able to handle zero-size arrays more robustly (i.e., w/out raising an exception) IMO. Of course, that doesn't mean that once it's been fixed, imshow (or cm, which is apparently what's really calling it) won't encounter some other problem on account of the fix, but I guess we'll have to cross that bridge when we come to it?

NB: You lose at most 3 pixels at the border of your image
when drawing
it the method you proposed, because the int floor'ing will
cause that.

I was afraid of that (fancy index math has never been one of my strong suits) but ultimately I'm making ~5e3 x ~5e3 images (which is why I'm having to create the images that way in the first place - I was getting a memory error trying to imshow the whole full-resolution image w/ one call), so that loss is negligible (but if you can show me how to avoid it, I'd be much appreciative).

NB II: Something happened, you sent the last message four
times?

Yeah, my apologies, I'm not sure why that happened; maybe was having connectivity issues and wasn't sure if I'd sent it successfully? Anyway, sorry 'bout that. :frowning:

Thanks again!

DG

ยทยทยท

--- On Fri, 3/5/10, Friedrich Romstedt <friedrichromstedt@...287...> wrote:

Friedrich

2010/3/5 David Goldsmith <d_l_goldsmith@...9...>:

I think it's a bug in numpy.ma._extrema_operations.reduce (at least Pierre GM couldn't explain it away and instructed me to file a bug ticket on it over there, which I did; w/ your permission, I'll add your code to that ticket?) - at the very least, it should be able to handle zero-size arrays more robustly (i.e., w/out raising an exception) IMO. Of course, that doesn't mean that once it's been fixed, imshow (or cm, which is apparently what's really calling it) won't encounter some other problem on account of the fix, but I guess we'll have to cross that bridge when we come to it?

Hmm, IMO it's correct to raise because the minimum of nothing isn't
defined? Matplotlib tries to find a minimum. Anyway, you cannot draw
ndarrays arr with 0 in arr.shape. So I think matplotlib should maybe
silently skip attempting to draw it?

Friedrich