That would work in basic because index notation is the only way of accessing basic array elements.
Of course that would not solve off-by-one errors, but those are always problems. -- Raul On Fri, May 18, 2018 at 12:31 PM, Joey K Tuttle <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
