Hi,
> > This can lead to surprising bugs in code that either explicitly
> > expects it to behave like python's max() or implicitly expects that by
> > doing "from numpy import max".
my solution is to never use numpy.max. For arrays, I always use the method
call (somearray.max()). For everything
Hi,
in error logs as yours, always look for the first line which says "error". If
it is, like in your case, something like
On Sunday, 13. May 2007 19:21:15 dmitrey wrote:
> /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include/limits.h:122:61: error:
> limits.h: No such file or directory
you are missing
On Monday 19 February 2007 12:06, Sven Schreiber wrote:
> Zachary Pincus schrieb:
> > Hello all,
> >
> > It seems that the 'eigh' routine from numpy.linalg does not follow
> > the same convention as numpy.linalg.eig in terms of the order of the
> > returned eigenvalues. (And thus eigenvectors as we
Hi,
> current behaviour. That is, what "A+B" on a blackboard in a math class
> means maps nicely to what 'a+b' means with a and b being numpy arrays. But
> 'A=B' means something completely different than 'a==b'.
This mapping is dangerous, I think A+B and A-B might be the only cases where
it actu
Hi,
> The question is then:
> 1) Is there any way to change the axis for which the product-sum is
> performed. This can of course be done by a swapaxis before and after the
> operation, but this makes the array non-contiguous, in which case the
> dot operation often makes bugs (at least in Numeric
