[TUHS] Array index history

[TUHS] Array index history

[shawn wilson]

I learned the other day that array indexes in some languages start at 1
instead of 0. This seems to be an old trend that changed around the 70s?
Who started this? Why was the change made?

It seems to have come about around the same time as C, but interestingly
enough Lua is kinda in between (you can start an array at 0 or 1).
Smalltalk can probably have a 0 base index just by it's nature, but I
wonder whether that would work in a 40 year old interpreter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170607/42b0c3ed/attachment.html>

[TUHS] Array index history

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

The original FORTRAN and BASIC arrays started indexing at one because everybody other than computer scientists start counting at 1.

These languages were for scientists and the beginner, so you wanted to make things compatible with their normal concepts.

PASCAL on the other hand required you to give the minimum and maximum index for the array.

 

It was an interesting concept when I got into computers in the early seventies that things would be numbered from zero.   Tape drive 0, TTY0, etc…

 

Of course, C’s half-assaed implementation of arrays kind of depends on zero-indexing to work.

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of shawn wilson
Sent: Wednesday, June 7, 2017 8:57 AM
To: The Eunuchs Hysterical Society
Subject: [TUHS] Array index history

 

I learned the other day that array indexes in some languages start at 1 instead of 0. This seems to be an old trend that changed around the 70s? Who started this? Why was the change made? 

 

It seems to have come about around the same time as C, but interestingly enough Lua is kinda in between (you can start an array at 0 or 1). Smalltalk can probably have a 0 base index just by it's nature, but I wonder whether that would work in a 40 year old interpreter. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170607/1c5da05c/attachment.html>

[TUHS] Array index history

[arnold]

shawn wilson <ag4ve.us at gmail.com> wrote:

> I learned the other day that array indexes in some languages start at 1
> instead of 0. This seems to be an old trend that changed around the 70s?
> Who started this? Why was the change made?
>
> It seems to have come about around the same time as C, but interestingly
> enough Lua is kinda in between (you can start an array at 0 or 1).
> Smalltalk can probably have a 0 base index just by it's nature, but I
> wonder whether that would work in a 40 year old interpreter.

Basically, until C came along, the standard practice was for indices
to start at 1. Certainly Fortran and Pascal did it that way. I suspect
that all the Algol family languages did too, but I only did a little
Algol W programming in colledge and that was long ago. I think Cobol also.

Pascal (IIRC) allowed you to specify upper and lower bounds, something
like

	foo : array[5..10] of integer;

with runtime bounds checking on array accesses.  (I could be wrong ---
it's been a LLLLOOONNNGGG time.)

HTH,

Arnold

[TUHS] Array index history

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

On 7 Jun 2017 07:20 -0600, from arnold at skeeve.com:
> Basically, until C came along, the standard practice was for indices
> to start at 1. Certainly Fortran and Pascal did it that way. I suspect
> that all the Algol family languages did too, but I only did a little
> Algol W programming in colledge and that was long ago. I think Cobol also.

On the other hand, before C, both B and BCPL used zero-based indexing.
So if we trace C's family tree, there is certainly precedence for
zero-based indexing into arrays.

https://www.bell-labs.com/usr/dmr/www/kbman.pdf page 8 (PDF page 10)
says:

> 7. A vector is a primary expression followed by any expression in []
> brackets. The two expressions are evaluated to rvalues, added and
> the result is used as an lvalue. The primary expression can be
> thought of as a pointer to the base of a vector, while the bracketed
> expression can be thought of as the offset in the vector. Since
> E1[E2] is identical to *(E1+E2), and addition is commutative, the
> base of the vector and teh offset in the vector can swap positions.

And https://www.bell-labs.com/usr/dmr/www/bcpl.pdf page 11 (PDF page
14) says:

> 4.7 Vector Applications
> /.../
> Semantics: A vector is represented by a pointer to a consecutive
> group of words which are the elements of the vector. The pointer
> points to the zeroth element.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Array index history

[arnold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Michael Kjörling <michael at kjorling.se> wrote:

> On the other hand, before C, both B and BCPL used zero-based indexing.
> So if we trace C's family tree, there is certainly precedence for
> zero-based indexing into arrays.

Ah. OK. I never used either language. I get the impression that BCPL
wasn't used / known much in the US, but I could be wrong. I was exposed
to BASIC and FORTRAN (and computer programming) circa 1976 and to C
in 1980.  Anything before then is before my time ... :-)

Thanks,

Arnold

[TUHS] Array index history

[Christian Neukirchen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

arnold at skeeve.com writes:

> Michael Kjörling <michael at kjorling.se> wrote:
>
>> On the other hand, before C, both B and BCPL used zero-based indexing.
>> So if we trace C's family tree, there is certainly precedence for
>> zero-based indexing into arrays.
>
> Ah. OK. I never used either language. I get the impression that BCPL
> wasn't used / known much in the US, but I could be wrong. I was exposed
> to BASIC and FORTRAN (and computer programming) circa 1976 and to C
> in 1980.  Anything before then is before my time ... :-)

It may be obvious, but awk(1) uses 1-indexing for arrays and string
offsets, and shell arguments are indexed from 1 too (which may be
reasonable given the special behavior of argv[0], but I think this
resulted in rc(1) being 1-indexed for lists).  pic(1) sensibly uses
1-indexing in the "Nth" notation.

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

[TUHS] Array index history

