From: *Henry Rich* <[email protected]>
Date: 11 May 2016 at 13:00
To: [email protected], Programming forum <[email protected]>
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
----------
From: *Raul Miller* <[email protected]>
Date: 11 May 2016 at 13:12
To: Programming forum <[email protected]>
Cc: [email protected]
When introducing breaking changes, I think it's best to make them
optional (9!:something to revert).
(But if that is too painful to implement, I guess it gets skipped and
people with problems need to hold onto an older implementation.)
--
Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------
From: *'Pascal Jasmin' via Programming* <[email protected]>
Date: 11 May 2016 at 14:10
To: "[email protected]" <[email protected]>
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
----------
From: *Roger Hui* <[email protected]>
Date: 11 May 2016 at 16:19
To: Henry Rich <[email protected]>
Cc: [email protected], Programming forum <[email protected]>
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).
In my mind this is not a similar case. There is a rule which may not
written down but should be written down, and the rule is this: If the
shape of the result can be computed from the shape(s) of the argument(s)
alone, then that is done, and if no elements are involved (argument(s) are
empty) then you are done (return the result) without further ceremony.
----------
From: *Henry Rich* <[email protected]>
Date: 11 May 2016 at 16:38
To: Roger Hui <[email protected]>
Cc: [email protected], Programming forum <[email protected]>
That's the sort of rule I was looking for. But more needs to be said to
make it unambiguous, namely when the shape can be so computed, and what the
shape of the (empty) result should be.
For example, (+), (+"+), (p =: +), and (4 : 'x+y'"0) all do the same
calculation, but the first gives an error when applied with rank 1, and the
others don't. Do we say 'the shape of the result can be computed from the
shape of the arguments alone' when the verb is a primitive or, for
primitives with IRS, the form primitive"n? And should the shape of the
result correspond to a literal reading of the fill-cell rule, as in my
examples, or should it follow some other precept?
It does seem incongruous to say that
(i. 0 2) +"1 i. 0 3
and
p =: +
(i. 0 2) p"1 i. 0 3
should have different results. But I am beginning to think that following
the fill-cell rule does not produce the most desirable results either. So
I would like us (the J community) to think about how to nail down what
should be the rules on the results of execution on empty arguments.
Henry Rich
----------
From: *Raul Miller* <[email protected]>
Date: 11 May 2016 at 17:11
To: Programming forum <[email protected]>
Cc: Roger Hui <[email protected]>, [email protected]
It probably is primitives only which can compute the shape of the
result from the shape of arguments alone.
The reason being that non-primitives need to deal with an arbitrarily
large verb space.
--
Raul
----------
From: *Henry Rich* <[email protected]>
Date: 11 May 2016 at 17:13
To: Roger Hui <[email protected]>
Cc: [email protected], Programming forum <[email protected]>
How about something like this?
The current rule is that if the fill-cell gets an error, execution
continues as if it had returned 0. We could say that this happens only for
a subset of errors: domain error for sure, others maybe. But a length
error would be passed through to fail the execution of the verb. Index
error, I'm not sure.
Henry Rich
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
