Marcel Hendrix wrote:
> Krishna Myneni <krishnamyneni@[EMAIL PROTECTED]
> wrote Re: FSL auxiliary
files: proposed reorganization of words
> [..]
>> How about the following specification for the result of invoking the
>> array/matrix name?
>
>> a{{ ( -- addr )
>
>> Return the address to the first array element for statically-defined
>> arrays/matrices and for dynamic arrays/matrices which have been
allocated. For
>> dynamic arrays/matrices which have not been allocated, the value of
addr is
>> ambiguous.
>
> This can not work. How does the program know the difference between a
> "valid address" and "an ambiguous" one? You don't want to test addr
> for a special value every time, and a{{ at time1 might be ambiguous
> while at time2 it has suddenly become valid.
>
The specification is not suggesting a debug mechanism; it is merely
do***enting
the fact that addr is not necessarily a valid address for the case of a
dynamically declared array whose data space has not been allocated. It is
the
programmer's responsibility to ensure that he/she doesn't attempt to use a
dynamic array prior to allocation. This is why the FSL provides "&" to
reference
the array for allocation (via }malloc etc.). Of course, one might simply
declare
an ambiguous condition in the case of an unallocated array, and then one
would
be free to implement some type of user warning.
> [..]
>> The header block of a matrix could include a flag to indicate whether
the data
>> was stored in row or column order. It might be best not to rule out
such
>> flexibility, since one may want to make their matrix data compatible
with either
>> Fortran or C conventions.
>
> How do you find the header block? Putting it at some offset before the
addr
> is again not possible (at times you will want to treat a row or column
of
> an existing matrix as a tem****ary array, preferably without copying).
>
In the current fsl-util.x implementations, the header block is typically a
contiguous space preceding the data area. If the header block structure is
allowed to be implementation dependent, then provide an API function which
returns the start of the header block. Of course, then, all elements in
the
header block would need API functions in order to set or get their values.
This
is the type of complexity I wished to avoid. But there appear to be a
greater
number of proponents for the idea of leaving the header block to be
defined in
implementation, rather than as a specification.
> My suggestion a{{ ( -- id ) \ unspecified ID
> is designed so that an implementation can use id to be the address of an
header.
> In this header an unspecified amount of descriptive data can be put
(rows, cols,
> data size, address of data, ... )
>
Yes, that's one advantage of leaving the header block to be implementation
dependent. One can put whatever information into it that one wants.
However,
****table library modules using such arrays must use commonly agreed-to API
functions only.
>> Therefore, I don't see a problem with
clearly
>> defining the contents of the header block for arrays and matrices, as
well as
>> with defining the behavior of array names.
>
> It is not wise to specify the contents of the header block, because this
> limits implementations unnecessary. If you want access to some
array/matrix
> parameter, specify an interface method like a{{ CDIM ( id -- #cols )
etc.
>
> -marcel
>
So sayeth the many.
Krishna
|
