Empty vector assignment

Comments:

Author Thread:

Patrick.Parks

Empty vector assignment
Posted: Tuesday, August 22, 2006 9:18 PM (EST)

It is that way by design! The number of rows and columns of data that gets shoved into the grid is determined by the number of Rows and Cols specified as well as the number or rows and columns in the data argument itself. If you specify Rows/Cols arguments 2 3 and an array (10 10 reshape iota 100) for data you will get 10 rows and 10 columns block of data inserted starting at position 2 3 in grid. This is somewhat like scalar extension. If the Rows and Cols specify more rows/cols than there is data, then the data is replicated to fill the desired size. If there is more data than Rows and Cols then the data size extends past the last specified Rows Cols coordinates. When you specify iota 0 as an argument we just follow this pattern and extend beyond the end of the last data row/col which means we start as row/col 1 1. Hope that makes sense now.

davin.church

Empty vector assignment
Posted: Wednesday, August 23, 2006 10:28 PM (EST)

Well, that makes a certain amount of sense, but I don't like the way you've extended the behavior...

If giving a scalar row and column number and a matrix of data, it makes some sense to start the data at that point and fill down and over to the limit of the data. However, if I'm specifying a list of rows and/or columns, then I don't think that location-extension should apply. I would either expect the data to be truncated to the location/size that I've specified, or I should get the equivalent of a length error.

In addition, carrying that behavior further to apply to an empty vector makes even less sense, as you no longer even have a starting point from which to expand. Starting at [1;1] seems quite arbitrary and is very unlikely to be what the programmer intended anyway.

And to carry the analogy in another direction, specifying a "scalar" piece of data should (from an APL point of view) cause the data to assume the shape of the indices, not the other way around.

None of these behaviors is compatible with what I think that an APL programmer would expect to see. Perhaps we should reconsider how these special situations should be handled?