Confusing results in J
John K. Taber
Let a=.i.5
I want to get a running balance, as for a checkbook so I enter
}.+/\a
which gives me the expected
1 3 6 10
This is nice, so I assign the verbs to bal as follows
bal=.}.+/\
But bal a gives me a quite unexpected length error!
If I display bal, the boxed result is exactly the same as for the bare
}.+/\.
I don't see what I'm doing wrong, so what is going on?
--
John K. Taber jkt...@netcom.com
===========================================================================
The whole world watches America, and America watches TV.
Sam Sirlin
|> Will somebody explain to me what I'm doing wrong in J?
|> Let a=.i.5
|> I want to get a running balance, as for a checkbook so I enter
|> }.+/\a
|> which gives me the expected
|> 1 3 6 10
|> This is nice, so I assign the verbs to bal as follows
|> bal=.}.+/\
|> But bal a gives me a quite unexpected length error!
|>
|> If I display bal, the boxed result is exactly the same as for the bare
|> }.+/\.
One easy way to fix things is to ask J what to do. In version 6 at least
bal2=. '}.+/\ y.' :11
will give you what you want. Then you can look at what J wrote for
you, or (as I often do) just move on to the next function.
--
Sam Sirlin Jet Propulsion Laboratory
Email: s...@kalessin.jpl.nasa.gov
WWW: http://grover.jpl.nasa.gov/~sam/index.html
Raul Deluth Miller
. Let a=.i.5
. I want to get a running balance, as for a checkbook so I enter
. }.+/\a
. which gives me the expected
. 1 3 6 10
. This is nice, so I assign the verbs to bal as follows
. bal=.}.+/\
. But bal a gives me a quite unexpected length error!
.
. If I display bal, the boxed result is exactly the same as for the bare
. }.+/\.
The problem is that a bare '}.+/\' parses differently from '}.+/\a'.
Digging out my old demonstration parse program, I note that }. and +
are verbs (it ignores the semantics of the words, and just uses the
first letter of each word to indicate syntactic properties), the
parsing for the first phrase works like this:
parse 'vdrop vplus areduce ascan noun'
queue stack pattern action
$ vdrop vplus areduce ascan noun ? ? ? ? GetNext
$ vdrop vplus areduce ascan noun ? ? ? ? GetNext
$ vdrop vplus areduce ascan noun ? ? ? ? GetNext
$ vdrop vplus areduce ascan noun ? ? ? ? GetNext
$ vdrop vplus areduce ascan noun ? ? ? ? GetNext
$ vdrop vplus areduce ascan noun $=(avn nv a ? Adverb
$ vdrop v ascan noun $=(avn nv a ? Adverb
$ vdrop v noun ? ? ? ? GetNext
$ vdrop v noun $=(avn v v n Monad2
$ vdrop n $=( v n ? Monad1
$ n Accept
Note especially the last three lines: the verb derived (by application
of the two adverbs to the addition operation) is applied as a monad to
the noun. The result is passed to the drop verb, which is also used
as a monad.
parse 'vdrop vplus areduce ascan'
queue stack pattern action
$ vdrop vplus areduce ascan ? ? ? ? GetNext
$ vdrop vplus areduce ascan ? ? ? ? GetNext
$ vdrop vplus areduce ascan ? ? ? ? GetNext
$ vdrop vplus areduce ascan ? ? ? ? GetNext
$ vdrop vplus areduce ascan $=(avn nv a ? Adverb
$ vdrop v ascan $=(avn nv a ? Adverb
$ vdrop v ? ? ? ? GetNext
$ vdrop v $=( v v ? Hookv
$ v Accept
Again, notice the last few lines. Instead of two monad applications
of verbs, the verbs are combined using a hook.
The net result here is that
(}. +/\) a
is about like saying
a }. +/\ a
What you want to do is more like
bal =: }. @: (+/\)
Or, perhaps more intuitively,
}. [: +/\
[: is the empty function (it has no domain), which is treated
idiomatically by the parser when constructing forks.
--
Raul D. Miller N=:((*/pq)&|)@ NB. public e, y, n=:*/pq
<rock...@nova.umd.edu> P=:*N/@:# NB. */-.,e e.&factors t=:*/<:pq
1=t|e*d NB. (,-:<:)pq is four large primes, e medium
x-:d P,:y=:e P,:x NB. (d P,:y)-:D P*:N^:(i.#D)y [. D=:|.@#.d
Roger Hui
> Let a=.i.5
> I want to get a running balance, as for a checkbook so I enter
> which gives me the expected
> This is nice, so I assign the verbs to bal as follows
> But bal a gives me a quite unexpected length error!
>
Subsequently, Raul Miller wrote:
> The problem is that a bare '}.+/\' parses differently from '}.+/\a'.
>
> Digging out my old demonstration parse program, I note that }. and +
> are verbs (it ignores the semantics of the words, and just uses the
> first letter of each word to indicate syntactic properties), the
Running a model of the parser can be interesting and instructive,
but (I believe) only after having already acquired some familiarity
with the language by other means. In this instance the question
has a much simpler answer. The composition obtained by juxtaposing
verbs f and g is a "hook" whose monad is defined as follows:
(f g) x <-> x f (g x)
The desired composition is effected by @, wherein
(f @ g) x <-> f g x
Displaying "bal", as stated in the original msg, is a good first step
in determining what it does.
bal=.}.+/\
bal
+--+---------+
|}.|+-----+-+|
| ||+-+-+|\||
| |||+|/|| ||
| ||+-+-+| ||
| |+-----+-+|
+--+---------+
The display of a verb has 1, 2 or 3 boxes. If 1 box, the verb
is primitive. If 2 boxes, look at the left box. If it is an
adverb a, then the verb is derived from v a; if not, then the
original verb is a hook. If 3 boxes, look at the middle box.
If it is a conjunction c, then the verb is derived from v0 c v1;
if not, then the original verb is a fork. This description
assumes boxed display 9!:3 (2), but with the obvious modifications
also applies to the tree display 9!:3 (4) or even to both together
9!:3 (2 4).
To gain facility with compositions, define a few verbs whose
interpretation you know and look at their displays. For example:
sum =. +/
mean =. +/ % #
ss =. +/ @ *:
norm =. %: @ (+/) @ *:
norm2 =. +/ &. *:
integral =. = <.
double =. 2&*
t2 =. + -
t3 =. + - *
t4 =. + - * %
t5 =. + - * % |
f2 =. + @ -
f3 =. + @ - @ *
f4 =. + @ - @ * @ %
f5 =. + @ - @ * @ % @ |
g2 =. + @ -
g3 =. + @ (- @ *)
g4 =. + @ (- @ *) @ %
g5 =. + @ (- @ *) @ % @ |
Robert Bernecky
>John Taber wrote on Wednesday, November 23:
>
>> Let a=.i.5
>> I want to get a running balance, as for a checkbook so I enter
>> }.+/\a
>> which gives me the expected
>> 1 3 6 10
>> This is nice, so I assign the verbs to bal as follows
>> bal=.}.+/\
>> But bal a gives me a quite unexpected length error!
Lemme get out my shoe and pound on the podium here for a moment.
This is a very common error among those new to J. In fact, it is so
common that it may reflect an error in design. Now, before everyone
leaps on me for being {insert your favorite word here},
let me clarify what I mean.
Errors in design may arise from several causes. One cause that is habitually
ignored is that of human factors, also called ergonomics. In the
design of aircraft, such design errors tend to be fixed, since their
presence causes unfortunate events such as crashes. An example of
this is an aircraft that had the throttle controls and flaps {I think}
side by side, with the SAME handles. A pilot who was busy with other
things -- watching traffic, eyeballing the runway, etc., could easily
grab the wrong control, with disasterous results.
This design fault was fixed in a very simple manner: The handles on
one set of controls were made VERY different from the other controls,
so that grabbing the wrong one was quite evident to the pilot.
In computer language design, as far as I can tell, NOBODY has ever
submitted a design to serious ergonomic testing. I am not sure
whether this is due to ego: "I KNOW what is right" or merely that
nobody ever thought it was important.
It would be enlightening, I believe, to subject J [and other languages]
to "Usability Testing" for a variety of users. The above error,
which appears to be related to substitutability of expressions,
reflects a subtle aspect of J semantics that is not grasped, at least
initially, by users. The development of a "conceptual model" of
the internals of J [or any other language and/or system] is key to
the understanding, or lack thereof, of that system.
If your conceptual model is at odds with the real thing, you'll continue
to make errors using that thing.
One way we, as designers, can help users to develop an appropriate
conceptual model is via "affordances", things that give us a clue of
How to use the system. A good example is that of a pushplate or
handle on a door: If you come up to a door with neither of these, it is
not clear how to get through. Push? Pull? Slide? If the door has an
handle, howver, you instinctively pull. If it has a pushplate, you
push. We can measure the usability of a system through usability testing,
giving a number of users simple tasks to perform, using the system.
If a lot of them make the same error(s), you can bet that the system
is designed wrong. Documentation is NOT the way to fix this. Books are
not the way to fix this. Changing the design, to reflect how people
think is a good start. Then go back and run usability tests again.
After a few iterations, it'll start to look great!
If usability testing had been applied to the APL keyboard, you can bet
your socks that:
a. There NEVER would have been two sets of parentheses (etc etc)
b. There might never have been an APL character set.
This may be considered by some to be a Bad Idea. Perhaps.
On the other hand, the popularity of APL might have been MUCH
greater.
Bob
John K. Taber
Robert Bernecky (bern...@eecg.toronto.edu) wrote:
: Lemme get out my shoe and pound on the podium here for a moment.
: This is a very common error among those new to J. In fact, it is so
: common that it may reflect an error in design. Now, before everyone
: leaps on me for being {insert your favorite word here},
: let me clarify what I mean.
Well, it is at least an error in the handbook. The Introduction and
Dictionary needs to clearly state that (....) is parsed differently from
.....
Note that, while I'm sure Roger Hui's comments are correct (and helpful)
I got into difficulty because the boxed display of the function didn't
help me. Both (}.+/\) and }.+/\ display the same. So, you must state
somewhere, and in an obvious manner, not as a problem to be worked out by
the student, that while they look the same, they don't behave the same.
Handbooks if intended for programmers should not be written like course
materials for one's acolytes in a math course.
[snip]
: If usability testing had been applied to the APL keyboard, you can bet
: your socks that:
: a. There NEVER would have been two sets of parentheses (etc etc)
: b. There might never have been an APL character set.
: This may be considered by some to be a Bad Idea. Perhaps.
: On the other hand, the popularity of APL might have been MUCH
: greater.
: Bob
OK. Let me put on my asbestos suit, and get in trouble. I've heard that
some folks consider APL's biggest mistake to be its use of Greek characters.
It may well have been. In my non-scientific sampling of programmers, the
Greek indeed scared them off. It made APL look like math, and in their
minds, math means hard, so they quickly put down the book and went on to
something else.
I've also heard that J means to correct that error, whether openly avowed
or not. There is at least no Greek in J. That's good. But if you think the
analogy to grammar is an improvement, you're crazy. Greek letters put folks
off. Gerunds and conjunctions will scare them shitless.
For God's sake, get rid of this blunder before it is too late. J is still so
new that you can rework all the manuals to suppress this analogy to grammar.
I don't mind if you use it amongst yourselves, a jargon for the esoterics,
so to speak. But for the rest of the world, use the language the world uses.
I mean this to be constructive criticism, if blunt. I offer it because I do
see the power and potential of J. J is going to be a tough enough sale, and
you don't need to shoot yourselves before you start by making a mistake.
Roger Hui
> This is a very common error among those new to J. In fact, it is so
> common that it may reflect an error in design. Now, before everyone
> leaps on me for being {insert your favorite word here},
> It would be enlightening, I believe, to subject J [and other languages]
> to "Usability Testing" for a variety of users. The above error,
> which appears to be related to substitutability of expressions,
> reflects a subtle aspect of J semantics that is not grasped, at least
> initially, by users. The development of a "conceptual model" of
> the internals of J [or any other language and/or system] is key to
But a new user is not going to have a conceptual model.
I'll come right out and say it: Neophyte errors are irrelevant
to language design. The J example involves juxtaposing two entities.
Suppose one were to test the initial reaction to juxtaposed numbers
by "the man in the street". Suppose many more of such people assume
"multiplication" rather than "vector constant". What then?
Errors (including "silly errors") made by experienced users are
another matter.
> Lemme get out my shoe and pound on the podium here for a moment. ...
> If usability testing had been applied to the APL keyboard, you can bet
p.s. Why all the references to footwear all of a sudden?
Reiter Clifford A
: Bob Bernecky wrote on Friday, November 25:
: > This is a very common error among those new to J. In fact, it is so
: But a new user is not going to have a conceptual model.
: to language design. The J example involves juxtaposing two entities.
: Suppose one were to test the initial reaction to juxtaposed numbers
: by "the man in the street". Suppose many more of such people assume
: "multiplication" rather than "vector constant". What then?
:
: Errors (including "silly errors") made by experienced users are
: another matter.
Actually, I think this example of juxtaposing numbers is a good one.
(I also agree with Roger that these errors aren't important - but the
ones that keep hanging up experienced users sure are.)
My ten year old started working through "Arithmetic" and that was the
first thing that hung him up. By the way, he assumed the extra spaces
were a typo, so he just left them out and then wondered why he wasn't
getting the same answers as shown in the book.
John K. Taber (jkt...@netcom.com) wrote:
: OK. Let me put on my asbestos suit, and get in trouble. I've heard that
: some folks consider APL's biggest mistake to be its use of Greek characters.
: It may well have been. In my non-scientific sampling of programmers, the
: Greek indeed scared them off. It made APL look like math, and in their
: minds, math means hard, so they quickly put down the book and went on to
: something else.
: I've also heard that J means to correct that error, whether openly avowed
: or not. There is at least no Greek in J. That's good. But if you think the
: analogy to grammar is an improvement, you're crazy. Greek letters put folks
: off. Gerunds and conjunctions will scare them shitless.
: For God's sake, get rid of this blunder before it is too late. J is still so
: new that you can rework all the manuals to suppress this analogy to grammar.
I suspect that those developing J need to use the language (gerund, adverb,...)
that they have in order to be precise and avoid the baggage of assumptions
that would be made if the language of other programming languages were used.
However, I agree that there must be more pleasant ways to become an
experienced J user than reading the manuals (Release 2 stuff is better, but...).
I think of this as an opportunity. How about writing some books on/using J?
Volunteers?
Cliff
--
Clifford A. Reiter
Mathematics Department, Lafayette College
Easton, PA 18042 USA, 610-250-5277
Raul Deluth Miller
. I got into difficulty because the boxed display of the function
. didn't help me. Both (}.+/\) and }.+/\ display the same. So, you
. must state somewhere, and in an obvious manner, not as a problem to
. be worked out by the student, that while they look the same, they
. don't behave the same.
I think it's important to point out that these behave the same. The
problem is that (}.+/\)a does not behave the same as }.+/\a
(Nor does it display the same, for typical values of a).
. Handbooks if intended for programmers should not be written like
. course materials for one's acolytes in a math course.
Or, more generally, written material should be designed for its
intended audience. Traditionally, in academic fields, this is handled
by associating "difficult" works with a set of pre-requisites.
. OK. Let me put on my asbestos suit, and get in trouble. I've heard
. that some folks consider APL's biggest mistake to be its use of
. Greek characters. It may well have been. In my non-scientific
. sampling of programmers, the Greek indeed scared them off. It made
. APL look like math, and in their minds, math means hard, so they
. quickly put down the book and went on to something else.
The problem with the Greek characters is a technical one: most people
don't have these characters on their keyboards. There are, of course,
dozens of workarounds to this problem -- but this multiplicity of
interfaces makes communication difficult.
. I've also heard that J means to correct that error, whether openly
. avowed or not. There is at least no Greek in J. That's good. But if
. you think the analogy to grammar is an improvement, you're
. crazy. Greek letters put folks off. Gerunds and conjunctions will
. scare them shitless.
"They" don't have to use gerunds and conjunctions.
The "real problem" is that when a person gets into difficulty, a
"random" methodology is adopted. If there's no strategy or mechanism
to get the person back on track, all sorts of strange associations are
developed. Frequently, these associations are erroneous...
. For God's sake, get rid of this blunder before it is too late. J is
. still so new that you can rework all the manuals to suppress this
. analogy to grammar. I don't mind if you use it amongst yourselves,
. a jargon for the esoterics, so to speak. But for the rest of the
. world, use the language the world uses.
Please, take a look in your dictionary of the english language and
look up some of these words: grammar, syntax, gerund, conjunction,
jargon. Are there more widely documented words which address some of
these concepts? Can you phrase your imperative in a more direct
fashion?
This problem of documentation is a pervasive issue.