"Andrew Nikitin" <[EMAIL PROTECTED]> wrote:
> >The interpreter is working as specified. The result is not "intuitive" 
> >because in this case
> >atoms of the index array do not select subarrays that are the same
> >shape. -- RogerHui 2006-07-18 23:06:08
>
> Where exactly this is specified? Dictionary page for } does not mention 
> shape of subarrays.
>
> >Could somebody please explain me where asterisk in top left corner is 
> >coming
> >from?
> >    '*' ((<1;2 3),<0;7) } 2 9$'-'
> >*------*-
> >--**-----

As much as I happen to dislike this particular behavior due to its
counter-intuitiveness, and how it makes certain useful constructs
either buggy, or awkward to re-specify in a 'correct' manner,
Roger is correct in that it DOES behave as specified.

The dictionary states:
  If m is not a gerund, x m} y is formed by replacing by x those parts of y 
selected by m&{ .

So let us see just what parts of y ARE selected by m&{.
Using numbers rather than characters, to illuminate just what is happening:
   i. 2 9
0  1  2  3  4  5  6  7  8
9 10 11 12 13 14 15 16 17
   ((<1;2 3),<0;7) { i.2 9 NB. note the 0 in the result
11 12
 7  0
   42 ((<1;2 3),<0;7) } i.2 9
42  1  2  3  4  5  6 42  8
 9 10 42 42 13 14 15 16 17
And this DOES replace indices 11, 12, 7, and 0 with 42.

That being said, however, I believe that I can argue the
opposite point even more convincingly:

The spurious '0' is a result of an implied fill, and is not ACTUALLY
'a part of y selected by m&{' but rather something inserted
by the implicit rank conjunction. In particular, it IS a part of i.$y,
but it is NOT in general a part of y itself.

   101+i.2 9
101 102 103 104 105 106 107 108 109
110 111 112 113 114 115 116 117 118
   ((<1;2 3),<0;7) { 101+i.2 9
112 113
108   0

In this case, the 0 returned by { is not from any actual part of y,
so the corresponding amend would erroneously replace the 101,
something that m&{ would never actually select in the first place.

I have a question for Roger:
Do you know of any cases where the current implementation
provides a useful behavior that would be broken by an
implementation that many seem to think seems more intuitive?


"Devon McCormick" <[EMAIL PROTECTED]> wrote:
> So, putting in an unnecessary "7" does what was probably intended:
>    '*' ((1;2 3);<0;7 7) } 2 9$'-'
> -------*-
> --**-----
>
> It _is_ wierd.

Unfortunately, the interpreter does not specify any order of
operations, so if you used '*#' rather than '*' above, it is not
well-defined what character would appear on the first row.

In particular, does 'XY'(0;0)}'AB' produce 'XB', or does it produce 'YB'?
The current Windows implementation seems to produce 'YB', but the
dictionary does not guarantee this.

Using the same index multiple times in the same amend can
produce unpredictable results, unless you guarantee that the
same left parameter is supplied each time (which fortunately
happens to be the case in the example you gave, but which
cannot be relied upon in general, unless you arrange the
parameters carefully).

-- Mark D. Niemiec <[EMAIL PROTECTED]>




----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to