Re: [matplotlib-devel] scipy core patch

[<da...@eg...>]

On Dec 2, 2005, at 3:43 PM, Eric Firing wrote:
> I don't understand the rationale for defining these functions, and in  
> particular the "resize" function that is causing problems.  It looks  
> to me like all three numeric packages include both resize functions  
> and resize methods, with the latter differing in that they work in  
> place and require contiguous arrays.  What your patch is doing is  
> removing access to the resize function, so there is no way to resize a  
> noncontiguous array.

I didn't realize such a function existed, and
was mostly following Travis' "list of necessary
changes" (in his book, Section 2.6.1). Of course
given that the right function exists from a top-
level import, that would be preferred over the
customization that I was doing.

I apologize if I gave the impression that the
patch was meant to be complete/correct/ideal.
It was mostly intended as a preliminary query
to see if there was any interest in pursuing
the specific backend numeric library approach,
since I had seen the discussion on a unified
build (which I didn't understand well enough
to implement.)

John Hunter wrote:
> A number of the symbols in numerix.mlab that Daishi originally defined
> were from various scipy (non-core) proper modules and I could not find
> these in the core.  Will scipy core not be providing the equivalent of
> MLab.py?

I did originally attempt to build vs. just
scipy_core, but failed for the same reason.
I was impatient to get things working for
my own purposes (scratching my own itch
and all that), so didn't put much effort
into pursuing this aspect further - but I
should have mentioned it in the original
message; sorry about that.

I'm happy to see that the patch was useful
enough to incorporate into the tree and
improved upon.

Eric Firing wrote:
> Here is another anomaly that I needed to work around:
>
> >>> bb = scipy.array([1.1,2,2,3.3])
> >>> 1.1 in bb
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: The truth value of an array with more than one element is  
> ambiguous. Use a.any() or a.all()
> >>> import numarray
> >>> nn = numarray.array([1.1,2.2,3.3])
> >>> 1.1 in nn
> True
>
> x in A behaves completely differently if A is a scipy ndarray than if  
> it is a numarray array.  This seems to me like a bug in scipy; the  
> num* behavior is certainly easier to use, in that it preserves the  
> list-like behavior when used in a list-like context.

I hit this also. Another behavioral difference
that pops up is:

---
In [3]: if scipy.arange(10) == None:
    ...:     pass
    ...:
------------------------------------------------------------------------ 
---
exceptions.ValueError                                Traceback (most  
recent call last)

/usr/local/python/python_2005-11-10/<ipython console>

ValueError: The truth value of an array with more than one element is  
ambiguous. Use a.any() or a.all()
In [4]:
---

versus:

---
In [7]: if Numeric.arange(10) == None:
    ...:     pass
    ...:
In [8]:
---

This was the reason for, e.g., this part of the patch:

Index: lib/matplotlib/contour.py
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/lib/matplotlib/contour.py,v
retrieving revision 1.16
diff -r1.16 contour.py
---
659c661
<         if linewidths == None:
---
 >         if linewidths is None:
---

(In this case I believe the new scipy approach
is less ambiguous and therefore better - the
intended semantics AFAICT in contour.py is for
'is', not '==' anyways.).

Thanks,
d