Questions for PS Data Structures (SDR Section 3.1)

[calvin.harman@…]

Below are questions about the coding of the data structure types for psLib and
requests for changes in the documentation and coding implementation.

• Can we add a "psElemSize" variable to the psType struct? It would be useful

in automating size checking of each of the container types. (i.e. having to
specifically code "sizeof(float)", "sizeOf(int)", etc.)

• The psDimen enum does not have entries for array, hash table, and linked

list types. Should they be added? The PS hash tables and linked list structs do
not have psType elements, but the array struct does.

• The psDimen enum has a PS_DIMEN_VECTOR type, but I can't find its definition

in the SDR (although it is referenced several times in the matrix operations
section). Should it be defined as GSL vector, psFloatArray, or something else?
If is a psFloatArray, should we change the psDimen PS_DIMEN_VECTOR to
PS_DIMEN_ARRAY?

• The psDimen enum has a PS_DIMEN_TRANSV type. This seems a little too

specific, since it is still a PS_DIMEN_VECTOR. I'd recommend removing this,
otherwise we should add entries for other transposed types, like matrix, array,
and image.

• The psDimen enum has a PS_DIMEN_MATRIX type, but I can't find the psMatrix

definition in the SDR (although it is referenced several times in the matrix
operations section) Should it be defined as GSL matrix, psImage, or something
else?

• The psDimen enum has a PS_DIMEN_OTHER type. Having this opens the door for

users to put anything into a psType, which could be dangerous. I'd recommend
removing it.

• The psElemType has several types which are not used in the array collection

such as chat, short, uchar, etc. Should they be listed if they're not being
used in array operations?

• The psElemType enum has a PS_TYPE_OTHER type. Having this opens the door for

users to put anything into a psType, which could be dangerous. I'd recommend
removing it.

• The psElemType enum doesn't have a PS_TYPE_VOID type. This could be used for

void * primitives and arrays.

• Section 4.8 of the SDR defines the psImage struct. This struct uses

primitive types like psF32, psS8, etc. This seems to conflict with the
definitions in the psElemType enumeration. Shouldn't we use the same names and
types everywhere?

[Paul Price]

Element size in psType:
The type field was intended for this purpose, but if you have a convincing
argument, please make it known.

psDimen and array, hash table, linked lists:
We do not expect to perform arithmetic upon hash tables or linked lists; hence
these did not include a type.

PS_DIMEN_VECTOR:
Yes, it was intended that this is employed for psXyzArray, where Xyz isone of
the numeric types (int, float, double, complex float etc). I would prefer not
to change the name to PS_DIMEN_ARRAY, since a vector has an arithmetic meaning,
while an array is simply a collection of numbers.

PS_DIMEN_TRANSV vs PS_DIMEN_VECTOR:
The intent here was that we need to be able to distinguish a 1xN matrix(vector)
from a Nx1 matrix (transposed vector). For example, when adding a matrix and a
vector, the vector elements are added to the ntries in each of the *columns* of
the matrix, whereas when adding a matrix and a transposed vector, the vectors
elements are added to the entries in each of the *rows* of the matrix. There
should be no need to add types for transposed matrices, since they are simply
matrices. (See p34 of the SDRS.)

PS_DIMEN_MATRIX:
PS_DIMEN_MATRIX changed to PS_DIMEN_IMAGE in the SDRS.

PS_DIMEN_OTHER:
The reason for this was to prevent arithmetic operations upon arrays of types
that aren't numeric. We expect that anything that has a PS_DIMEN_OTHER type
will produce an error upon arithmetic operations.

psElemType and char, short, uchar etc:
Agreed at this morning's meeting that there wasn't a need for these.

PS_TYPE_VOID:
It's not clear how primatives would be used in the array operations, so I don't
think there's a need to add this.

psF32, psS8 etc in psImage:
I agree wholeheartedly --- changed in the SDRS.

[Paul Price]

Closed following this morning's meeting.