Unintuitive rank behaviour of gerund"n

[Helen]

Hello!

I was writing some J (version 9.6) and I ran into some unexpected behaviour with the interaction between gerund"n and modifiers:

    (+`-"0) 1 1 NB. gives 1 _1

    <@(+`-"0) 1 1 NB. gives <"0] 1 1

I imagine that this happens because, whilst gerund"n is in all other aspects a verb of rank n, it has to operate on the whole array at once behind the scenes(?) in order to work as expected, and so it ends up with this unintuitive behaviour of being rank infinity, but only when you apply it directly.

I was thinking it might make sense to just make gerund"n have rank infinity? It matches how gerund/ and other phrases work, and also makes its behaviour with modifiers more intuitive.

A downside to this approach I can see is that if you genuinely wanted a verb of rank n (for whatever reason), you would need to write gerund"n"n, which looks rather silly.

I'm not sure if this is particularly interesting, but I thought it was worth bringing up.

Kind regards,

Helen

[Henry Rich]

Generally I agree with your analysis.

gerund"n does nothing 'behind the scenes'.  In <@(gerund"0) the
(gerund"0) was applied independently to each atom of the input. Notice
that the first verb of the gerund was used for each application.

You are right that gerund"n should have infinite rank.  I didn't think
about the modifier case when I implemented gerund"n, simply assuming it
would be n.  With the current definition gerund"n"n gives a different
result from gerund"n, which sucks.

However, I don't think changing it is urgent, because since u@(gerund"n)
is so broken, nobody can be using it.

If nobody comes up with a good counterargument, I will make the change
sometime before the next release.

Henry Rich

> To unsubscribe from this group and stop receiving emails from it, send
> an email to forum+un...@jsoftware.com.

[Elijah Stone]

> gerund"n"n

i didn't expect this to work (and wouldn't expect it to with the proposed
changes either), but it does--+`-"0"0]1 1 is 1 _1, where i would have expected
1 1. i think this is a bug. thoughts?

i think it could make sense for u@(v`w"n) to 'distribute over' the " and act
the same as (u@:v)`(u@:w)"n but that would be an incompatible change and i
think both results would be a bit confusing so i don't think it is worth
changing any way. i don't think u`v/ is a good thing to compare to because
_all_ u/ have rank infinity

[Henry Rich]

You are right - u"n ignores the "n if the ranks of u are <= n.   This
was done because so many beginners used +"0 routinely with big
performance loss.

