[PD] Re: VASP, numarray etc..

[Thomas Grill]

Hi Ben,
i'm cc'ing to the list, since this might be interesting for others too

> I got a pixelTANGO bug report about the new "symbol" type in py. Seems
> symbols are no longer mapped to strings in python but remain some py
> type of "symbol" of course the normal string processing methods (not
> functions) don't work.
>

right, there's a Python type "Symbol" now, that encapsulates pd 
t_symbol pointers.

> So can I use str() to convert the symbol to a python string? Does py
> convert a string back to a symbol when PD gets it?

Yes and yes.

> Is there any
> documentation for py now? I seem even more confused with this latest
> release about types and available methods. (does the symbol type now
> have special symbol only methods?)

Not really, it can be compared to other symbols and cast to string (and 
in the cvs version also works as a normal immutable Python sequence.)


> I'm finding the included examples
> less than ideal for learning the API...

Hmmm, you're right. The thing is that i wanted to put out the current 
state so that i can work on new features.
I'm sure i'll find more time soon to work on a real tutorial.

>
> I think Miller would be better to add a "matrix" data type than an 
> image
> type, somehow to unify vasp, gridflow and iemmatrix so that they can 
> all
> pass (or at least convert) data to the different forms.
> Oh and what is the projection for the VASP rewrite?
>

I'm working on the vasp rewrite now - most of the functionality is 
covered by numarrays already.
As previously stated, vasp will be a Python module (mostly extending 
numarray functionality) that is used from within py/pyext.
py has been extended (in cvs) so that Python object pointers can be 
passed between several instances of py in the patcher, like [vasp( 
messages in the old version.
I'll give an overview of the new features as soon as the naming/syntax 
has stabilized.

Concerning PD arrays and matrices i already stated that i'm considering 
introducing a new type that is based on numarrays.
This seems convenient since numarrays can map to existing memory and 
therefore also be able to interact with Miller's data structures.
Numarrays are extremely flexible (multi-dimensional, all relevant 
types, also non-contiguous) and is seems very likely that they become 
the basis for a Python core array type.
The only basic problem that i see for now is the locking of the Python 
interpreter state, which could collide with realtime operations in PD. 
This is not a problem if Python is used only in single-threaded mode, 
but since scripting isn't too fast this seems like a drawback. Let's 
see if i can work around this.
For numarrays to be really efficient for audio and video application it 
will also be necessary to optimize the ufuncs which are at the moment 
implemented too straightforward (auto-generated) without SIMD or MMX... 
this is a target for the vasp project as well.

best greetings,
Thomas