--- Bruno Daniel <[EMAIL PROTECTED]> wrote: > > Omitting your detailed comments on trains, and how to distinguish hooks > > from forks, let me interject that valence is an entirely orthogonal > > matter. Any verb train may be put into either monadic or dyadic > > contexts, and figuring out what sort of verb train you have in hand does > > nothing to resolve valence. > > x (v4 v3 v2 v1) y > (a hook) will be executed as > > x v4 ((v3 y) v2 (v1 y)) > ======================= > not as > x v4 ((x v3 3) v2 (x v1 y)) > or anything else, > while > > x (v5 v4 v3 v2 v1) y > (a fork) will be executed as > > (x v5 y) v4 (x v3 y) v2 (x v1 y) > ================================ > > so the two concepts are not orthogonal. The addition of v5 changes the valence > of many verbs in the train.
The design goal of J notation was to be like mathematics. Mathematics is beautiful, but it is not simple. COBOL is not beautiful, neither it is simple. Java is simple, but I do not recall anyone boasting about beauty of a passage in Java. (Recent generics following Smalltalk and Lisp are cute but not handsome.) J is not just an array library, it is the whole package; and notation plays a central role. So if one likes the arrays but cannot accept the notation, then implementing array primitives in another language and devising a convenient interface to them is probably the way to go. But it won't be J then. The Maxwell's equations is a very good analogy: would you rather get introduced to them in their pristine mathematical form or as a FORTRAN subroutine (with .GE. amount of comments). However, to be prepared to handle this mathematical brevity, one has to be subjected to serious training in vector, tensor et al analyses. Interestingly, the examples of "readability issues" are just encounters with some of the sharp edges (pun indented) of this thoughtful design. Indeed, as quoted above, the addition of train element changing effect of other elements rings the bell of stacked fractions in arithmetic, where adding another level changes numerators and denominators. The awareness about monadic/dyadic context in tacit expressions brings about none other than the design feature of ambivalence: http://www.google.com/search?q=ambivalent&sitesearch=jsoftware.com To illustrate, I was recently fascinated, re-reading Keith Smillie "J Companion for Statistical Calculations", 1999 http://www.jsoftware.com/jwiki/Stories/KeithSmillie by how ambivalence allows to represent variance and covariance with a single verb. So not only do those formulas look alike, they get executed from the same expression. That is the realization of executable notation: the "initial motive for developing APL" Kenneth Iverson "A Personal View of APL," IBM Systems Journal, 30(4), 1991 http://www.research.ibm.com/journal/sj/304/ibmsj3004O.pdf Some of the ingredients of the mathematical beauty, brevity and clarity (not simplicity), can also be illustrated by this example: not only do J primitives fit onto a single page, but also many topics covered thereby. NB. ========================================================= mean =: +/ % # NB. arithmetic mean dev =: - mean NB. deviation form mean ssp =: +/ @ (*&dev)~ NB. sum of squared devs (monad) NB. or products of devs (dyad) var =: ssp % <:@[EMAIL PROTECTED] NB. sample variance (monad) NB. or covariance (dyad) sdev =: %: @ var NB. standard deviation cor =: var % *&sdev~ NB. correlation (dyad), 1 (monad) Note 'example' x1=. 5.27 5.68 6.25 7.21 8.02 8.71 8.42 y1=. 12 18 24 30 36 42 48 x1 cor y1 ) NB. ========================================================= ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
