Asked for thoughts, so here they go:
How many operations can be optimized
to not actually bring it to the front?
(special combinations wrt the t. family)
Not that many, I think. So it’s better
to actually
1. prepare your data layout and =: the result
2. apply an easily understood algorithm to it
… but I agree with your “advantages” section
Am 24.01.22 um 05:30 schrieb Elijah Stone:
Suppose I would like to normalise a vector. Easy: %+/&.:*:. Nice and
pretty, gotta love under.
What if I've got an array of vectors, and I want to normalise all of
them? There are two ways, corresponding to two different
representations: %+/&.:*:"1 and %"_1 _ +/&.:*:. The former corresponds
to an array where the last axis is the axis axis, and the latter to an
array where the leading axis is the axis axis (which may seem odd, but
I've found it useful).
There are two operations involved: a division and a reduction. Neither
of these _needs_ to be applied at rank, but we cannot avoid ranking
_both_ of them. Now suppose the axis axis is neither leading nor
trailing. Then we need: (%"_1 _ +/&.:*:)"n.
" is inherently eachy. That is not a bad thing--sometimes there are
eaches to be eached--but it does mean it is somewhat heavy-handed. |:
is an interesting alternative. %"_1 1 can be written as %&.(0&|:`a:).
And the sum can be performed moving the axis in question to the front
rather than to the back.
I therefore propose a 'transpose-ish' family of conjunctions. Say: t.
t: t.. t:: (RIP Taylor series). u t. n brings axis n to the front
(brings it near) before applying u; u t.. n brings axis n to the rear
(brings it far, hence the longer suffix); u t: n brings axis n to the
front before applying u, but returns it afterwards (hence two dots); t::
should be obvious.
Advantages: encourages holistic, array-oriented thinking over eachy
thinking. Distinguishes rank's role as a vehicle for repetition from
its role as a general alternative to the axis operator. A single
application under transpose can replace nested applications at rank.
Disadvantages: harder to teach. Maybe harder to understand (though
operations on high-dimensional arrays may be difficult to understand
regardless). Probably harder to implement performantly. I propose too
many primitives, and if The Powers That Be are not wise enough to reject
them all, they will turn the language into C++.
Thoughts?
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
