I recall being astonished (circa 1974) to learn of the IBM product development group's approach to implementing BASIC regards index origin.
They had a similar discussion to the one here, and decided a simple solution would be that when a user declared a (row by col) array, simply set aside space for (row+1 by col+1) elements. Then the user's program would work with their origin of choice and have no clumsiness of origin declaration... I found it so amusing that I have no idea whether it had any supporters, or the people proposing it were laughed out of the room... > On 2018May 18, at 08:48, Don Guinn <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
