Thanks Michael! I've needed this many times while doing Project Euler problems.
On Fri, Jul 31, 2015 at 7:37 AM, Michael Ferguson <[email protected]> wrote: > Hi - > > 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; > 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...) > > 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...) > > 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. > > 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. > > 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... > > Thanks for any thoughts, > > -michael > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers >
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