With the current maldefinition of gerund"n that behavior is not
transparent (i. e gerund"n"(gerund"n) would be different I think), but
if we fix gerund"n to have infinite rank all will be well.

There was a time long ago when u@(v`w) did distribute to (u@v`(u@w)) but
it was never documented and eventually removed. Roger must have had
similar ideas.  I have often wanted (<@) or (&.>) to distribute over
gerunds, so I think we should keep the idea alive.  Maybe when we have a
gerund type?

I think u`v/ /is/ a good thing to compare to because it reminds us that
("n) is the simplest partitioning modifier.

Henry Rich

[Cameron Chandoke]

I may have some thoughts / suggestions to contribute, but before I weigh in with them, I'm still seeking to first be sure that I understand the more basic dynamics here.

> With the current definition gerund"n"n gives a different result from gerund"n, which sucks.

This is what I would've expected, too, as reasoned below. However, upon some testing, I'm surprised to find that they seem to in fact be the same...!

I would've thought that they would always differ, except when the argument(s) have only one n-cell. My reasoning is that (u`v)"n"n should apply the cyclic u`v"n independently to each n-cell (based on the outer application of "n to u`v"n), each of which gets partitioned vacuously again as a single n-cell (based on the inner application of "n to u`v), and therefore just u would be applied on every n-cell, with v applied to none. But strangely it seems that's not what happens. For example, below, I would've expected the |.`|:"2"2 to give the same result as |."2 , but it doesn't:    

   (|.`|:"2"2 ; |.`|:"2 ; |."2) i.3 3 3

┌────────┬────────┬────────┐
│ 6  7  8│ 6  7  8│ 6  7  8│
│ 3  4  5│ 3  4  5│ 3  4  5│
│ 0  1  2│ 0  1  2│ 0  1  2│
│        │        │        │
│ 9 12 15│ 9 12 15│15 16 17│
│10 13 16│10 13 16│12 13 14│
│11 14 17│11 14 17│ 9 10 11│
│        │        │        │
│24 25 26│24 25 26│24 25 26│
│21 22 23│21 22 23│21 22 23│
│18 19 20│18 19 20│18 19 20│
└────────┴────────┴────────┘

   NB. |: was still applied to middle cell in |.`|:"2"2 case

The following example demonstrates why I would've expected |.`|:"2"2 to be the same as |."2:

   (|."2   -:   [: |.`|:"2&> <"2) i.3 3 3
1

So perhaps somehow under the current implementation, u`v"n"n is always the same as u`v"n (for non-negative n)? I'm not sure how that's happening. Could this be a bug?  Or am I perhaps missing something? 

Regards,

Cameron

P.S. -- I'm assuming strictly non-negative rank n in our discussion, since for negative n, verb_or_noun"n"n already generally yields a different result from verb_or_noun"n , independent of whether verb_or_noun is a gerund.

[Cameron Chandoke]

Additionally, I see that u`v"n"_"n gives the result I had been expecting from u`v"n"n -- namely, that only u is applied to all the n-cells, with :

   |.`|:"2"_"2 i.3 3 3
 6  7  8

 3  4  5
 0  1  2

15 16 17
12 13 14

 9 10 11

24 25 26

21 22 23
18 19 20

I'm not sure why |.`|:"2"_"2 would give a different result from |.`|:"2"2 .

Cameron

[Henry Rich]

I'll respond tomorrow, but do read my reply to Elijah's post.  u"n is just plain u when the rank of u<=n (which produces anomalous results on gerund"n)

Henry Rich

[Cameron Chandoke]

Ah, goodness... I had read that, but wrongly thought that it only had relevance in the context of the hypothetical change of making gerund"n have infinite rank. Yes, I now see how it explains what would otherwise be my anomalous results. Well, my prior responses provided zero new information then -- just ignore. 

Separately, I'd like to voice my support for generally having ((u`v) Adverb) yield (u Adverb)`(v Adverb).  

The downside is that on NuVoc, each J word lists from among u v m n x y as its valid operands / arguments, and the proposal would imply that every adverb and conjunction would now accept and m or n in place of where it may formerly have listed only u or v... just for the sake of this one gerund functionality. 

Another alternative would be to leave just the (m"n) page to mention this behavior which affects the validity of operands of all other modifiers. Although this still leaves some inconsistency in the documentation, this seems the most reasonable to me.

Cameron

[Helen]

Having seen the higher-dimensional examples Cameron provided, I realised I never tested gerund"n on nouns with rank higher than n+1, and so I went back to try this, and the results are not what I expected: if you try

    (+`-"0&., -: +`-"0) i. 2 3

you should get 1. That is, +`-"0 y does all the calculation as if y were flattened, but without actually flattening y. In general, gerund"n acts as if y were actually ,&.:(<"n) y but keeping the original shape of y for the result (at least for the small examples I tested).

I hadn't realised this when I suggested that gerund"n should have rank infinity, although rank infinity makes sense if you were to keep this behaviour. However, perhaps it would make sense if instead gerund"n had rank n+1 and behaved like gerund"n"_"(n+1) does currently?

Either way, like you say, it is not a significant problem at all, and gerund"n appears nowhere in any of my code so I have no strong feelings either way - just adding in some thoughts I had after seeing today's emails.

Kind regards,

Helen

[Jan-Pieter Jacobs]

So, if I got it correctly, gerund"n being applied to rank _ is useful in the function it provides, but does not make sense with the semantics of how u"n applies elsewhere, i.e. the result does not have the rank that was specified.

The fact that <@ etc takes this rank would be consistent with what one expects from ", but not from the function assigned to gerund"n.

Perhaps it would make sense not to have this functionality tied to " then? It could also be a defined as a further case of `: as 'cycle gerund at rank n', like:

gerund`: (9,mr,lr,rr)

with mr, lr, rr working as for normal rank.

This way, the semantics of " are homogeneous again, and we keep the useful possibility of applying a list of gerunds cyclically to elements.

It would come at the cost of a few extra characters in use and a breaking change.

Best regards,

Jan-Pieter

[Henry Rich]

u`v adverb

can be supported by some adverbs but not others if need be.  Adverbs that already accept gerund arguments would have to be exceptions.

Henry Rich

[Henry Rich]

    (+`-"0&., -: +`-"0) i. 2 3

1

gerund"n doesn't flatten anything.  &., is Structural Under, restoring the shape of y.

Your generalization fails when the gerund changes the rank/shape:

   {.`{."1  i. 2 3 4
 0  4  8
12 16 20


I think rank (n+1) is hard to remember and not any better justified than rank _ .

Henry Rich

[Henry Rich]

The point is that the function of gerund"n, however it is specified, makes no sense when applied to cells individually.  That says it should have rank _ .

This is not enough of a problem to introduce a breaking change.

Henry Rich

[Helen]

To clarify, I don't mean that gerund"0 actually flattens or changes the shape of anything, just that if you were to first flatten, then apply gerund"0, then restore the shape of y, you would get the same result. In general, if you try

    flatten=:,&.:(<"n)    NB. "flattens" y to an array of rank n+1

    frame=:n&}.&.|.@$     NB. gets the shape of y, ignoring the last n entries

    (gerund"n -: frame $ gerund"n@:flatten) y

you should get 1, regardless of the choice of gerund, n and y. For example,

    n=:1

    gerund=:{.`{:

    flatten=:,&.:(<"n)

    frame=:n&}.&.|.@$

    (gerund"n -: frame $ gerund"n@:flatten) i. 2 3 4

1

I found this unexpected because from my understanding, gerund"n applies successive verbs from the gerund to items of rank n, and therefore, I thought it would act on lists of items of rank n (i.e. arrays of rank n+1). So, I expected that when applied to arrays of rank higher than n+1, it would first act on all the subarrays of rank n+1, and then collect the results according to the shape of y. That is, I expected that gerund"n would act as if it were a normal verb with rank n+1 (i.e. gerund"n"_"(n+1)). However, for example,

    ({.`{:"1 -: {.`{:"1"_"2) i. 2 3 4

0

My point with the these examples is that gerund"n is not acting on the subarrays of rank n+1 and then collecting the results according to the shape of y, it is acting on the entire array (as if it was just a flat list of items of rank n) and only using the full shape of y when collecting the results.

Perhaps this is the intended behaviour of gerund"n - I found it counterintuitive and so thought to bring it up.

Kind regards,

Helen

[Henry Rich]

The behavior is intended.  gerund"n applies to n-cells.  There might be an array of them, but each n-cell gets the next gerund, cyclically, and the frame is preserved.

Henry Rich