[shawn wilson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Jun 8, 2017 7:29 AM, "Christian Neukirchen" <chneukirchen at gmail.com>
wrote:

arnold at skeeve.com writes:

> Michael Kjörling <michael at kjorling.se> wrote:
>
>> On the other hand, before C, both B and BCPL used zero-based indexing.
>> So if we trace C's family tree, there is certainly precedence for
>> zero-based indexing into arrays.
>
> Ah. OK. I never used either language. I get the impression that BCPL
> wasn't used / known much in the US, but I could be wrong. I was exposed
> to BASIC and FORTRAN (and computer programming) circa 1976 and to C
> in 1980.  Anything before then is before my time ... :-)

It may be obvious, but awk(1) uses 1-indexing for arrays and string
offsets, and shell arguments are indexed from 1 too (which may be
reasonable given the special behavior of argv[0], but I think this
resulted in rc(1) being 1-indexed for lists).  pic(1) sensibly uses
1-indexing in the "Nth" notation.


I never thought of it like that wrt awk. However, I always thought of $0 as
"self" in higher level OO languages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/22a874e0/attachment.html>

[TUHS] Array index history

[Tony Finch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Michael Kjörling <michael at kjorling.se> wrote:
>
> And https://www.bell-labs.com/usr/dmr/www/bcpl.pdf page 11 (PDF page
> 14) says:
>
> > 4.7 Vector Applications
> > /.../
> > Semantics: A vector is represented by a pointer to a consecutive
> > group of words which are the elements of the vector. The pointer
> > points to the zeroth element.

That syntax is quite different from the later BCPL that I'm familiar with.
http://www.cl.cam.ac.uk/~mr10/bcplman.pdf

It has a ! indirection operator which can be both unary and binary, as in

	old BCPL	new BCPL	C

	lv x		@x		&x
	rv ptr		!ptr		*ptr
	ptr*[i]		ptr!i		ptr[i]

Richards' 1969 paper uses a down-arrow for binary !

You can use "manifest" constants for laying out a structure, e.g.

	MANIFEST { car; cdr; }

declares car and cdr to have values 0 and 1. This lets you do struct-style
indirection using the same operator as for array indexing, like in this
function definition:

	LET cadr(p) = p!cdr!car;

When I saw how ->integ is used in the 6th Edition kernel it felt very BCPL
to me.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: Cyclonic becoming southwest, 5 or 6. Moderate or rough. Rain.
Moderate or poor.

[TUHS] Array index history

[Dave Horsfall]

On Wed, 7 Jun 2017, Tony Finch wrote:

> You can use "manifest" constants for laying out a structure, e.g.
> 
> 	MANIFEST { car; cdr; }
> 
> declares car and cdr to have values 0 and 1. [...]

