Re: [gtkdatabox] gtkdatabox-list Digest, Vol 39, Issue 16



Can I ask a question here:

Are you suggesting to "column-ize" it as matlab does (i.e., the (:) operator in matlab.)

That is: Create a single column vector from a multidimensional matrix (of any order), and then pass the index as a vector? You would need to know the element type (double complex, double float, single float, integer, byte, etc)

Example:

A(5,4) would be a matrix of 20=5*4 elements, or a vector of 20 elements, and an vector index of [5,4,64(double flt)] (a vector of 2 elements), of size 5 and 4, consisting of 64 bit IEEE floating point numbers)

If A(4,5,6) this is a single column vector having 4*5*6=30*4=120 elements, and a vector index of [4,5,6, 16(int)]. 120 16 single integers.

Maybe I'm missing the point here? If so, never mind ;0)

Jont

On 11/16/2012 02:59 PM, gtkdatabox-list-request gnome org wrote:
On 11/16/2012 01:36 PM, Amish S. Dave wrote:
>I've started implementing some changes in how GtkDatabox handles input
>data, along the lines of my earlier posting.  Would like some feedback
>on the interface, and on whether worthwhile or not.  It can be done in
>a completely backwards compatible way.
>
>GOALS:
>1. more flexible / robust data handling (handle non-float data,
>growing arrays, ring buffers, matrices where the data is a particular
>row or column).
>2. be backwards compatible with existing scheme
>3. minimize or eliminate data copying / memory allocations
>
>PROPOSAL:
>instead of passing a (gfloat *) pointer and a length:
>pass a (void *) pointer, a starting offset, a stride number, and the
>number (length) of samples to process, as well as the size of the
>allocated buffer, which may be less than the length when dealing with
>a ring buffer.
>
>The idea is to treat the data as coming from a matrix of
>floats/doubles/ints.  If gtkdatabox is told to go beyond the available
>number of rows of data, then wrap around to the beginning (i.e. treat
>as ring buffer).  In the simple case, the matrix has one column of
>floats, in which case it's just like what we have now.
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]