Thanks all for these enlightening answers. Indeed, thinking of filling an
array of size x by cyclically repeating elements from y, it's an odd
thought doing so with an empty y.
These were exactly the things I was missing, i.e. a historical perspective.
I don't see the need for changes really, I was just surprised. In case
needed, one can just as easily specify the fill directly if needed, (using
!., if known), or infer it from y's type using overtake: x ($ 1&{.) y .Jan-Pieter Op di 21 feb. 2023 om 15:48 schreef Henry Rich <[email protected]>: > Your view seems to be what Ken had in mind. > > On this view, (x $ y) and (x $!.f y) are two very different verbs: one > that uses only atoms of y and one that uses fill. > > If we allowed $ to have implied fill, we would be creating a chimera. > > Perhaps we could define $!.'' (i. e. any empty fill) to indicate that > the fill should be implied from the type of y. > > Henry Rich > > On 2/20/2023 1:49 PM, Paul Jackson wrote: > > I don't remember ever talking to Ken about this one, but I can tell you I > > was quite upset when APL 2 changed the rules for reshape. > > > > In my mind reshape would require special case handling to assume the need > > for knowing the data type of the empty. Reshape doesn't ever provide > > missing elements. It's sole task is to use the existing elements until > > something the size requested is provided. There is no amount of looping > > which can turn nothing into something, therefore I believe quite > properly a > > domain error. > > > > > > > > On Mon, Feb 20, 2023, 6:27 AM Jan-Pieter Jacobs < > [email protected]> > > wrote: > > > >> Looking through the implementation of dev/eformat, I found this line > which > >> puzzled me: > >> > >> > https://github.com/jsoftware/dev_eformat/blob/4c285152bb27c2bfcb474738ea3b839e4ce96d0d/eformat.ijs#L496 > >> > >> There's nothing wrong with that line, or with the fact it triggers an > >> error, but it does indicate that $ raises an error in a situation where > {. > >> does not, i.e. reshaping an empty array errors, while overtaking from > one > >> does not. > >> > >> Indeed, 5 $ '' or 5$ 0$0 give an error, while 5 {. '' and 5 {. 0$0 just > >> work, producing arrays of 5 spaces or zeros as expected. 5 $!.'' '' also > >> works, as does 5$!.1 ''. > >> Why wouldn't $ be able to see the data type (and thereby, fill element) > of > >> it's y argument, and fill accordingly? As far as I remember, any noun > in J > >> has a datatype, and a fill element. As the the fill element is a scalar, > >> the dimensionality being different in the case of $ shouldn't matter > >> either. > >> > >> Is there anything I'm missing, or is this really an inconsistency > without > >> any reason for existence? > >> > >> Best regards, > >> Jan-Pieter > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
