Krishna Myneni krishnamyneni@[EMAIL PROTECTED]
wrote:
> Marcel Hendrix wrote:
>> "C. G. Montgomery" <cgm@[EMAIL PROTECTED]
> writes Re: FSL auxiliary
>> files: proposed reorganization of words
>> [..]
>>> If the result of invoking the name of an array has to be the same in
>>> all implementations, I think the only possibility would be that it
>>> returns the address of the first array element, but that could force
>>> inefficiency for some implementations.
>>
>> That is not possible for dynamically allocated arrays.
>>
>
> 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.
I think Marcel's proposal that the value returned is
implementation-defined is preferable, since it allows more freedom in the
implementation. It's also somewhat simpler if its ambiguity isn't
dependent on whether a dynamic array has been allocated or not.
> >> ... (Similarly, the layout of the data should IMHO be flexible --
> >> row-major order?, column-major order?, code space?, data space?,
> >> linked-list???)
> >
> > No, please! Rigidly specify row or column order, and rigidly specify
> > that indexes start at 0. The code/dataspace issue is hidden from the
> > programmer, but for DMATRIX and DARRAY it would be hard to defend an
> > implementation that uses code space. Linked-lists are forbidden, the
> > data should be in contiguous memory -- many algorithms use this fact,
> > and it is needed for external calls. It is indeed sometimes very
> > convenient to call Fortran in stead of C, but for my own work I have
> > managed to successfully hide these details from the Forth side of the
> > interface (iForth only ever sees C-style arrays, even when interfaced
> > to Matlab).
> >
>
> 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.
I don't recall any of the present Library algorithms depending on the
details of data storage. (If I'm wrong about that, I'd appreciate being
corrected.) I agree that it might be useful to have either Fortran or C
orders available somehow, and it has been demonstrated that this can be
done efficiently, but I would prefer that the Library algorithms don't
depend on any particular storage or require specifying it somehow. That
can be left to the fsl-util file, which is required by but not part of
the Library.
I quite agree that 0-indexing should be mandatory. That's definitely
current practice and consistent with other Forth usage.
> I agree that linked lists and other complex data ordering methods should
> be ruled out for the basic FSL arrays. My opinion is that array and
> matrix structure should be kept as simple as possible to meet *existing*
> and likely near-term requirements of the FSL. It is unwarranted to over
> design simple arrays and matrices, both for the reasons of efficiency,
> and simplicity of use. At one extreme, a highly generalized and
> customizable format for data storage can be designed, such as the
> astronomical community's FITS format. Then we would need a library
> module consisting of thousands of lines of codes just to create and use
> simple arrays. The other extreme is to specify an array/matrix as a
> contiguous block of data with no header information, which is too
> simplistic for most uses. What we have now in most of the fsl-util files
> is pretty close to the right level of complexity. 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.
With the exception of the last sentence, it's my agreement with this that
leads me to the preferences I have described. But I feel that specifying
the contents of a header block could constrain possible implementations
without providing any benefits great enough to compensate.
My thinking about these matters has led me to think that what is im****tant
to preserve is the effect of certain phrases, such as
nels elsize ARRAY a{ and elsize DARRAY a{ and a{ el# }
and corresponding phrases for 2-d arrays, but that the details of how this
happens in terms of the behavior of the components ARRAY and DARRAY
and a{ and } should be left as open as possible to allow flexibility
to implementors.
Similarly, the phrases involving & and &! that need to be specified
are
& d{ nels }malloc and & d{ }free and a{ & b{ &!
and their 2-d counterparts.
I think (but I'm not sure) that if those phrases work then all the current
Library routines will work correctly. What appeals to me is requiring
the behavior of such phrases without further specifying the details of
how the individual components behave. Sample implementations would of
course be available as "contributed files". (Devising tests for this
would be a nontrivial but feasible exercise, I think.) And of course I'm
only talking about guidelines for official FSL code.
I'd certainly welcome comments on
1) whether such a specification for phrases would be sufficient
2) if so, whether there are other phrases needed
cheers cgm
|
