[PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)

[Jim Fulton, U.S. Geological Survey]

On Jan 19, 11:39am, James Hugunin wrote:
> Subject: Re: [PYTHON MATRIX-SIG] Finalized 0.3 interface (hopefully)
>
>    From: "Jim Fulton, U.S. Geological Survey" <jfulton@usgs.gov>
>
>    > The two special data members "__array__", and "__return_constructor__"
>    > will be supported for python objects that want to pretend to be an
>    > array.
>
>    After thinking about this a bit, I'm quite comformable with the
>    __array__ member idea, because there is a precedent with __float__,
>    __int__, and __long__.  However, I have a *strong* opinion that
>    __array__ should be a member *function* that returns an instance as an
>    array.  This is in keeping with __float__, __long__, etc.  If a
>    user-defined type wants to store it's data in an array data member and
>    return the member, it can, but other user-defined classes may want to
>    compute and return array data on demand.
>
> This makes sense.
>
>    I would also recomment that the __array__ member function should have
>    an optional type code argument so that an extension that wants, say, a
>    double precision array can request one.
>
> I don't agree with this.  I really think that the __array__ member
> function should return whatever the internal array is used by the
> object, and let the extension convert it as it sees fit.

I don't feel too strongly about this second point, however,
I suspect that there could be many interesting classes that don't store their
data in arrays at all.  These will have to make some decision about what to
return and this could cause an extra array to be allocated.  Also, having these
conversion functions take a type argument is sort of symetric with the type
argument in the array constructor.

>
>    With an __array__ member function, I could, for example, immagine database
>    table objects that extracted their numeric data as an array on demand.
>    This could be quite useful.
>
> This sounds useful.
>
>    I'm not so comfortable with the __return_constructor__ idea.  It seems
>    to only make sense for single-argument functions.  I have an alternate
>    proposal.  Suppose that certain functions allowed an optional
>    (keyword?) argument that provided this constructor.  So, for example,
>    instead of:
>
>        bar=sin(foo)
>
>    where bar and foo are both Spams (e.g. Arrays) you would have:
>
>        bar=sin(foo,Spam)
>
>    Now, you don't want to have to type ",Spam" everytime, not because you
>    don't like typing, but because you don't want the clutter, so you
>    define a "sin" method in Spam:
>
>        def sin(self): return sin(self,self.class)
>
>    so then you could do:
>
>        bar=foo.sin()
>
>    I realize that this is not quite as pretty as the first version (or is
>    it?), but it feels cleaner overall to me.  In the case of
>    multi-parameter functions, it will be clear which object (the
>    reciever of the message) determines the return type.
>
> This is actually the version that I currently have running (more or
> less) it can infact be implemented entirely in python as a wrapper
> around the underlying math functions.  My principle problem with this
> approach is that it requires me to know about all of the available
> numeric functions and define equivalents for them whenever I define a
> new Spam.  This just seems unreasonable to me.
>
> For example, let's say I make a OneIndexArray (FORTRAN style indexes
> start at 1).  Obviously, I want this array to work with all of the
> existing operations on arrays, and to return a OneIndexArray back.
>
> I think that Jim F sees a problem with

Actually, I'm having more of a "gut" reaction.

>
> power(OneIndexArray, Matrix).
>
> I would simply have this function call raise an exception saying that
> it was called with arrays having different __return_constructor__'s.

I think I'd rather have this thing return an array in this case.  I guess I
think it would be better to make this explicit, like:

   OneIndexArray.power(Matrix)

or like:

   OneIndexArray(power(OneIndexArray, Matrix))


>
>    > One last question on installation:
>    >
>    > I plan to package this up as an addition to the standard python
>    > distribution, therefore, installation will consist of adding files to
>    > Modules, Lib, and Include.  Does this strike anybody as an
>    > unreasonable thing to do?
>
>    For now, it's OK, but the released version should be a stand-alone module.
>
> Maybe I'll let somebody else take care of these final packaging details.

Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================