> Confusingly, the explicit call to nonzero() is not what is
> causing the numarray problem. The problem is an implicit
> call to NumArray.__nonzero__() resulting from the range
> expression. I found I could "fix" the numarray exception by
> adding parens to the range expression:
> nonzero((ticklocs >= 10.0**ymin) * (ticklocs <= 10.0**ymax))
I wasn't able to replicate your problem in ticklocs.py on my system
(could be a version issue?).
Reproducing the exception requires using numarray-0.9. Also,
ticklocs.py is coded to demonstrate the unexpected Numeric results
rather than the numarray exception to there is a try/except block which
passes the numarray exception on to parenthesized code.
Ie, the following works fine for me; I
assume it generated a RuntimeError for you based on your example code.
In any case, in general I try to avoid using multiplication for
logical arrays because it sometimes produces surprising results. I
think here we want
ind = nonzero(logical_and(ticklocs>=10.0**vmin ,
This is clearer and unambiguous.
> Lastly, assuming the parens are correct, there is still a
> problem with the log functions which I haven't looked at
Here's what's going on under the hood
You are using the single arg form of plot with log scaling for both
axes. The y values are arange(2,800) and the x values are implicit:
arange(len(y)). Since this starts with 0, when take the log of zero
in loglog, you are in a world of pain. The current version of
matplotlib warns but then tries to go ahead, which generates the
error. Specifically, it took the positive parts of x but left y
alone, resulting in the unequal sized array problem.
I changed the code to raise rather than warn. You now get the more
helpful error message
ValueError: Cannot take log of negative data
Makes sense. Thanks for the explanation.
Both changes in CVS.
On Mon, 2004-04-05 at 18:32, John Hunter wrote:
Todd Miller <jmiller@...31...>