There are a lot of issues here.
On Fri, 31 Jul 2015, Michael Ferguson wrote:
> I've found it useful to allow some Chapel arrays to be read without
> knowing their size in advance. In particular, non-strided 1-D Chapel
> arrays that have sole ownership over their domain could be read into
> where that operation will resize the array to match the data read. I've
> prototyped this for JSON and Chapel style textual array formats
?
> (e.g. [1,2,3,4] ).
>
> E.g.
> var A:[1..0] int;
... revisiting history here.
This look like what Algol68 called flexible array bounds. Note that I was
not programming when Algol68 was released!! I do remember reading stuff
about the issues when I was using this in the early 80s. Because it was so
long ago that I do not have references, but unlike when I was younger, we
now have access to Google. So fishing for
algol68 flexible array
Not that it says anything negative
http://www.cs.virginia.edu/~mpw7t/cs655/pos2.html
There are books by the guy who coined the term 'Software Engineering',
Friedrich L Bauer. He was one of the original Algol68 architects who died
only about 4 months ago). Both discuss this topic. One of the books is
titled 'Compiler Construction: An Advanced Course', the other 'Algorithmic
Language and Program Development'.
>From memory, 'flex' bounds were regarded as a big no-no by many people,
even though those saying this agreed that there were lots of cases where
having them would be nice and make for much cleaner algorithms.
They were the basic mechanism behind Algol68's strings.
> mychannel.read(A);
>
> could read into A any number of elements and adjust its domain accordingly.
> The alternative is that such an operation is an error.
> So, I think that this kind of feature would be an improvement, but I'm not
> sure everyone will agree. To start the discussion, I have four design
> questions:
> 1) Does changing the size of a read array when possible seem like the
> right idea? Or should reading an array always insist that the input
> has the same size as the existing array (which I believe is behavior
> we are stuck with for arrays that share domains...)
I always prefer consistency. Not sure whether that is a very valid reason.
That said, and as Michael mentioned later, reading is a bit separate to
how something is stored.
> 2) Should any-dimensional rectangular arrays be written in binary in a
> form that encodes the size of each dimension? (In other words, write
> the domain first). Such a feature would make something like (1)
> possible for multi-dimensional arrays but might not match what people
> expect for binary array formats. (I don't think we've documented
> what you actually get when writing an array in binary yet...)
Remind me what the argument is against demanding that prior to reading the
array contents, the domain be read and then used to allocate the array?
> 3) Any suggestions for a Chapel array literal format for
> multi-dimensional arrays?How would you write such arrays in JSON (and
> would anyone want to)? At one point there was a proposal to put the
> domain in array literals, like this:
> var A = [ over {1..10} ];
>
> but that doesn't really answer how to write multidimensional array
> literals. One approach would be to store the array elements in a flat
> way and just reshape them while reading; e.g.
>
> var A = [ over {1..2, 1..3}
> 11, 12, 13,
> 21, 22, 23 ];
>
> where the spacing would not be significant.
Do you mean reshape (resize?) then after reading?
> If we had a reasonable format, we could extend support like (1) to
> any-dimensional arrays that do not share domains, even for some textual
> formats.
Not sure what you mean here.
> 4) I'm finding that each layout or distribution needs to be adjusted
> separately in order to implement these operations (they are currently
> implemented in dsiSerialReadWrite - part of the domain map (dmap)
> interface). But, it seems to me that how to read/write is reasonably
> independent of how the array is represented (as long as the I/O code
> can access the elements somehow). Is there a particular reason why
> these I/O operations are implemented on a per-dmap basis, rather than
> once for each type of array (rectangular, sparse, associative, etc)?
> I'd like the implementation approach to make it more likely that
> writing an array of a particular shape and then reading it with a
> different domain map will work. But, I might be confused about how it
> works now...
There are a lot of issues there, from design to implementation. They need
lots of thought. Are we confusing language features with the practicality
of I/O implementation? Just a thought.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
