Implementation differences in psLookupTable

[Eric.VanAlst@…]

This bug is not against the documentation, but possible updates to the
documentation may be involved with the resolution. The implementation in
release 4 for psLookup table has the following differences:

Type psLookupTable data structure has additional elements numRows and numCols.

Two additional enumeration types psLookupStatusType which gives status of the
interpolation process and psLookupParseErrorType which gives status of the read
table process.

Function psLookupTableAlloc definition is different. SDR specifies a parameter
numValues to indicate the number of vectors for the allocation. The
implementation specifies two parameter not in the SDR: validTo and validFrom
which are used to initialize the members in the psLookTable structure.

Function psLookupTableInterpolate definition is different. The implementation
adds an additional parameter of type psLookupStatus which is updated based on
the results of the lookup. If the index specified is outside the table range
then the closest table entry(last or first) is returned and the status specifies
if return result is passed the top or bottom of the list. The SDR states the
function shall return NaN if the index is outside the table.

Function psLookupTableInterpolateAll definition is different. The
implementation adds an additional parameter of type psVector which is updated
based on the results of the lookup in each column of the table. It has similar
funcitonality as psLookupTableInterpolate in that it will return the closest
table entry in the vector. The SDR states the function shall return NULL if the
index is outside the table.

Should any of these changes be incorporated into the SDR or should the
implementation change to match the SDR?

[Paul Price]

The functions assume that the file containing the values have the types (e.g.,
"psF32") at the head of each column. The data file should not need to know the
types of the columns --- we are thinking of text files simply containing values.

But this identifies something that we hadn't thought of --- the function needs

to know the types. I have therefore reworked the function prototypes in the
SDRS to include a scanf-like format string to specify both the number of columns
and the types. I have also split psLookupTableRead into two functions,
psVectorsReadFromFile and psLookupTableImport, to make it flexible;
psLookupTableRead still remains, and should simply link the two pieces together.

Addressing specific differences you mentioned:

1. If adding numRows and numCols helps the coding, I don't think it's a problem.
2. I'm not in favour of psLookupStatusType and psLookupParseErrorType; these

aren't in line with the way we've been handling errors in psLib.

3. Reworked spec for psLookupTableAlloc
4. Same as 2.
5. The additional vector in psLookupTableInterpolateAll seems to hold status

values, so same answer as 2.

I would request that the functions be implemented as in the SDRS. The changes I
have made to the function definitions will require reorganisation of the current
implementation, but I think that all the pieces are there already. I had
originally been expecting that all the types would be psF64, and was surprised
to see that the current implementation provides more flexibility about the
types. I believe the changes I have made to the definitions in the SDRS keep
the strengths of the current implementation, while bringing it into line with
the psLib design philosophy.

I will attach pages from the new SDRS.

[Paul Price]

Revision of psLookupTable in the SDRS.

[Paul Price]

The bug on the documentation has been fixed. The implementation will shortly be
delivered, I think.