This is a very interesting topic: What should be a primitive? For example, why do you think j. is a primitive? This is exercise 8 in *Some Exercises in APL Language Design <http://www.jsoftware.com/papers/APLDesignExercises.htm>*. A possible answer is also included there. I don't know that that is _the_ answer in the context of J. Iverson designed it and I implemented it without discussion. (I should have asked him about it.) I think the j. function is one of those masterstrokes which separates a master from the rest of us.)
I don't think there is a simple answer to the first question above. I believe you have to consider the five "important characteristics of notation", found in *Notation as a Tool of Thought <http://www.jsoftware.com/papers/tot.htm>*. Note that non-redundancy is not included. On Sun, Oct 15, 2017 at 9:04 AM, Raul Miller <[email protected]> wrote: > It's interesting to note how J includes a fair bit of redundancy > > For example, we have - but we also have <: (which is -&1) and we have > -. (which is 1&-). Why do we have these? > > Primarily, for educational contexts. It can be useful when teaching > people to have specific words for commonly used operations. > > The underlying principle here, I think, is one of giving people > multiple perspectives when relaying a concept. I think the hope is > that at least some of it will "stick". > > But, also, for example, using -. for logical negation segues easily > into bayesian probability. There, we do not simply have 1 and 0 for > true and false, but we have a whole range of probabilities in between. > We can keep using -. for logical negation (it becomes the probability > of the event NOT happening), but we have to switch from *. to * for > combing events. > > If A and B are independent probability variables then A*B is the > probability that both are true. Similarly, if A and B are logical > variables, then A*B is true if and only if both A and B are true. We > can use * for logical AND. But the corresponding OR statement would be > *&.-. > > And J does not define that "bayesian OR" as a primitive, perhaps in > part to emphasize the need for understanding its derivation, perhaps > in part because it's only 5 characters already to get the > implementation and perhaps in part to emphasize the divide between > probability and logic. > > Anyways, without -. we would instead need *&.(1&-) which is just a bit > more unwieldy (but which, ok, would still work). > > Food for thought, perhaps... > > Thanks, > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
