there is,
$ 0 {"0 1 i. 0 3
0
the problem comes with rr of _ or maximum of rhs
$ (0$0) {"0 1 i. 0 3
0
Not very pleasant to keep the behaviour, though at the same time I can imagine
the behaviour to be used in ({ :: v). Though not by me, as playing with the
subtleties of null is not that fun, especially when you/reasonable people will
want to correct dumb behaviour.
Another possibility would be to fix $: . On the other hand, I can somewhat
understand the current logic from these examples
$ 0 {"0 0 i.0 4 2
0 4 2
$ 0 {"0 1 i.0 4 2
0 4
$ 0 {"0 2 i.0 4 2
0 2
$ 0 {"0 3 i.0 4 2
|index error
| $0 {"0 3 i.0 4 2
{. 0 {"0 0 i.0 4 2
0 0
0 0
0 0
0 0
The 0th index at maximum rank doesn't exist. Seems reasonable.
A different approach that is semi-consistent in J is to guard functions with
^:(0 <#@]) . Many functions implicitly behave this way, and its a useful
general abstraction for nulls.
$ 3 + i.0 3
0 3
$ 3 {^:(0 <#@]) i.0 3
0 3
----- Original Message -----
From: Henry Rich <[email protected]>
To: [email protected]; Programming forum <[email protected]>
Sent: Wednesday, May 11, 2016 4:00 PM
Subject: [Jprogramming] Design issue: incompatible specs/expectation
concerning fill
1. When a verb is executed on an empty argument, it executes on a cell
of fills to find the shape of the result (using atomic 0 as the result
if the execution fails)
2. The shape of (integerarray { otherarray) is ($integerarray, (shape of
an item of otherarray)).
These are inconsistent. It's not obvious, but here's an example:
(0$0) { i. 0 3
The x argument has a 0 in the frame, so it should execute on a cell of
fills; that is, the verb should start by executing
0 { i. 0 3
This fails with index error, so the result of the fill-cell execution
should be taken to be atomic 0, and the overall result should have shape
(,0).
It doesn't because (integer { array) is implemented as if { had infinite
left rank. ((0$0) {"{ i. 0 3) produces the correct result.
I fixed that, so that { produced the right result, but it broke
something in sparse-array processing that depended on the old rules. I
am now wondering if there might be user code too that depends on this
erroneous behavior.
A similar case is
(i. 0 2) +"1 i. 0 3
This fails with length error, but by the fill rules it should produce (0$0).
I would like to have a discussion about the right course of action
with the JE. We could:
1. Leave the current inconsistent behavior as is (yuk!).
2. Make { conform to the spec, violating rule 2 above and possibly
causing errors in the field
3. Others?
Henry Rich
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
