Author Message collecting questions about J

Further to the discussion about functions applied to the rows and the
columns of a table, here is demonstration that the preferred way to
specify the application of a function TO EACH ROW OF A TABLE and the
application of the same function TO EACH COLUMN OF THE SAME TABLE is to
use the rank conjunction along with the transpose.  "Preferred way" in
this case is defined to mean "a general way", that is, "a way that
always gives a correct result, no matter what the function."

transpose =. |:
m =. i. 3 3
m
0 1 2
3 4 5
6 7 8

NB. f and g both sum the (non-zero) elements in y.
f =. 3 : '+/ (-. 0=y.)#y.'
g =. 3 : '+/y.'

NB. apply f and g TO EACH ROW of table m
NB. (that is, apply TO EACH RANK-1 CELL)
NB. they are equivalent
f"1 m
3 12 21
g"1 m
3 12 21

NB. apply f and g TO EACH COLUMN of table m
NB. (that is, apply TO EACH RANK-1 CELL OF THE TRANSPOSE)
NB. they are equivalent
f"1 transpose m
9 12 15
g"1 transpose m
9 12 15

NB. ... BUT
NB. f and g have different behaviours for RANK-2 cells
NB. (f and g have different behaviours for a table)
f m
3  6  9
12 15 18
12 14 16
g m
9 12 15

NB. similarly for the "mean" function
mean =. +/ % #

NB. mean OF EACH ROW of table m
mean"1 m
1 4 7

NB. mean OF EACH COLUMN of table m
mean"1 transpose m
3 4 5

This may of course be compared with the syntax in APL, where
the sum of each row is given by +/m and the sum of each column is
given by +/m, and there is no general expression to apply an
arbitrary function to each row (or each column) of a table.  (I believe
this last statement is correct.)  Also the previous expressions were
origin-dependent.  (No origin-dependence in J.)

--RL

Tue, 11 Nov 1997 03:00:00 GMT  collecting questions about J

Richard Levine writes on Friday, May 26:

Quote:
> Further to the discussion about functions applied to the rows and the
> columns of a table, here is demonstration that the preferred way to
> specify the application of a function TO EACH ROW OF A TABLE and the
> application of the same function TO EACH COLUMN OF THE SAME TABLE is to
> use the rank conjunction along with the transpose.  "Preferred way" in
> this case is defined to mean "a general way", that is, "a way that
> always gives a correct result, no matter what the function."

I disagree.

a. Transpose implies a large movement of data and should be used
as last resort.  An application making extensive use of transpose
probably has a mistake in its data design.

b. I don't see why a method which always works, no matter what
the function, is necessarily a preferred way.  Such generality
usually comes at a price in both readability and efficiency.

Consider the following analogy:  In APL (and J) not everything can
be done using non-looping expressions.  Should looping methods
be preferred over non-looping ones, because they are "more general"
and "always work"?

In the case of "mean", the simpler expression is in fact more general,
working on arrays of any rank, not just tables.

Quote:
>   NB. f and g both sum the (non-zero) elements in y.
>      f =. 3 : '+/ (-. 0=y.)#y.'
>      g =. 3 : '+/y.'

I find these examples contrived and unconvincing.  Why the circum-
locutory  f"1 |: m  and  g"1 |: m  when the equivalent  +/m  is so much
terser (and faster by factors of 17 and 12 for f and g, respectively)?

Wed, 12 Nov 1997 03:00:00 GMT  collecting questions about J

Quote:

>a. Transpose implies a large movement of data and should be used
>as last resort.  An application making extensive use of transpose
>probably has a mistake in its data design.

Nossir. Transpose implies a change in the view of the data.
It need not imply ANY data movement. In fact, APL implementations
that DO move data for a transpose [SHARP APL, IBM APL2, Dyalog APL,
APL*PLUS III tm c etc -- did I miss any of them?] suffer dismal
performance simply because they do NOT implement descriptor
algebras that would permit ALL structual operations to be performed in
fixed time, regardless of array size.

Data movement is indeed expensive, and should be avoided, but
good interpreter or compiler design can make the performance of
transpose, etc., a non-issue.

Now, as to Roger's second claim "mistake in its data design" presumes
that the way data is accessed remains static thoughout the application.
This simply isn't true in reality. The HPF fortran people made the
same mistake.

Robert Bernecky

Snake Island Research Inc
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9

tel: (416) 203-0854
fax: (416) 203-6999

Fri, 14 Nov 1997 03:00:00 GMT

 Page 1 of 1 [ 3 post ]

Relevant Pages
 11. profile.js