Re: Growable arrays

Re: Growable arrays

[Daniel Llorens]

> Message: 2
> Date: Thu, 14 Jun 2012 10:33:36 -0400
> From: Mark H Weaver <mhw@netris.org>
> 
> Although Scheme vectors should remain fixed-size for reasons I have
> given elsewhere in this thread, Guile also includes a more complex
> 'array' type that includes features such as arbitrary rank (i.e. number
> of dimensions), arbitrary lower bounds (not just 0), and shared views on
> the same underlying array with arbitrary affine mappings of indices.
> 
> Guile 'arrays' cannot currently be resized, but I see no good reason for
> this limitation.  They are already quite complex, and already require a
> second level of pointer indirection.
> 
> What do other people think?

I do not think this is a good idea. Guile arrays are just views of a vector. Are you proposing to have a separate array implementation? The resize operation clashes with the notion of shared views, and it only makes sense for arrays of rank 1. It can defined on the ravel (the old C++ library, Blitz++, has it) but I don't quite see how it would work in Scheme.

It's true that arrays are complex. They should be simpler. For example, I'd remove the arbitrary lower bound feature. Do people use it? I've never used it, and I use arrays all the time.

> From: David Kastrup <dak@gnu.org>

> Another complex type, this time with quite more serious memory and
> performance impact, that can't be implemented on top of a simple
> resizable common primitive and has an almost, but not quite, overlapping
> underlying feature set?
> 
> It's almost as if you _like_ not being able to reuse code.

…

> Hash tables.  Apparently vlists.  I am not convinced that this does not
> make sense for normal and uniform vectors as an option as well.

Currently Guile vectors can be viewed as arrays of rank 1. If vectors become resizable, I think that there has to be a way to protect shared arrays from the resize operation.

Re: Growable arrays

[David Kastrup]

Daniel Llorens <daniel.llorens@bluewin.ch> writes:

> I do not think this is a good idea. Guile arrays are just views of a
> vector. Are you proposing to have a separate array implementation? The
> resize operation clashes with the notion of shared views, and it only
> makes sense for arrays of rank 1. It can defined on the ravel (the old
> C++ library, Blitz++, has it) but I don't quite see how it would work
> in Scheme.
>
> It's true that arrays are complex. They should be simpler. For
> example, I'd remove the arbitrary lower bound feature. Do people use
> it? I've never used it, and I use arrays all the time.

If you take a look at "Numerical Recipes in C" (unless they got their
act together in a later edition), they just mapped the Fortran code 1:1
to C.  And I mean 1:1 and not 1:0.  They left the 0 index empty.  And
implemented arrays not as "a view" on a vector, but rather as as a
vector of independently allocated vectors.  Of course, all on the heap.

I should think that being able to interchange 0/1 based would be the
most important application.  Then you would want to have this feature
for translating Pascal programs (they are start index agnostic).
Indexes in math often run from 1, being able to translate into a
straightforward 1-based rendition can avoid transliteration errors.

It is definitely a higher-level feature and not a fundamental property
of underlying primitive data types, though.

-- 
David Kastrup

Re: Growable arrays

[Daniel Llorens]

> Date: Thu, 14 Jun 2012 21:35:48 +0200
> From: David Kastrup <dak@gnu.org>
> To: guile-devel@gnu.org
> Subject: Re: Growable arrays
> Message-ID: <87y5npu1nv.fsf@fencepost.gnu.org>


> I should think that being able to interchange 0/1 based would be the
> most important application.  Then you would want to have this feature
> for translating Pascal programs (they are start index agnostic).
> Indexes in math often run from 1, being able to translate into a
> straightforward 1-based rendition can avoid transliteration errors.

Yes, that's the only thing I've ever seen it used for. I don't think it's worth the cost. Translation only needs to be done once. 

Sure, the cost is small and to do anything fast with Guile arrays it's necessary to go down to C/C++ anyway. The wrapper checks the bounds and I can forget about it.

I just don't think of arrays as a complex data structure where it's ok to pile features at the foundations.