[PYTHON MATRIX-SIG] A ramble on ofunc's and omath

[Jim Fulton, U.S. Geological Survey]

Hm.  This made be reread:

> > a. It seems like if I don't do the import of omath then 2.*x doesn't
> > work. After a from omath import * it does. (?)
> This is true.  You have to import omath somehow, or matrices do not have
> any numeric behavior (notice that if you use import Matrix, or from Matrix
> import *. this gets done for you).  Here are the reasons...

Let me guess: x is an object returned from a module other than the matrix
module that creates matrix objects, right?  In the above example, Matrix has
not been imported yet?

Then the initialization code for Matrix causes the ofunc stuff to get wired
into the matrix type?

I'm more and more inclined to think that extension types (types not
built into the language) should always be hosted and exported by an
extension module and accessed from other modules via the import
mechanism.  If this were the case, then any extension module that
created matrices would have to import the Matrix module to get access
to a matrix constructor.  The Matrix module would then import other
needed modules, like omath. (See additional comment below.)

I intend to rewrite FIDL so that modules that it creates import Matrix and use
PyObject_GetAttrString to obtain matrix constructors.  So if you get a
matrix from a FIDL-generated module, Matrix and therefore omath, will
have been imported and matrices will have numeric behavior.

On Dec 14,  1:43pm, James Hugunin wrote:
> Subject: [PYTHON MATRIX-SIG] A ramble on ofunc's and omath
>
> This relates to both Konrad's and Jim's recent posts.  Also, this is a bit
> of a rambling set of comments rather than a coherent argument.  I just want
> people to understand where this weird ofunc thing came from, and what it
> does now.
>
> 1) What is an Optimized FUNCtion?
>
> An ofunc is a python object that contains C code to execute a function on
> arrays of raw C numbers (or on raw python objects, but that's another story)
> at close to compiled speed.  Each function takes an arbitrary number of
> arguments of given types, and produces an arbitrary number of results of
> given types.  For every desired combination of types that the function
> should operate on, there is another bit of C code to do the actual
> computation.
>
>
> 2) Why not bundle it into the matrix object?
>
> For one thing, I'd like to eventually clean things up and document them
> well enough that anybody can create an ofunc.  They're really useful little
> critters for doing very fast computations on arrays of numbers.
>
> Also, there are things like generalized reductions that need to have
> something to grab onto as the function to reduce over.  Without ofuncs as
> real python objects, I don't have any good way to express something like:
>
> add.reduce(m)
> (equivalent to but much faster than reduce(lambda x, y: x+y, m) ).
>
> There are also many of these creatures that don't really belong with the
> matrixobject, but which should behave in exactly the same way as "built-in"
> functions like add.  These include things like hypot.
>
>
> 3) Why the current weird dependency on import omath?
>
> I wanted to have a module which defined add and subtract as ofuncs so that
> they could be used in things like add.reduce.
>
> I also wanted to be able to play with different implementations of the
> ofuncs for different purposes.  For example, it should be possible to do the
> usual numeric tricks of special casing the currently very general inner
> loops to gain speed improvements.  Using the current setup, this can be done
> by creating a new module, and using the ofuncs for things like add and
> subtract defined in this new module in the matrix object.
>
> Also, I noticed that the matrix object was quite useful without any math
> functions at all, and I thought that it was a nice coincidence that this
> arrangement made it possible to have a "stripped-down" matrixobject with no
> numerical capabilites if you so desired.

But you now have a weird interface to the matrix module.  Assuming
that on most systems, the matrix module will be dynamically linked
anyway, I wouldn't worry about size.  Just let the matrix module
import omath so that the user who doesn't need omath can still use
matrix math without having to be aware of your implementation decision
to use omath.

Jim

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

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