I prefer index origin zero too. And I mentioned this discussion to my wife this morning she pointed out that 2d and 3d graphs always have an origin of zero. But when I first learned FORTRAN back in the stone age it only had index origin of one.
But when it comes down to it. Pick one. I don't care which. I can deal with it. Back to the PLI handling of indexing. Internally PLI kept dope vectors somewhat like the descriptors in APL and J. As such it was not necessary to pass the starting and ending indices for arrays to subroutines. A big improvement back then. On Fri, May 18, 2018 at 9:18 AM, Robert Bernecky <[email protected]> wrote: > I prefer 0=⎕io, especially for array arithmetic, because it works > well for mixed-radix indexing, which is essential for array operations. > As an implementor of functional array language processors (compilers > and interpreters), I do this sort of thing a lot, under the covers. > > Consider this nice identity, in which base value (#.) and representation > (#:) > are inverses, when we operate in origin zero: > > i. 8 > 0 1 2 3 4 5 6 7 > 2 #. 2 2 2 #: i. 8 > 0 1 2 3 4 5 6 7 > > Now, let's do it with origin one: > > 2 #. 2 2 2 #: 1 + i. 8 > 1 2 3 4 5 6 7 0 > > That's nice, except the expression is no longer an identity. For those who > don't care > about getting correct answers, this is fine. However, I have clients who > do care about such things. > > Now, back to FORTRAN/Fortran: An array can have an arbitrary index origin. > Worse yet, EACH array in a program can have its own, unique, index origin. > > Let's ignore mathematics for a moment, and contemplate how much > you would like to be handed a large system to maintain, > in which the author exercised this Awesome Power. It may be possible > to maintain, but it (a) is not fun, and (b) it introduces a rich set of > ways > to generate faulty programs. > > Not for me, thanks. > > Bob > > > > On 2018-05-18 10:40 AM, Don Guinn wrote: > >> If you look at the notation for vectors and matrices in mathematics the >> first element of a vector is written as V(1) and the upper left corner of >> a >> matrix is M(1,1). Having to use parens because I can't figure out how to >> put subscripts in e-mail. >> >> True, in summations of infinite series etc. the lower limit is chosen that >> makes the most sense and can be any value. But when the index has no >> significance except to choose elements of a vector or matrix it starts >> with >> one in the all math texts I can find. >> >> This may change as now that so many people program and are used to an >> index >> origin of zero. My point was not what the index origin should be when it >> is >> only used to locate a element. One works well as does zero. The mistake in >> APL was to duck the issue by allowing both making generalized indexing >> difficult. >> >> On Fri, May 18, 2018 at 5:19 AM, alexgian via Chat <[email protected]> >> wrote: >> >> OK, I'll give the questions a go, too, bearing in mind that I am not a >>> power user, just a J dilettante. >>> >>> >>> >>> How similar? - About as similar as Lua and Javascript :) !!! They may >>> look completely different on the surface and are used differently but the >>> underlying ideas and the paradigm (mindset required) are practically >>> identical. >>> >>> Re EBCDIC - Don't really know, but as someone (Don?) already said, EBCDIC >>> was no remedy in that case either. Anyways motivation-wise the character >>> set was probably quite low in priority. >>> >>> Can they do the same things? - Er hm, get the same results? Yes. The >>> same way? Not quite, only sometimes. Plus, I don't think APL has >>> implicit >>> functions. (Correct me if I'm wrong) >>> >>> Typing - You're kidding, right? >>> >>> OOP - No idea about modern APLs. J has a way of doing it, but every time >>> I tried using it I ended up swearing. Good job I don't do >>> programming-in-the-large in J. I'm sure you could get used to the system >>> though, just not sure if you would like it. Stick to Java if you want >>> traditional OOP, you could always call J from a library, I suppose. >>> >>> Supersets - Already answered I think. Once, perhaps. No more, due to >>> progress. >>> >>> Niche - Depends on your niche. I suspect their importance is quite high >>> in the refined realms of the big players, math quants and such. So >>> definitely not "niche" economically. >>> >>> >>> >>> I have to say, I mainly write in Clojure or Scheme but I often see the J >>> style of thinking creeping in. Which I like! >>> >>> >>> On 17 May 2018 at 04:27 jane dalley <[email protected]> wrote: >>>> >>>> >>>> This is my first post; my hope is this is an appropriate question. >>>> >>>> My knowledge of APL and J is very limited so my expectation is a simple >>>> >>> answer that is within my limited ability to grasp. >>> >>>> Examples: >>>> >>>> How similar are both APL and J? >>>> >>>> To the best of my recollection APL could be written with EBCDIC so why >>>> J? >>>> >>>> Can APL do everything J can do and visa versa? >>>> >>>> Can APL and J be forced to be strongly typed? >>>> >>>> Are APL and J capable of being Object Oriented like C++ or C#? >>>> >>>> Would one view J as a superset of APL? >>>> >>>> Are J and APL more than niche languages? >>>> >>>> Sorry if any of these questions are perceived to be offensive, probably >>>> >>> they have been asked many times before. >>> >>>> Sorry also if these questions are deemed silly such as a toddler might >>>> >>> ask. >>> >>>> Regards, >>>> >>>> Jane the novice of J >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>>> >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >>> >>> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > -- > Robert Bernecky > Snake Island Research Inc > 18 Fifth Street > Ward's Island > Toronto, Ontario M5J 2B9 > > [email protected] > tel: +1 416 203 0854 > text/cell: +1 416 996 4286 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
