Marcel Hendrix mhx@[EMAIL PROTECTED]
wrote:
> "C. G. Montgomery" <cgm@[EMAIL PROTECTED]
> writes Re: FSL auxiliary
> files: proposed reorganization of words
> (...)
>> 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.)
>
> There must be one, because I remember a discussion about it with Skip
> long ago.
Thanks, I'll go look for it one of these days.
> (...)
> Having 0-indexing but Fortran order would negate any possible benefit of
> the flexibility, so I would vote to remove the flexibility.
I don't understand this at all. If I want to pass the address of a
Fortran-ordered array to some foreign routine, the fact that Forth treats
it as 0-indexed makes no difference. Storage order and index conventions
are orthogonal.
> Again, the
> FSL already is using C-style ordering (never can remember if this is
> called row-major or column-major) already.
My personal fsl-util file stores matrices in the Fortran order, and at
least most of the FSL routines work perfectly. That's why I thought that
none of the Library cared. ;-)
>> 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.
>
> Note that when d{ leaves an id, it is not necessary to have & because
> }malloc and }free can be made to work with the id . Likewise, a{ b{
> }own would be a readily understood equivalent to a{ & b{ &! .
Exactly. & might well be a noop, which would be removed by optimization
(by machine or by hand). But it would break a lot of current code to
remove the word. And your }own would be a new word in place of &! ,
with a new syntax, so there's not much gain there.
As much as possible, what I would like to see is a set of specifications
which are consistent with the most common implementation (i.e., the one
in the current fsl-util auxiliary files) but less rigid, to allow (even
encourage) alternatives.
cheers cgm
|
