I was watching an "All Questions Answered" lecture by DEK -
http://www.youtube.com/watch?v=CDokMxVtB3k
and noted comments starting about 9 minutes into the lecture
concerning the unique patterns resulting from rearranging a set like
0 0 0 1 1 1. His comments caused me to tinker with the ideas in j.
After playing with my verbs (that expose a bug) and doing some
research on the topic in a more general way, I found that I had
hacked out a quite obscure way of writing what would be much faster,
leaner, more elegant, correct, and extensible (the x: bit), done as -
oof =: 13 : '(i.y+1)!x:y' NB. Out OF
oof NB. showing that 13 : produces quite a satisfying result
x: !~ [: i. 1 + ]
oof 6
1 6 15 20 15 6 1
That is, the number of ways of taking each of i. n+1 things from a
collection of n.
In my play, I started off with a sieve of all the binary numbers
possible with n digits. Then I decided that it was more useful just
to enumerate the patterns and I replaced a # by [ and made a table
with =/ and came up with the following (HackedOutOF) -
hoof =: 3 : '+/"1 ((>: i.y) =/ +/"1 z) [ z =. #: i. 2^y'
hoof 6
1 6 15 20 15 6 1
Happily, it gives the same result as oof (even though complicated and
obscure...) My use of the temporary z was just sloppiness - but I
didn't notice that until I was flummoxed by making a tacit form -
hooft =: 13 : '+/"1 ((i.y+1) =/ +/"1 z) [ z =. #: i. 2^y'
and discovering that it produces a very different result (displaying
the shape is sufficient to show that without wasting space).
$hooft 6
7 64 7
So clearly, 13 : failed. This rings a bell of something similar being
reported before, but maybe it is different. I haven't succeeded in a
simple expression that goes wrong in the same way. I'm sure someone
in the forum can provide a tacit form that is similar, but works
correctly - something other than -
hooft
([: i. 1 + ]) ([: +/"1 [ =/ +/"1) [: #: [: i. 2 ^ ]
or perhaps a simple example that demonstrates the bug....
BTW, this problem occurs the same in j versions 6-32, 7-32, and 7-64.
However, things work OK in versions 405, 501 and 503a where 13 :
produces a longer, but works OK, result -
hooft
[: +/"1 (([: i. ] + 1:) =/ [: +/"1 [: #: [: i. 2: ^ ]) [ [: #: [: i. 2: ^ ]
I also note that if I remove the extraneous use of z in the definition, i.e.
hooft =: 13 : '+/"1 (i.y+1) =/ +/"1 #: i. 2^y'
hooft
[: +/"1 ([: i. 1 + ]) =/ [: +/"1 [: #: [: i. 2 ^ ]
hooft 6
1 6 15 20 15 6 1
Then it works correctly in all versions. So, I conclude it has
something to do with the extraneious local variable z.
Upon looking, I found there was a previously reported 13 : problem
(maybe from the same gremlin). In j602 and j7
v2 =: 13 : 'y + y'
v2
+
Which, of course, doesn't produce the expected result of doubling y.
In older versions (503a and earlier) -
13 : 'y. + y.'
] + ]
which works correctly. Both seem like bugs that should be fixed.
Ironically, the work around offered at the time was
v2 =: 13 : 'n + n [ n=.y'
v2
] + ]
Which does produce a correct result even though a similar extraneous
variable seems to be the culprit in my problem...
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