Which of course led to C's "enum" facility.
`
-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Array index history

[Lyndon Nerenberg]

> Basically, until C came along, the standard practice was for indices
> to start at 1. Certainly Fortran and Pascal did it that way. I suspect
> that all the Algol family languages did too, but I only did a little
> Algol W programming in colledge and that was long ago. I think Cobol also.

APL (excepting some early implementations) lets you set the "index origin" 
to either 0 or 1, either by assigning a value to the quad-IO system 
variable, or through the ')ORIGIN' command (varies with the 
implementation).

Changing quad-IO inside a function at runtime was a trick used to inflict 
endless terror on many a first-year undergrad ;-)

--lyndon

[TUHS] Array index history

[Bakul Shah]

On Wed, 07 Jun 2017 07:20:43 MDT arnold at skeeve.com wrote:
> 
> Basically, until C came along, the standard practice was for indices
> to start at 1. Certainly Fortran and Pascal did it that way.

Pascal's array type syntax is

    array-type: "array" "[" index-type "]" "of" type

Index type could be an integer sub-range or scalar type or
scalar sub-range. Pascal doesn't allow specifying array size
with a simple integer so the question of default index for
first element doesn't arise.

In spite of having learned and used Pascal, PL/I, Fortran and
APL before C, a lower bound of 0 seemed most sensible to me.
Not because of any efficiency reasons but because of modular
arithmetic which I learned before C!

[TUHS] Array index history

[Tim Bradshaw]

On 7 Jun 2017, at 13:56, shawn wilson <ag4ve.us at gmail.com> wrote:
> 
> I learned the other day that array indexes in some languages start at 1 instead of 0. This seems to be an old trend that changed around the 70s? Who started this? Why was the change made? 

I was going to make the obvious glib comment about languages which care more about some transient notion of efficiency than usability leading to 0-based indexing.

But I think in fact it must be cultural: FORTRAN was historically 1-based, of course, and although it looks like LISP 1 (1960) didn't have arrays, LISP 1.5 (1962) *did*, and they were 0-based.  It looks to me like ALGOL 58 allowed you to define lower & upper bounds, based on http://www.softwarepreservation.org/projects/ALGOL/report/Algol58_preliminary_report_CACM.pdf/view

So I suspect that languages designed by and for people who actually did a lot of numerical matrix manipulation (ie applied mathematicians, physicists &c) used the conventions of those fields, which were and are 1-based indexing; languages designed by & for formal CS people tended to use zero-based, and languages designed by people who were feeling their oats as regards flexibility allowed user-defined bounds.

--tim

[TUHS] Array index history

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Wed, Jun 7, 2017 at 8:56 AM, shawn wilson <ag4ve.us at gmail.com> wrote:

> I learned the other day that array indexes in some languages start at 1
> instead of 0. This seems to be an old trend that changed around the 70s?
> Who started this? Why was the change made?

​Tastes Change -- but I really think its more "things happen" is the short
answer.

The longer answer really comes from what you were comfortable.    As has
been pointed at the 'engineers' and US types that grew up in the world of
Fortran and Basic in the 50s, and 60s had used 1.   Which made perfect
sense for them.   Certainly has my father was taught and how he taught me
in the sixties.   However, the 'formal' mathematician and Europeans types
from the Algol world ​tended to think 'normal' in terms of counting from 0
like the HW did during the same time period.

By the late 60s, early 70th, as has been pointed out, some languages
started to offer some choice.   I remember different professors at CMU
having different views what was better - and clearly it was a matter of
taste.   But most took a view of what was most important was to keep *to
local custom and convention *as the SW engineering rule* of 'least
amazement' *needed to be high bit.

I think the more interesting note is that Ken has gone on record to state
he set out to create a Fortran compiler when he created B.  So it is an
interesting question of why B (and C) ended up with the BCPL (Algol)
convention of 0 based addresses not the Fortran 1 based?    But I actually
think the 'zero-ness' of today, we have is less to do with 'Algol-like'
(Pascal et al) winning and being 'better'  than it was that C ended up as
the dominant language and for whatever reason Ken picked zero based
addressing - probably >>I'll guess<< because he was staying close to the HW.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170607/14f6918a/attachment.html>

[TUHS] Array index history

[Arthur Krewat]

If you think of an array as a memory area of bytes, words, whatever, the 
simple way to deal with it is the index being 0 is the first in the array.

Why go to the trouble of decrementing the index to retreive the first 
entry?

ALGOL did indeed have arrays with bounds:

INTEGER ARRAY K,L[0:10,0:10];

Two arrays, K and L with 0 first, 10 last. Total of 11 elements.

Of course, it's a "higher level" language than C. My thinking on the 
subject is that C is very close to assembler, so if you're using for 
example Intel X86 instructions:

MOV SI,1
MOV AL,[SI + ARRAY1]                        ; retrieve the SECOND 
element (byte)

Likewise, for words, just left-shift SI one bit.

For me having started out in assembler (actually, MACRO-10 on a PDP-10), 
it's intuitive as to why/how C does arrays.

ak

[TUHS] Array index history

[Ron Natalie]

> Why go to the trouble of decrementing the index to retreive the first entry?

What makes you think that you have to decrement the index.    Don't get sucked up in the idiotic C implementation of an array.   Arrays can be efficiently implemented no matter where the index starts.

[TUHS] Array index history

[Arthur Krewat]

On 6/7/2017 3:03 PM, Ron Natalie wrote:
>> Why go to the trouble of decrementing the index to retreive the first entry?
> What makes you think that you have to decrement the index.    Don't get sucked up in the idiotic C implementation of an array.   Arrays can be efficiently implemented no matter where the index starts.
>
>
In the days when memory and clock cycles were costly, an extra decrement 
or subtract was not something to be taken lightly :)

On the other hand, I can see that you could solve this in the 
preprocessor. In my example, just make it:

MOV AL, [SI + (ARRAY1 - FIRSTELEMENT)]

And let the assembler deal with it.

Still, there's something oddly "artificial" about that, again from the 
machine language point of view. There's nothing "idiotic" about it IMHO. 
It's just the way processors actually work.

Of course, if you're really into abstraction, well, to each his own :)

ak

[TUHS] Array index history

[Ron Natalie]

The memory storage location and the first element offset are effectively constants, you can remove them from the equation.

[TUHS] Array index history

[ARJANEN Loïc Jean David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Le jeudi 8 juin 2017, Arthur Krewat <krewat at kilonet.net> a écrit :

> On 6/7/2017 3:03 PM, Ron Natalie wrote:
>
>> Why go to the trouble of decrementing the index to retreive the first
>>> entry?
>>>
>> What makes you think that you have to decrement the index.    Don't get
>> sucked up in the idiotic C implementation of an array.   Arrays can be
>> efficiently implemented no matter where the index starts.
>>
>>
>> In the days when memory and clock cycles were costly, an extra decrement
> or subtract was not something to be taken lightly :)
>

I doubt that avoiding a decrement was really the reason. I mean, it's an
array: if you're 0-basing it you're still paying a decrement but for bounds
checking this time. Keeping as close as possible to how the target machine
worked or following a convention in another hand, that I can see.

Loïc


-- 
ARJANEN Loïc Jean David
http://blog.luigiscorner.com
---
“Computer science is no more about computers than astronomy is about
telescopes, biology is about microscopes, or chemistry is about beakers and
test tubes. Science is not about tools. It is about how we use them, and
what we find out when we do.”
Michael R. Fellows and Ian Parberry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/ed8bc2da/attachment.html>

[TUHS] Array index history

[Random832]

On Wed, Jun 7, 2017, at 15:15, Arthur Krewat wrote:
> On 6/7/2017 3:03 PM, Ron Natalie wrote:
> >> Why go to the trouble of decrementing the index to retreive the first entry?
> > What makes you think that you have to decrement the index.    Don't get sucked up in the idiotic C implementation of an array.   Arrays can be efficiently implemented no matter where the index starts.
>
> In the days when memory and clock cycles were costly, an extra decrement 
> or subtract was not something to be taken lightly :)

You wouldn't need a decrement per access, because the base itself could
still be stored as the address of the "0th" element (i.e. what would be
the "-1th" in a 0-based system). It might add some extra complexity to
the relocator, if it's not currently possible to have a reference
outside the bounds of an object and/or with a negative offset, but
statically linked programs (the only kind on V7 and earlier) did not do
any runtime relocation.

[TUHS] Array index history

[Arthur Krewat]

On 6/8/2017 9:49 AM, Random832 wrote:
> On Wed, Jun 7, 2017, at 15:15, Arthur Krewat wrote:
>> In the days when memory and clock cycles were costly, an extra decrement
>> or subtract was not something to be taken lightly :)
> You wouldn't need a decrement per access, because the base itself could
> still be stored as the address of the "0th" element (i.e. what would be
> the "-1th" in a 0-based system). It might add some extra complexity to
> the relocator, if it's not currently possible to have a reference
> outside the bounds of an object and/or with a negative offset, but
> statically linked programs (the only kind on V7 and earlier) did not do
> any runtime relocation.
>

Shortly after making that statement, it occurred to me that the 
preprocessor or assembler could take care of that easily.

Even better than worrying about whether arrays started at 0 or 1 in C 
would be to institute bounds checking in the first place :) But again 
would add lots of extra code that in the days of the origins of C was 
not something you wanted to add to the memory footprint.

[TUHS] Array index history

[Tim Bradshaw]

> On 7 Jun 2017, at 20:15, Arthur Krewat <krewat at kilonet.net> wrote:
> 
> In the days when memory and clock cycles were costly, an extra decrement or subtract was not something to be taken lightly :)

Indeed they weren't, and that's how we know that 1-based indexing doesn't require any overhead given a reasonably good compiler.  If you'd gone to people writing big CFD simulations in 1975 and told them that by using a version of FORTRAN which had 0-based arrays they could save any significant runtime at all then they would have changed to it without a thought.  But they didn't.

[TUHS] Array index history

[Robert Swierczek]

>
> Arrays can be efficiently implemented no matter where the index starts.
>

Keep in mind that C was/is primarily a language to write OS's and
other system level software.  Hardware such as memory addresses, page
tables, disk sectors, etc. are all indexed from zero for very good
reasons.  I would shudder to contemplate an implementation of the Unix
V6 kernel in a hypothetical C-with-one-based-arrays language.

[TUHS] Array index history

[Dave Horsfall]

On Wed, 7 Jun 2017, Robert Swierczek wrote:

> Keep in mind that C was/is primarily a language to write OS's and other 
> system level software.  Hardware such as memory addresses, page tables, 
> disk sectors, etc. are all indexed from zero for very good reasons.  I 
> would shudder to contemplate an implementation of the Unix V6 kernel in 
> a hypothetical C-with-one-based-arrays language.

Weren't the Burroughs mainframes implemented in Algol, likely with a 
1-origin?  Of course, I could be wrong (it was quite a few years ago since 
I touched a B-1700)...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Array index history

[Peter Jeremy]

On 2017-Jun-07 22:45:08 -0400, Robert Swierczek <rmswierczek at gmail.com> wrote:
>Keep in mind that C was/is primarily a language to write OS's and
>other system level software.  Hardware such as memory addresses, page
>tables, disk sectors, etc. are all indexed from zero for very good
>reasons.  I would shudder to contemplate an implementation of the Unix
>V6 kernel in a hypothetical C-with-one-based-arrays language.

Two counter-examples
1) CHS numbers sectors starting from 1, not 0.
2) Pr1meOS was written in Fortran. 

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/f0a81b6b/attachment.sig>

[TUHS] Array index history

[Dave Horsfall]

On Thu, 8 Jun 2017, Peter Jeremy wrote:

> Two counter-examples
> 1) CHS numbers sectors starting from 1, not 0.

Ah, those were the days, writing drivers for RK-11s etc...

> 2) Pr1meOS was written in Fortran. 

Ironic, really, considering that "1" is not prime :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Array index history

[Ron Natalie]

Original PR1MEOS was a weird beast.   Not just Fortran, but FortranIV which
is beyond the array index issues is far from a language I'd want to have to
build a lot of low level contructs in.   No structured aspects of it at all
(indeed, this was the impetus for RATFOR, though I don't think Prime ever
saw it).    They didn't stay with Fortran long.   They wrote their own PL/1
variant called PL/P a scheme also implemented at UNIVAC (PLUS) and IBM
(PL/S).    I would venture that C was the only systems implementation
language that made the leap into a general purpose language.

[TUHS] Array index history

[Doug McIlroy]

>  Who started this? Why was the change made?

Arrays in Fortran and Algol were indexed from 1 by default, but
Algol (IIRC) generalized that to allow first:last declarations. 
NPL used first,last for the SUBSTR operation. But first,last 
begets off-by-one errors. The successor slice begins at last+1.
The formula for the position of 1-indexed a[i,j] is a mess.
First,length is much cleaner: the successor begins at
first+length. I convinced the committee of that, so when
NPL became PL/I, first,length was the convention. Zero-
indexing is also a clean first,length notation. BCPL,
where a[i] was synonymous with rv(a+i), had it. Dennis, who
knew a good thing when he saw it, took it over. Dijkstra,
too, often inveighed against 1-indexing, and opined that
zero was the true computer-science way. 

1-indexing certainly came into programming languages from
the math tradition for matrix notation. Of course in
math series are often indexed from zero, so one may
pick and choose. Off hand I can only think of one CS
context where 1 comes in handy: heapsort.

Doug

[TUHS] Array index history

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

When he tests a microphone, Don Knuth says:

“Testing zero, one, two.”

> On 7Jun 2017, at 10:27 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> Dijkstra,
> too, often inveighed against 1-indexing, and opined that
> zero was the true computer-science way. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/2d36f742/attachment.html>

[TUHS] Array index history

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick):
> When he tests a microphone, Don Knuth says:
> 
> “Testing zero, one, two.”

As opposed to Niklaus Wirth, who presumably would rather say:

"Testing lower bound, lower bound plus one, lower bound plus two."

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Array index history

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Thu, Jun 8, 2017 at 8:56 AM, Michael Kjörling <michael at kjorling.se>
wrote:

> On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick):
> > When he tests a microphone, Don Knuth says:
> >
> > “Testing zero, one, two.”
>
> As opposed to Niklaus Wirth, who presumably would rather say:
>
> "Testing lower bound, lower bound plus one, lower bound plus two."


"Testing: the set N, defined so that there are some elements 'b' and 'e' in
N with known values taken from the integers and such that b less than or
equal 'e' and every other element is both the natural successor of an
element in N and less than or equal to 'e'."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/7b311e3f/attachment.html>

[TUHS] Array index history

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

My other favorite Wirth joke (I believe he coined himself) plays fun with the pronunciation of his name:

You can call me by name… VEERTH or by value… WORTH.

 

 

From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dan Cross
Sent: Thursday, June 8, 2017 9:46 AM
To: Michael Kjörling
Cc: TUHS main list
Subject: Re: [TUHS] Array index history

 

On Thu, Jun 8, 2017 at 8:56 AM, Michael Kjörling <michael at kjorling.se> wrote:

On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick):
> When he tests a microphone, Don Knuth says:
>
> “Testing zero, one, two.”

As opposed to Niklaus Wirth, who presumably would rather say:

"Testing lower bound, lower bound plus one, lower bound plus two."

 

"Testing: the set N, defined so that there are some elements 'b' and 'e' in N with known values taken from the integers and such that b less than or equal 'e' and every other element is both the natural successor of an element in N and less than or equal to 'e'."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170608/9946b599/attachment-0001.html>

[TUHS] Array index history

[Nemo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On 08/06/2017, Michael Kjörling <michael at kjorling.se> wrote:
> On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick):
>> When he tests a microphone, Don Knuth says:
>>
>> “Testing zero, one, two.”
>
> As opposed to Niklaus Wirth, who presumably would rather say:
>
> "Testing lower bound, lower bound plus one, lower bound plus two."

In his latest language Oberon, all arrays start at zero.

N.

[TUHS] Array index history

[Dave Horsfall]

Just to diverge from this thread a little, it probably isn't all that 
remarkable that programming languages tend to reflect the hardware for 
which they were designed.

Thus, for example, we have the C construct:

    do { ... } while (--i);

which translated right into the PDP-11's "SOB" instruction (and 
reminiscent of FORTRAN's insistence that DO loops are run at least once 
(there was a CACM article about that once; anyone have a pointer to it?)).

And of course the afore-mentioned FORTRAN, which really reflects the 
underlying IBM 70x architecture (shudder).

I know that Burroughs' iron ran ALGOL; I shudder to think of any box that 
runs native PERL...

Speaking of Burroughs (which we weren't), their OS was MCP (Master Control 
Program) which we the great unwashed called Male Chauvinist Pig, no doubt 
to their distress :-)  Any other examples of poor acronyms designed by 
ignorant marketoids?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Array index history

[William Pechter]

DEC Professional Operating System POS. 

Great acronym there...  

-----Original Message----

Speaking of Burroughs (which we weren't), their OS was MCP (Master Control 
Program) which we the great unwashed called Male Chauvinist Pig, no doubt 
to their distress :-)  Any other examples of poor acronyms designed by 
ignorant marketoids?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Array index history

[Steve Nickolas]

On Fri, 9 Jun 2017, Dave Horsfall wrote:

> Speaking of Burroughs (which we weren't), their OS was MCP (Master Control
> Program) which we the great unwashed called Male Chauvinist Pig, no doubt
> to their distress :-)  Any other examples of poor acronyms designed by
> ignorant marketoids?

Apple had SOS.

-uso.

[TUHS] Array index history

[Larry McVoy]

> I know that Burroughs' iron ran ALGOL; I shudder to think of any box that 
> runs native PERL...

Huh?  If I couldn't have C on the iron I'd be ecstatic with perl 4 (I'm old,
never warmed up to perl 5).  

In fact, while I was at Sun I proposed rewriting a pile of /usr/bin in
perl 4 just because it would be more maintainable.  I did walk that back
at some point but I love me some perl.

I've moved on because I created my own C/perl combo language and that's
what I do most of my programming in these days.

http://mcvoy.com/lm/photos.l

is an example.  I'm in Europe right now, you can see the results of photos.l
here (warning ~8MB of thumbnails):

http://mcvoy.com/lm/europe

I'm very fond of that language, it's like a scripting version of C,
has structs, but has all the fun stuff from perl.

Docs here:

http://www.mcvoy.com/lm/L/L.html

[TUHS] Array index history

[Greg 'groggy' Lehey]

On Friday,  9 June 2017 at  1:04:39 +1000, Dave Horsfall wrote:
>
> And of course the afore-mentioned FORTRAN, which really reflects the
> underlying IBM 70x architecture (shudder).

I had promised myself that I wouldn't get involved in this thread, but
I had to step in here.

Yes, the IBM 704 had the CAS instruction (Compare Accumulator with
Storage), a three-way skip instruction that easily implemented the
FORTRAN Arithmetic IF.  But the "index" registers were correctly
called decrement registers: their content was subtracted from the base
address.  I assume that this was because the 704 was a ones-complement
machine whose basic arithmetic operation was subtraction, so this was
cheaper than adding the registers to the base address.

To implement indexing with the base 704 hardware, FORTRAN would have
had to have an upper bound of -0 (remember that number?).

Still, there were three decrement registers, and the original FORTRAN
was limited to three dimensions, evidently as a result.

> Speaking of Burroughs (which we weren't), their OS was MCP (Master
> Control Program) which we the great unwashed called Male Chauvinist
> Pig, no doubt to their distress :-)

This name (the original one) cropped up again in the 1982 film "Tron"
(http://www.imdb.com/title/tt0084827/).  It was singularly
inappropriate.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170609/8e5952a9/attachment.sig>

[TUHS] Array index history

[Richard Tobin]

> Basically, until C came along, the standard practice was for indices
> to start at 1. Certainly Fortran and Pascal did it that way.

Mercury Autocode used 0.

  http://www.homepages.ed.ac.uk/jwp/history/mercury/manual/autocode/4.jpg

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[TUHS] Array index history

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

Arnold gets it right on the Pascal indexing.

In UCSD Pascal you could specify any array bounds you would like and
the compiler would 0 base them for you by always doing a subtraction,
or addition if your min was negative, of your min array index. So a little
run time cost for non-zero based arrays.

I’m not sure how other Pascal compilers did this.

I find it interesting that there are now a slew of testing programs
(Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’
array bounds checking for C.

	David

> On Jun 7, 2017, at 10:01 AM, tuhs-request at minnie.tuhs.org wrote:
> 
> Date: Wed, 07 Jun 2017 07:20:43 -0600
> From: arnold at skeeve.com
> To: tuhs at tuhs.org, ag4ve.us at gmail.com
> Subject: Re: [TUHS] Array index history
> Message-ID: <201706071320.v57DKhmJ026303 at freefriends.org>
> Content-Type: text/plain; charset=us-ascii
> 
> Pascal (IIRC) allowed you to specify upper and lower bounds, something
> like
> 
> 	foo : array[5..10] of integer;
> 
> with runtime bounds checking on array accesses.  (I could be wrong ---
> it's been a LLLLOOONNNGGG time.)
> 
> HTH,
> 
> Arnold

[TUHS] Array index history

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

=

> I find it interesting that there are now a slew of testing programs (Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’
> array bounds checking for C.

And nothing prevents a C compiler from doing bounds checking, it's just not obliged to.   There are C compilers that will allow you to enable such checks for debugging purposes.

[TUHS] Array index history

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3875 bytes --]

I'd like to comment on the technical difficulty of array bounds
checking.   First of all, there are two kinds.   The simple kind
computes the index and simply checks that the address is within the
array.  This can be done fairly easily -- create a pointer to the end
of the array, and test against it (and with a bit more work,
"pre-test" loops so you don't need to test each element).  If you
ignore possible negative subscripts, it's even easier.  And it
catches a lot of the ugliest bugs.  The harder version checks the
range of each index in a multidimensional array separately.  This is
quite a bit more work, although it too can be optimized significantly
with enough work.  And if C didn't conflate arrays and pointers, I
suspect this would have been added to C long ago.

But C does conflate arrays and pointers.   When an array is passed
to a function, all that is passed is the location.  There is no clue
what the size is.  To even pass in the "end of array" pointer gets
expensive, since more registers need to be saved and loaded on each
call.  Correct negative subscripts are not unheard of when passing
part of an array into a functions.  And utilities like malloc get
more complicated as well, and for some of malloc's other uses (e.g.,
in class object creation) the checks would be inappropriate.  And
finally, because pointers are extensively used in data structures,
pointer conventions are often used when using arrays (e.g., passing in
NULL when an array argument is not present or needed).

There is yet another problem.  If array size or shape information
were somehow passed with arrays, it would be unkind for the language
to give the programmer no way to find out what the size(s) are.  This
desire ultimately leads to a rich calling convention like that of
MATLAB where you can have multiple function outputs, determine how
many inputs are present, and inputs will disclose their size and shape
on request.  Good to program in, but function calls are quite a bit
more expensive.

Realizing that most system code at the time of C's invention was still
written in assembler and PDP-11's were almost too small in memory to
do anything interesting (my laptop currently has roughly 243,000 times
the memory space of a PDP-11!), C's conventions provided a big
improvement in code correctness with a small cost when compared to
assembler... 

Steve

----- Original Message -----
From: david@kdbarto.org
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Thu, 8 Jun 2017 11:20:24 -0700
Subject:Re: [TUHS] Array index history

 Arnold gets it right on the Pascal indexing.

 In UCSD Pascal you could specify any array bounds you would like and
 the compiler would 0 base them for you by always doing a subtraction,
 or addition if your min was negative, of your min array index. So a
little
 run time cost for non-zero based arrays.

 I’m not sure how other Pascal compilers did this.

 I find it interesting that there are now a slew of testing programs
 (Valgrind, Address Sanitizer, Purify, etc) that will add the
‘missing’
 array bounds checking for C.

 David

 > On Jun 7, 2017, at 10:01 AM, tuhs-request at minnie.tuhs.org wrote:
 > 
 > Date: Wed, 07 Jun 2017 07:20:43 -0600
 > From: arnold at skeeve.com
 > To: tuhs at tuhs.org, ag4ve.us at gmail.com
 > Subject: Re: [TUHS] Array index history
 > Message-ID: <201706071320.v57DKhmJ026303 at freefriends.org>
 > Content-Type: text/plain; charset=us-ascii
 > 
 > Pascal (IIRC) allowed you to specify upper and lower bounds,
something
 > like
 > 
 > foo : array[5..10] of integer;
 > 
 > with runtime bounds checking on array accesses. (I could be wrong
---
 > it's been a LLLLOOONNNGGG time.)
 > 
 > HTH,
 > 
 > Arnold


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170609/2cd98147/attachment.html>

[TUHS] Array index history

[Arthur Krewat]

On 6/9/2017 5:21 PM, Steve Johnson wrote:
> C's conventions provided a big improvement in code correctness with a 
> small cost when compared to assembler..

Being an assembler snob for a number of years when I first started 
programming, having started with MACRO-10 on a PDP-10 in high school, I 
was reluctant to consider C as an alternative.

At one point early on, I decided I would see what the difference was in 
actual performance. So, on an IBM-AT, I wrote two programs. Both did a 
wire-frame rotation of a 3D cube, rotating around both the X and Y axis. 
They both used my own graphics library written in assembler that used 
the basic BIOS graphics calls to draw lines in 3D.

One program was written in straight Intel 80286 assembler. The other, in 
C, C86 from Computer Innovations, Inc.

The straight assembler version, I wrote using double-word integers. One 
word for everything above the decimal point, one word for everything 
below the decimal point. Now, because of the loss of precision, and that 
I defined the matrices for rotation as static integers, after a few 
hundred iterations, the cube would start to deform but it was a proof of 
concept.

The C version, I used real sin(), cos(), but - the interesting part is 
that I didn't have a floating point coprocessor - so the floating point 
was emulated in the supplied math library.

The assembler version ran at a ratio of 3:4 compared to the C 
version.Meaning if the assembler version did X rotations in 3 minutes, 
the C version did it in 4 minutes. BUT - the C version cube didn't 
deform over time, because the accuracy was intact.

After that, I gave up on assembler except where critical. C as a concept 
did what I needed it to do ;)

On topic for this conversation is the fact that arrays in C are 
basically a perfect mapping to assembler. if you moved from assembler to 
C like I did, there was no concern over "arrays should start at 1". It 
was just intuitive anyway.

On the other hand, if you went from some other language to C, well, I 
can understand the alien-ness.

art k.

[TUHS] Array index history

[Johnny Billquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On 2017-06-07 19:01, "Ron Natalie"<ron at ronnatalie.com> wrote:
> The original FORTRAN and BASIC arrays started indexing at one because everybody other than computer scientists start counting at 1.

FORTRAN, yes. BASIC (which dialect might we be talking about?) normally 
actually start with 0. However, BASIC is weird, in that the DIM 
statement is actually specifying the highest usable index, and not the 
size of the array.

Thus:

DIM X(10)

means you get an array with 11 elements. So, people who wanted to use 
array starting at 1 would still be happy, and if you wanted to start at 
0, that also worked. You might unintentionally have a bit of wasted 
memory, though.

> These languages were for scientists and the beginner, so you wanted to make things compatible with their normal concepts.

True.

> PASCAL on the other hand required you to give the minimum and maximum index for the array.

In a way, PASCAL makes the most sense. You still what range you want, 
and you get that. Anything works, and it's up to you.
That said, PASCAL could get a bit ugly when passing arrays as arguments 
to functions because of this.

> Of course, C’s half-assaed implementation of arrays kind of depends on zero-indexing to work.

:-)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] Array index history

[Ron Natalie]

> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally
actually start with 0. However, BASIC is weird, in that the DIM statement is
actually specifying the highest usable index, and not the size of the array.

Eh?  Not in any BASIC I ever used.   They all started at 1.   Can't vouch
for the later Microsoft "visual" variants but the original 1970's era BASIC
started with 1.
DIM X(10) gave you ten elements from 1...10

[TUHS] Array index history

[Steve Nickolas]

On Thu, 8 Jun 2017, Ron Natalie wrote:

>
>> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally
> actually start with 0. However, BASIC is weird, in that the DIM statement is
> actually specifying the highest usable index, and not the size of the array.
>
> Eh?  Not in any BASIC I ever used.   They all started at 1.   Can't vouch
> for the later Microsoft "visual" variants but the original 1970's era BASIC
> started with 1.
> DIM X(10) gave you ten elements from 1...10

All M$ dialects that I am aware of start at 0 by default.  Later ones have 
OPTION BASE to change this or let you do DIM X(5 TO 7) if you want.

-uso.

[TUHS] Array index history

[Random832]

On Thu, Jun 8, 2017, at 19:41, Steve Nickolas wrote:
> On Thu, 8 Jun 2017, Ron Natalie wrote:
> > DIM X(10) gave you ten elements from 1...10
> 
> All M$ dialects that I am aware of start at 0 by default.

In fact, they give you eleven elements from 0 to 10, which means that
code which *uses* 1..10 is compatible but wastes some space.

[TUHS] Array index history

[Ron Natalie]

I stand corrected.   I pulled up the original typewritten Dartmouth BASIC manual and indeed the indices start at zero (though many coding examples don't write the zeroth element).   By default arrays were 11 elements long.   You could change that with the DIM statement.   Yes, the value given to DIM is the highest index making a DIM A(20) defining a 21 element array.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Random832
Sent: Friday, June 9, 2017 11:12 AM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Array index history

On Thu, Jun 8, 2017, at 19:41, Steve Nickolas wrote:
> On Thu, 8 Jun 2017, Ron Natalie wrote:
> > DIM X(10) gave you ten elements from 1...10
> 
> All M$ dialects that I am aware of start at 0 by default.

In fact, they give you eleven elements from 0 to 10, which means that code which *uses* 1..10 is compatible but wastes some space.

[TUHS] Array index history

[Johnny Billquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

All variants of BASIC by DEC does this. A few others I've tried also do. But since BASIC was not standardized for the longest time, it's hard to claim that BASIC really was one way or another. I have definitely not tried every dialect that has existed.

  Johnny 


Ron Natalie <ron at ronnatalie.com> skrev: (9 juni 2017 01:16:48 CEST)
>
>> FORTRAN, yes. BASIC (which dialect might we be talking about?)
>normally
>actually start with 0. However, BASIC is weird, in that the DIM
>statement is
>actually specifying the highest usable index, and not the size of the
>array.
>
>Eh?  Not in any BASIC I ever used.   They all started at 1.   Can't
>vouch
>for the later Microsoft "visual" variants but the original 1970's era
>BASIC
>started with 1.
>DIM X(10) gave you ten elements from 1...10

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170609/4064e9af/attachment.html>

[TUHS] Array index history

[Pete Turnbull]

On 09/06/2017 00:16, Ron Natalie wrote:
> 
>> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally
> actually start with 0. However, BASIC is weird, in that the DIM statement is
> actually specifying the highest usable index, and not the size of the array.
> 
> Eh?  Not in any BASIC I ever used.   They all started at 1.   Can't vouch
> for the later Microsoft "visual" variants but the original 1970's era BASIC
> started with 1.
> DIM X(10) gave you ten elements from 1...10

Well, my experience matches Johnny's.  I used many derivatives of 
MicroSoft BASIC - PET, Apple INTBASIC, Applesoft, Exidy Sorcerer, and 
others - and they all start at 0.  AFAIR HP BASIC did so as well.  The 
original 1960s Dartmouth BASIC (for which I have a copy of the manual) 
also started at 0 (cf. page 38); indeed if you didn't explicitly DIM an 
array, you got eleven elements indexed 0...10.

-- 
Pete
Pete Turnbull

[TUHS] Array index history

[Toby Thain]

On 2017-06-08 8:25 PM, Pete Turnbull wrote:
> On 09/06/2017 00:16, Ron Natalie wrote:
>>
>>> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally
>> actually start with 0. However, BASIC is weird, in that the DIM
>> statement is
>> actually specifying the highest usable index, and not the size of the
>> array.
>>
>> Eh?  Not in any BASIC I ever used.   They all started at 1.   Can't vouch
>> for the later Microsoft "visual" variants but the original 1970's era
>> BASIC
>> started with 1.
>> DIM X(10) gave you ten elements from 1...10
>
> Well, my experience matches Johnny's.  I used many derivatives of
> MicroSoft BASIC - PET, Apple INTBASIC, Applesoft, Exidy Sorcerer, and
> others - and they all start at 0.  AFAIR HP BASIC did so as well.  The
> original 1960s Dartmouth BASIC (for which I have a copy of the manual)
> also started at 0 (cf. page 38); indeed if you didn't explicitly DIM an
> array, you got eleven elements indexed 0...10.
>

I wrote a lot of BBC BASIC. DIM(9) allocates ten elements, 0..9, 
according to this:

http://www.riscos.com/support/developers/bbcbasic/part2/arrays.html

--Toby

[TUHS] Array index history

[Pete Turnbull]

On 09/06/2017 02:19, Toby Thain wrote:
> I wrote a lot of BBC BASIC. DIM(9) allocates ten elements, 0..9, 

Yes, all versions (of which there are at least nine, going back to 
1981), and so too does its predecessor, Atom BASIC.  Indexing from zero 
was the norm in 1970s/1980s BASICs.

-- 
Pete
Pete Turnbull

[TUHS] Array index history

[Johnny Billquist]

On 2017-06-08 22:17, Dave Horsfall<dave at horsfall.org> wrote:
> 
> Just to diverge from this thread a little, it probably isn't all that
> remarkable that programming languages tend to reflect the hardware for
> which they were designed.
> 
> Thus, for example, we have the C construct:
> 
>      do { ... } while (--i);
> 
> which translated right into the PDP-11's "SOB" instruction (and
> reminiscent of FORTRAN's insistence that DO loops are run at least once
> (there was a CACM article about that once; anyone have a pointer to it?)).
> 
> And of course the afore-mentioned FORTRAN, which really reflects the
> underlying IBM 70x architecture (shudder).

FORTRAN stopped running the loops at least once already with FORTRAN 77. 
The last who insisted on running loops at least once was FORTRAN IV.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol