[PD] VASP future
gr at grrrr.org
Tue Mar 22 21:58:19 CET 2005
i'm thinking about the future of VASP these days since i'm myself using
it for compositional work.
Said this, it is not completely true though, since i'm using the
numarray extension of the py/pyext external (CVS version), which allows
to work with PD arrays in Python. I consider this the future of VASP
(namely to be a pure Python module), although it will perhaps be called
Realizing there are still a number of daily downloads although i haven't
touched VASP for quite a while now let's me ask you about your usage of
VASP. Do you use it for
- simple array math/transformation?
- medium complex things like analysis or synthesis?
- complex work like algorithmic composition and the likes?
- none of the above?
- something completely different?
Does it have to provide
- real-time response (like for interaction with DSP processing)?
- or not?
Do you predominantly use
- singular VASP objects?
- groups/whole subpatchers of interacting VASP objects?
I realized in my own work that it's very hard to express complex stuff
as PD graphs, and also VASP has the problem of needing to lock arrays
while working on them, which still isn't really implemented in PD (it is
in the devel branch, but the future of this isn't clear either).
The question is now whether i abandon the current PD object
implementation of VASP and focus on the Python one, or think about a
side-by-side solution of both systems, probably reducing the
functionality of the current VASP implementation a bit. There's still
time to decide since the Python array implementation hasn't been
Let me know what you think and if you care at all.
More information about the Pd-list