[Numpy-discussion] More complex data types

[Charles R Harris]

On 10/5/07, Neal Becker <ndbecker2 at gmail.com> wrote:
>
> Charles R Harris wrote:
>
> > On 10/5/07, Neal Becker <ndbecker2 at gmail.com> wrote:
> >>
> >> Charles R Harris wrote:
> >>
> >> > On 10/5/07, Neal Becker <ndbecker2 at gmail.com> wrote:
> >> >>
> >> >> I'm thinking (again) about using numpy for signal processing
> >> >> applications. One issue is that there are more data types that are
> >> >> commonly used in signal processing that are not available in numpy
> (or
> >> >> python). Specifically, it is frequently required to convert floating
> >> >> point
> >> >> algorithms into integer algorithms.  numpy is fine for arrays of
> >> integers
> >> >> (of various sizes), but it is also very useful to have arrays of
> >> >> complex<integers>.  While numpy has complex<double,float>, it
> doesn't
> >> >> have
> >> >> complex<int,int_64...>  Has anyone thought about this?
> >> >
> >> >
> >> > A bit. Multiplication begins to be a problem, though. Would you also
> >> want
> >> > fixed point multiplication with scaling, a la PPC with altivec? What
> >> about
> >> > division? So on and so forth. I think something like this would best
> be
> >> > implemented in a specialized signal processing package but I am not
> >> > sure of the best way to do it.
> >> >
> >>
> >> I'd keep things as simple as possible.  No fixed point/scaling.  It's
> >> simple
> >> enough to explictly rescale things as you wish.
> >>
> >> That is (using c++ syntax):
> >> complex<int> a, b;
> >> complex<int> c = a * b;
> >> complex<int> d = d >> 4;
> >>
> >> Complicating life is interoperability (conversion) of types.
> >>
> >> I've used this concept for some years with c++/python - but not with
> >> numpy.
> >> It's pretty trivial to make a complex<int> type as a C extension to
> >> python.
> >> Adding this to numpy would be really useful.
> >
> >
> > How about fiddling with floating point to emulate integers by
> subclassing
> > ndarray? That wouldn't buy you the speed and size advantage of true
> fixed
> > point but would make a flexible emulator. Which raises the question,
> what
> > are your main goals in using such a data type? Not that I don't see the
> > natural utility of having complex integer numbers (Gaussian integers),
> but
> > if you are trying to emulate hardware something more flexible might be
> > appropriate.
> >
> > Chuck
>
> Yes, this is intended for modelling hardware.  I don't know what you mean
> by "more flexible".  I design my hardware algorithms to use integer
> arithmetic.  What did you have in mind?


Well, you could do bounds and overflow checking, use mixed integer
precisions, and also deal with oddball sizes, such as 12 bits. You might
also support 16 bit floats, something that is not available as a native type
on most platforms. I'm just tossing some ideas out there. As I say, I don't
see any reason not to have integer complex arrays, if only for the data
type. Then again, maybe you could define your own data type and just
overload the operators, something like

In [5]: complex32 = dtype('int16,int16')

In [6]: zeros(2, dtype=complex32)
Out[6]:
array([(0, 0), (0, 0)],
      dtype=[('f0', '<i2'), ('f1', '<i2')])

I suspect that the tools you want for emulation and debugging  would be hard
to get with exact replication.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20071005/4032b951/attachment.html>