This isn't a bug in take, but a bug in ;. (cut). The results would make
sense if the verbal argument to ;. was < , or the RHA to the derived verb
were 0$a: , equivalents, but they're not, they're ] and '' respectively.
The issue is that b is boxed (with no elements), in the sense of 3!:0 (not
L. )*. To reason about the sensibilty of the overtake, you'd want to test for
the equivalence of '' to 0$a: (not a: or <'' as those arrays have 1
element and '' has 0). But the test wouldn't be whether the arrays match,
because of course they match, having the same shape and no differing elements
(i.e. the set of non-shared and hence non-matching elements is itself empty).
Type generally doesn't play a part in equivalence (though obviously it can be
used as a shortcut in lots of cases) -- for example, 1r2 = 0.5 and 'hello'=3 u:
'hello' (if I'm remembering the correct function code to produce Unicode from
ASCII)*.
But once you add elements to an empty array, the question of type is relevant
again. Fill (as in overtake) and catenation are examples of adding elements to
an array.
-Dan
* It is tempting to use this "no elements" reasoning to answer the question of
why L. doesn't consider 0$a: boxed -- because that array contains no boxes.
But a more convincing reason arises when we ask "if not 0, then what should
L.0$a: produce?". How deep is such an array? If that empty array is boxed,
then we can say the depth is 1+ the depth of the boxed contents. But what are
the contents of the boxes that don't exist? Do they, too, contain boxes that
don't exist?
It would be more egalitarian to say the type of >a: is boxed, because then
you do not impute a type onto the contents (we mostly view box as a type unto
itself, but it can also be viewed as an envelope that hides the type, or marks
the type as unknown or irrelevant - the dictionary considers "boxed vs open" a
characteristic independent of type, like shape), and of course the type of the
array itself is box (so which other type should we prefer? Why would that
other type get special treatment?).
In fact, in some circumstances the (empty) open of a empty boxed array has type
boxed (and yes, the open of that array is also boxed), but I believe this is
considered a (grandfathered in) bug, rather than intentional.
Anyway, if you want to test whether an array has type box, rather than whether
it has depth, then you can ask a: -: 0 {.@:$ , (using the overtake behavior
you noticed) or even just 32-:3!:0 using the interpreter's reflective
capabilities. Of course, the type of an empty array is most often irrelevant
(as contrasted with, say, its shape), and would only matter in the kind of case
the test uses to see if it's "boxed" in the first place.
As a pragmatic thing, you shouldn't care about the type of an empty array, as J
is careful to maintain type throughout operations, and the external interfaces
are careful to produce the right type of empties when they need to. This is a
nice feature of J -- edge cases aren't.
The only cases where I've encountered a problem is when I prototyped
(initialized) an array with the wrong type (usually '' because it's easy to
type) and later caused it to fill. More often than that though, the problem
with my prototypes has bee an ill-considered shape. Maintain the J philosophy,
and ensure *your* edge cases aren't!
Anyway, I can't think of situation where a "surprising" type isn't a bug, and
we should report such surprises. Like you just did!
------Original Message------
From: June Kim
Sender: [email protected]
To: J Programming
ReplyTo: J Programming
Subject: [Jprogramming] strange behavior in "take"
Sent: Jan 14, 2010 2:17 PM
b=.1];._3 ''
b
''-:b
1
(<'')-:b
0
4{.''
4{.b
+++++
|||||
+++++
(4{.'')-:4{.b
0
Why is the result of 4{.b boxed here? I think it shouldn't be boxed.
Is this a bug?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
Please excuse typos; composed on a handheld device.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
