Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

false == 2 ??

 [1/66] from: gchiu::compkarori::co::nz at: 2-Jul-2001 13:41


Why does this happen?
>> pick [ 1 2 ] true
== 1
>> pick [ 1 2 ] false
== 2
>> pick [ 1 2 3 ] false
== 2 -- Graham Chiu

 [2/66] from: agem:crosswinds at: 2-Jul-2001 5:27


RE: [REBOL] false == 2 ?? [gchiu--compkarori--co--nz] wrote:
> Why does this happen? > >> pick [ 1 2 ] true
<<quoted lines omitted: 3>>
> >> pick [ 1 2 3 ] false > == 2
was somewhere on the list while ago. IIRC either true[true-part][false-part] pick [ true-part false-part] true Carls part of last Zine used in in that way to press ~5 in one line :)
> -- > Graham Chiu
;-) Volker

 [3/66] from: gchiu:compkarori at: 2-Jul-2001 15:39


On Mon, 2 Jul 2001 5:27:46 +0200 [agem--crosswinds--net] wrote:
> Carls part of last Zine used in in that way > to press ~5 in one line :) >
Okay, I see it. It's one of those forth methods to shorten code - replacing logic with maths. But just wondering why false isn't 0 instead of 2! I guess pick [... ] 0 isn't very helpful :-) -- Graham Chiu

 [4/66] from: robert:lancaster:opennw at: 2-Jul-2001 15:47


Hmmmmm....
>> to-integer TRUE
== 1
>> to-integer FALSE
== 0

 [5/66] from: larry:ecotope at: 1-Jul-2001 21:05


Hi Graham, Volker, Robert
>> help pick
USAGE: PICK series index DESCRIPTION: Returns the value at the specified position in a series. PICK is an action value. ARGUMENTS: series -- (Type: series pair event money date time object port tuple any-function) index -- (Type: number logic) So PICK is an action. Actions are polymorphic functions that can have very different effects depending on the datatype of the arguments. PICK takes a number or a logic arg. If the arg is a number it is used as an index into the series arg. If it is a logic value, it returns the first element for true and the second element for false.
>> pick [545 676 828] true
== 545
>> pick [545 676 828] false
== 676 There is no connection with any numeric value associated with true and false. As Robert mentioned,
>> to-integer true
== 1
>> to-integer false
== 0 Also
>> to-logic 0
== false
>> to-logic -123.5
== true
>> to-logic 123.5
== true So to-logic returns false for 0 or 0.0 and returns true for all other numbers. Cheers -Larry

 [6/66] from: brett:codeconscious at: 2-Jul-2001 14:06


Hi Graham, The help on Pick says that it accepts number! and logic! types for the index value. So when given a logic! type for an index, pick's behaviour is simply to choose the first value in the series when the index is true, otherwise choose the second. No conversions to number are necessary. Therefore pick [...] false does not imply that false = 2. HTH! Brett.

 [7/66] from: joel:neely:fedex at: 1-Jul-2001 18:52


Hi, Graham, This is just one of those "stumbling blocks" where there's nothing to do but memorize the exception. Graham Chiu wrote:
> Okay, I see it. It's one of those forth methods to shorten > code - replacing logic with maths. > > But just wondering why false isn't 0 instead of 2! >
As you correctly pointed out, consistency in identifying FALSE with 0 would have created problems, due to the fact that The Powers That Be decided that series positions shall begin with one, rather than zero. In case anyone is tempted to claim that this is for the convenience of human beings, I'll point out that the first house on my block is number 1262, yet I've never heard anyone -- including children -- become confused over the equivalence of "first" and "number 1262". Most people of my acquaintance -- including non-geeks -- have no trouble distinguishing ordinal numbers (first, second, third, etc.) from cardinal numbers (0, 1, 2, ... 1262, 1268, 1274, etc.) I assume that the decision to have true before false in the behavior of PICK and / (as a path constructor) is by analogy with the behavior of EITHER or IF/ELSE which have the option for true before the option for false, so that if/else logic-expr true-block false-block or either logic-expr true-block false-block is essentially equivalent to do pick [true-block false-block] logic-expr (that is, without re-ordering the blocks). *sigh* I guess we'll take what consistency we can get! ;-) -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [8/66] from: gchiu:compkarori at: 2-Jul-2001 17:17


On Sun, 1 Jul 2001 21:05:21 -0700 "Larry Palmiter" <[larry--ecotope--com]> wrote:
> Hi Graham, Volker, Robert > >> help pick
<<quoted lines omitted: 11>>
> So PICK is an action. Actions are polymorphic functions > that can have very
Live and learn <g> fuzzy: 3 :-) -- Graham Chiu

 [9/66] from: joel:neely:fedex at: 1-Jul-2001 19:37


Hi, Larry, Not that I'm in the habit of tilting at windmills, but ... ;-) Larry Palmiter wrote:
> So PICK is an action. Actions are polymorphic functions that > can have very different effects depending on the datatype of > the arguments. >
True enough, but it pains me to have polymorphism used as shorthand for "there is no consistent pattern, just memorize it".
> PICK takes a number or a logic arg. If the arg is a number > it is used as an index into the series arg. If it is a logic > value, it returns the first element for true and the second > element for false. There is no connection with any numeric > value associated with true and false. >
Well... (grumble, grumble)... the above explanation clearly identifies "true" with "first" and "false" with "second". We already know that REBOL fairly rigidly identifies "first" with one and "second" with "two", at least in cases where counting is a meaningful operation (such as positions in a series!) So I think it's a bit unfair to say there's "no connection". Rather it seems reasonable to acknowledge that the terminology used by REBOL allows (if not invites) one to reason that true -> first -> one false -> second -> two which conflicts (at least in the mind of many readers, I'd suggest) with the inference based on type conversion.
> >> to-integer true == 1 > >> to-integer false == 0 > > Also > > >> to-logic 0 == false > >> to-logic -123.5 == true > >> to-logic 123.5 == true >
Again, let's play fair. There are more numeric values than logic values, so the pigeonhole principle requires that either we have a many-to-one relationship, or we rule some conversions as illegal and throw exceptions. REBOL chose door number 1 in this case, and we usually use fixpoints to determine the natural correspondence in such cases, as in
>> 0 == 0 >> to-logic 0 == false >> to-integer to-logic 0 == 0 >> to-logic to-integer to-logic 0 == false
and
>> 300 == 300 >> to-logic 300 == true >> to-integer to-logic 300 == 1 >> to-logic to-integer to-logic 300 == true >> to-integer to-logic to-integer to-logic 300 == 1
where we stop iterating when we reach stability, and conclude that the "natural" correspondence is true <--> 1 false <--> 0 I'd point out that in some languages, the correspondence is true <--> -1 false <--> 0 but then I'd have to talk about other languages and "bits", neither of which are legitimate REBOL concepts... ;-) In contrast, REBOL rules that strings of length <> 1 may not be converted to character values,
>> to-char "a" == #"a"
as distinct from
>> to-char "aa"
** Script Error: Invalid argument: aa ** Where: to-char ** Near: to char! :value so, in this case REBOL takes door number 2. There is a term (which escapes me at the moment, the hour being late) in crystallography for the following interesting phenomenon: When growing outward from a single "seed", many crystalline substances produce lovely, consistently- structured crystals in which everything aligns nicely. However, if a single environment contains multiple such seed-points, the result may be nicely-structured regions around the seeds, with chaotic jumbles at the boundaries where differently-aligned regions grew to collision and began competing over orientation. The presence of such boundaries of mis-aligned regions may very well serve as "fault lines" along which the structure as a whole is weakened and may be broken apart more easily. But I digress, since crystals are a non-REBOL concept. ;-) -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [10/66] from: robbo1mark:aol at: 2-Jul-2001 6:25

Correct Behaviour? Was False = 2 ?????


JOEL NEELY, Hi Joel, are you saying that you think this should be the "CORRECT" or "CONSISTENT" REBOL Behaviour. Notice I've given 'PICK the ability to accept an integer! logic! & none! value for indexing values, is this correct / consistent in your opinion?
>> to-integer false
== 0
>> to-integer true
== 1
>> to-integer none
== 0
>> to-logic 0
== false
>> to-logic 1
== true
>> to-logic none
== false
>> alpha: [a b c d e f g]
== [a b c d e f g]
>> index? alpha
== 0
>> length? alpha
== 7
>> pick alpha 0
== a
>> pick alpha 1
== b
>> first alpha
== a
>> second alpha
== b
>> last alpha
== g
>> pick alpha true
== b
>> pick alpha false
== a
>> pick alpha none
== a
>> logic: [false true]
== [true false]
>> pick logic 0
== false
>> pick logic 1
== true
>> pick logic true
== true
>> pick logic false
== false
>> pick logic none
== false
>> first logic
== false
>> second logic
== true
>> last logic
== true
>> index? logic
== 0
>> length? logic
== 2
>> find alpha 'z
== none
>> find alpha 'c
== [c d e f g]
>> index? find alpha 'c
== 2 Should REBOL display & act with "correctness" and consistency or should it mimic the abiguity and inconsistency that both Larry & yourself imply / state with your previous posts on this thread? I look forward to your comments with much interest. cheers, Mark Dickson

 [11/66] from: joel:neely:fedex at: 2-Jul-2001 3:49


Hi, Mark, Since you asked... ;-) - "correctness" requires specification - "consistency" is A Good Thing, but sometimes isn't free - REBOL is REBOL; anything else is something else [Robbo1Mark--aol--com] wrote:
> JOEL NEELY, > > Hi Joel, are you saying that you think this should > be the "CORRECT" or "CONSISTENT" REBOL Behaviour. >
I distinguish between "correct" and "consistent". A program is "correct" (or not) if it conforms to specification (or not). In the absence of specification, one is unable to call *any* program behavior "incorrect". Since an implementation (compiler and/or interpreter) of a programming language is a program, I can only describe its correctness in terms of the specification for the language. I do assume that the standard laws of arithmetic and numerical analysis apply to any language that represents arithmetic as part of its capabilities. Therefore, any language (using standard arithmetic notation!) that evaluated 2 + 2 as equal to 5 would be incorrect IMHO. OTOH, "consistency" is an admittedly subjective quality, but is important in that it promotes learning and understanding. Self-consistency is critical for a language to be usable; it is also reasonably easy to discuss objectively. I think that self-consistency is preserved when, for example write %foo.file foo-data and save %foo.file foo-data use the same ordering for destination and content arguments. Had they not done so, there would have been an easily- avoidable opportunity for programmers to make needless errors. Consistency with familiar "common sense" habits and inferences is much harder to argue (or refute) with objectivity, but is still highly important because it affects the ability of new- comers to become comfortable and confident with a language. Most people of my acquaintance -- geeks or non-geeks -- are familiar with the concept of the "case" of a letter, as in upper-case "A" versus lower-case "a". Since this is a property of the individual letter, I question the "common sense" consistency of the following:
>> uppercase "why"
== "WHY"
>> uppercase #"w"
** Script Error: uppercase expected string argument of type: any-string ** Near: uppercase #"w" This example would be easy to fix without breaking any existing REBOL code IMHO. That's not always the case. Consider
>> the-block: [2 3 5 7 9] == [2 3 5 7 9] >> the-list: make list! the-block == make list! [2 3 5 7 9] >> remove the-block == [3 5 7 9] >> remove the-list == make list! [3 5 7 9] >> the-block == [3 5 7 9] >> the-list == make list! []
IMHO it is inconsistent with "common sense" that REMOVE would leave blocks and lists in differing states after evaluating analogous expressions. (I might be persuaded that it is even self-inconsistent...) But I suspect that if REBOL/Core 2.6 changed REMOVE to leave all series values in the same resulting state, there might be breakage in some people's code. In such a case, RT (i.e., Carl) would have to decide between preserving existing code vs. changing the behavior of REMOVE in the interest of future benefits of consistency, learnability, and understandability (for generations of future programmers yet to be enlightened to the virtues of REBOL ;-) Not that I have a preference, of course! ;-} However, if someone gets tripped up by the current behavior and posts a question to this list, I think that fairness compells both RT and us on the list to acknowledge the root cause -- inconsistency/exceptions in the notation itself -- and offer - explanation for the inconsistency (if there is one), - suggestions for how to remember the exceptions, - documentation that explicitly warns of the stumbling blocks most often encountered. I would prefer not to have the questioner think that I lay the fault at his door, and regard him as having inadequate REBOL Zen .
> Notice I've given 'PICK the ability to accept an > integer! logic! & none! value for indexing values,
<<quoted lines omitted: 3>>
> inconsistency that both Larry & yourself imply / state > with your previous posts on this thread?
I'd love to see (and would be willing to provide labor toward) a complete REBOL specification. Until that document exists, discussion of "correctness" is largely meaningless. I'd love to see internal and "common-sense" inconsistencies eliminated whenever possible, but I am realistic enough to know that this can't happen without effort/cost. However, when you say that you've "given 'PICK the ability" to behave in some particular way, we must be clear that we're no longer talking about REBOL. Anyone is entitled to make up his/her own language with whatever properties (s)he wishes. If the goal of such an effort is to "mimic" REBOL, then it seems clear that faithfully reproducing REBOL behavior is implicit to that goal. If the goal of such an effort is to create your own language, I'd certainly suggest that you put serious effort into first specifying the language, examining/refining that specification to eliminate all possible inconsistencies (of any kind), and then faithfully reproducing the behavior called for in the spec. But in neither case should you call it "REBOL". -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [12/66] from: robbo1mark:aol at: 2-Jul-2001 11:23


Joel / Everybody okay then accepting all your perfectly valid qualifications & clarifications, I'll reframe my original question, thus...... If the decision was YOURS, would YOU prefer to see REBOL behaviour modified so series! index begin at 0, True, False & None & 'PICK behaved in the way I described. You intimated that you see the future of REBOL being a much greater time period than the past history of REBOL thus far so presumably you think it's important that we don't get "locked" into the "WRONG" way of doing things forever just for the sake of backwards compatability. I use the term "WRONG" here on my analysis of of your previous comments, I've no doubt you will correct me here on this ;-) With regards to backwards compatability I've got loads of scripts that no longer work because of changes in newer REBOL versions. /Wait to /No-Wait port! refinements, VID changes to name but a few examples. RT don't seem to mind breaking backwards compatability when it suits them for the sake of newer preferable behaviour. Also I believe "major" changes to port! schemes are planned in upcoming REBOL releases, we'll have to wait & see how much this changes backwards compatability, If at all! Now I know all of this is hypothetical as only Carl & the RT gang can actually decide and implement any Language changes to REBOL but as someone who's knowledge and opinions I greatly respect ( if not always agree with 8-) I was just trying to elicit whether you would "PREFER" the behaviour I suggested as opposed to "ACTUAL" REBOL behaviour, IF the decision was YOURS to make? ( Which it's NOT so sorry If Iam wasting your time. ) Secondly, I too agree that it is important we document and specify as MUCH of REBOL behaviour and consistency / inconsistency as we can, I also think it would be extremely valuable and useful to have a REBOL specification and in the absence of "official" RT documentation, I TOO would contribute and volunteer my efforts to the production of such a document, though NOT as Lead Author as there a people on this List much more capable & experienced with this aspect of REBOL / Comp. Sci. than myself, besides trying to grok what lies beneath REBOL takes up enough of my time / brain capacity! Your opinions are valued! , well by me anyway ;-) PS Ladislav, Larry & everybody else, please feel free to comment on this if you so wish. Quick & Dirty REBOL User Poll. 1. Should Series! Index begin at Zero? 2. Should 0, None & False be equivalent for 'PICKing values from a series! and return the FIRST or index 0 value whereas True and 1 would return the SECOND or Index 1 value? cheers folks, Mark Dickson

 [13/66] from: jelinem1:nationwide at: 2-Jul-2001 11:34


Here is opportunity to stick my foot in my mouth that is too juicy to pass up. First of all, IMO associating logic data-types with numerical values is subjective anyway, and the the argument for choosing 0, 1 (or -1, 0) is steeped in legacy code of "other languages". Making the statement "pick [a b c] true" is bastardizing the 'pick functionality unless there is a fundamental reasoning for allowing a logic value to take the place of an index. Generally speaking, this is an invalid operation in the "correct" sense. This operation does have definition, however, FOR A SPECIFIC LANGUAGE based on that language's implementation. C programmers know the underlying (and very literal, almost universal) definition of TRUE and FALSE; REBOL doesn't work that way! 'true and 'false in REBOL do not evaluate to numeric values, but to true logic types. If we allow them to choose from among elements of a series, what makes sense <caps>ignoring the implementations of other languages due to thier deficiencies in supporting true logic types?</caps> I have no problem with the answer RT have given, and was in fact delighted at discovering the reasoning (just before I read the next reply which stated this). That is, everytime you used 'if and 'either you were already performing "pick [[code1] [code2]] <logic value>"! From a generic programming perspective, what could make more sense? Besides, as was also pointed out, if you want your "usual" numeric values of 'true, 'false use 'to-integer.
> Quick & Dirty REBOL User Poll. > 1. Should Series! Index begin at Zero?
Absolutely not. If you truly think in terms of "index" then yes, but (being a human being, not a C program) I think in terms of "position".
> 2. Should 0, None & False be equivalent > for 'PICKing values from a series! and > return the FIRST or index 0 value whereas > True and 1 would return the SECOND or > Index 1 value?
No. See my interpretation of existing REBOL functionality above. - Michael, going to eat something more wholesome, now

 [14/66] from: ryanc:iesco-dms at: 2-Jul-2001 10:31


> Quick & Dirty REBOL User Poll. > > 1. Should Series! Index begin at Zero? >
Yes. While it has always seemed perfectly natural to me, most non-programmers I know find it odd, and dont relate to it naturally. For this reason I am glad to see the series begin with 1.
> 2. Should 0, None & False be equivalent > for 'PICKing values from a series! and > return the FIRST or index 0 value whereas > True and 1 would return the SECOND or > Index 1 value?
Yes, it should, but I dont imagine it very useful. Just would make good consistency and sensibility though, and probably an elementary change, so therefore should be implemented. I would expect it was intended to work this way, but someone probably goofed.
> > cheers folks, > > Mark Dickson > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
--Ryan Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400

 [15/66] from: awing:hetnet:nl at: 2-Jul-2001 20:04


Hi to all. being a newbie to REBOL, I am interested in the subject! I've done a lot of work using lots of programming languages. Just as Carl I find languages fascinating. So far (having looked at REBOL for a few weeks now) I've got a positive "feeling" about it. Having said that, I agree with Mark that it is better to "purify" the language now in order to keep up with future requirements.
> 1. Should Series! Index begin at Zero? >
Yes, I like that. To be backward compatible, however, a REBOL command line switch could be added to enable both ways.
> 2. Should 0, None & False be equivalent > for 'PICKing values from a series! and > return the FIRST or index 0 value whereas > True and 1 would return the SECOND or > Index 1 value? >
To be honest, I look upon this issue as an obscure one. I believe that True and False etc. should not be looked at as if they are ordinal and can be used as indices into a series! I would vote for an error to be generated when one tries to misuse boolean values this way.
> Now I know all of this is hypothetical as only > Carl & the RT gang can actually decide and implement > any Language changes to REBOL ... >
I think it is a pity that the language remains proprietary! In order to gain broad support for and use of REBOL, there should evolve ways to influence the further development of REBOL by the open community. Not doing so will prevent REBOL from growing real big. Kind regards, Arie van Wingerden

 [16/66] from: agem:crosswinds at: 2-Jul-2001 20:32


RE: [REBOL] Re: Correct Behaviour? Was False = 2 ???? [ryanc--iesco-dms--com] wrote:
> > > > Quick & Dirty REBOL User Poll. > >
snip
> > 2. Should 0, None & False be equivalent > > for 'PICKing values from a series! and
<<quoted lines omitted: 6>>
> expect it was intended to work this way, but someone probably > goofed.
pessimistic approach. iam used to yes/no, true/false,.. also [pick["got it"] false] gives none, like if. lots more elegant. OTOH, should [to integer! true] throw error? theres no need to give logic values implicit integer meaning. we have [pick[1 0] logic] if we need it :-)
> > > >
<<quoted lines omitted: 3>>
> > -- > --Ryan
;-) Volker

 [17/66] from: ryanc:iesco-dms at: 2-Jul-2001 13:21


[agem--crosswinds--net] wrote:
> RE: [REBOL] Re: Correct Behaviour? Was False = 2 ???? > [ryanc--iesco-dms--com] wrote:
<<quoted lines omitted: 18>>
> also [pick["got it"] false] gives none, like if. > lots more elegant.
Hmm, it is kinda elegant that way.
> OTOH, should [to integer! true] throw error? > theres no need to give logic values implicit integer meaning. > we have [pick[1 0] logic] if we need it :-) >
Logic values do have an implicit integer meaning, 0 false, and 1 true. This is firmly accepted amongst electronics world.
> > > > > >
<<quoted lines omitted: 9>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400

 [18/66] from: rryost:home at: 2-Jul-2001 14:05


I'm in favor of retaining REBOL's present behavior in re starting a series with index 1 for the first element. I'm an old Forther, and first preferred starting with 0, but at this point in REBOL's development, too many words would have to be redefined to make the switch. Keep starting at 1. As to how Pick should act with a logic argument vs with a numeric argument, I see no need for "consistency". Logic elements have only two values, True and False. A user should never assume how a function like Pick will act with a logic type argument from how it acts with a numeric type argument. In my opinion, numeric values of 1, 0, -1, 2, etc should _never_ be generally associated with the logic values True and False. It's ok for a script to make such an association ("locally") in a function, at the whim of the person writing the script, and defining the function. Russell [rryost--home--com]

 [19/66] from: rryost:home at: 2-Jul-2001 14:15


In response to Michael, tho I'm certainly not an expert, I thought Object Oriented Programming allowed an Object to process input arguments of different types in entirely unique (inconsistent, if advantageous) ways. This is an example of "overloading" (definition of actions depends on type of argument) the word Pick. There are many other examples of this in REBOL. Russell [rryost--home--com]

 [20/66] from: joel:neely:fedex at: 2-Jul-2001 16:38


Hello, all, Having already expressed some opinions (perhaps too many ;-) in this area, I felt inclined to listen for a while. I think there are a couple of points that haven't come up that are worth considering. [Robbo1Mark--aol--com] wrote:
> 1. Should Series! Index begin at Zero? >
I'd rephrase as "What are the pro/con tradeoffs for having series indices begin at 0 or 1? If there are advantages to having 0-origin indexing, do those advantages outweigh the effort of conversion of existing code?" Let me pose a practical programming question: given
>> a: [2 3 5 7 11 13 17 19] == [2 3 5 7 11 13 17 19] >> b: at a 5 == [11 13 17 19] >> c: at b 3 == [17 19]
what is the relationship between A and C? I.e., what value of X makes pick a x equivalent to pick c 2 Answering this question (or explaining the answer) in a 1-origin scheme (actually, any non-0-origin scheme) seems to involve the distinction between absolute indices and relative indices, which combine according to the following rules: absolute - absolute is relative absolute + absolute is useless/misleading relative +/- relative is relative absolute +/- relative is absolute The relative index of B in A is (5 - 1). The relative index of C in B is (3 - 1). Therefore, the absolute index of C/2 in A is (5 - 1) + (3 - 1) + (2 - 1) + 1 = 8. If all indexing were 0-origin, the distinction between absolute and relative indexes goes away. The above example would have read ;; a: [2 3 5 7 11 13 17 19] == [2 3 5 7 11 13 17 19] ;; b: at a 4 == [11 13 17 19] ;; c: at b 2 == [17 19] and the position of C/2 relative to A would be 4 + 2 + 2 = 8. Remember that it wasn't until western civilization gave up the 1-origin Roman numerals and began using the 0-origin decimal system that arithmetic really began the uphill climb to becoming Mathematics.
> 2. Should 0, None & False be equivalent > for 'PICKing values from a series! and > return the FIRST or index 0 value whereas > True and 1 would return the SECOND or > Index 1 value? >
There's another lurking inconsistency, which has nothing to do with converting to/from integers. Consider that
>> logblk: reduce [
[ 1 < 2 1 > 2 2 < 1 2 > 1 [ ] == [true false false true]
>> sort logblk == [false false true true]
Doesn't it seem odd that SORT thinks that FALSE precedes TRUE, and yet PICK thinks that FALSE *follows* TRUE? Surely the ordering of values within a type is a meaningful concept, whether or not we try to convert to/from some other type? -- It's turtles all the way down! joel'dot'neely'at'fedex'dot'com

 [21/66] from: agem:crosswinds at: 3-Jul-2001 3:35


RE: [REBOL] Re: Correct Behaviour? Was False = 2 ???? [ryanc--iesco-dms--com] wrote:
> [agem--crosswinds--net] wrote: > > RE: [REBOL] Re: Correct Behaviour? Was False = 2 ????
<<quoted lines omitted: 29>>
> Logic values do have an implicit integer meaning, 0 false, and 1 > true. This is firmly accepted amongst electronics world.
are rebol-users electronic? true, on, yes / false, off, no in human & rebol world. handle / ignore in a way. so [ok's: ok's + to integer! is-it-right?] makes sense and [pick["we got it"] is-it-right?] makes sense too. IMHO thinking with action on "false, off, no" is not so common, more digital "not not" thinking. needs additional brain <-> code -translations.
> > > > > >
<<quoted lines omitted: 10>>
> > -- > Ryan Cole
-Volker

 [22/66] from: agem:crosswinds at: 3-Jul-2001 3:35


RE: [REBOL] Re: Correct Behaviour? Was False = 2 ???? Hello Joel, [joel--neely--fedex--com] wrote:
> Hello, all, > Having already expressed some opinions (perhaps too many ;-)
<<quoted lines omitted: 29>>
> of C in B is (3 - 1). Therefore, the absolute index of C/2 > in A is (5 - 1) + (3 - 1) + (2 - 1) + 1 = 8.
which is (5 - 1) + (3 - 1) + 2 = 8 or [(offset? a b) + (offset? b c) + 2] and in a simulated 2d-array y - 1 * width + x ; rebol-order ;-) instead of y * width + x both not to much more complicated. (aerm, +/- 1 . my preferred error.. usually i get confused with this stuff, please check.. :)
> If all indexing were 0-origin, the distinction between absolute > and relative indexes goes away. The above example would have
<<quoted lines omitted: 7>>
> system that arithmetic really began the uphill climb to becoming > Mathematics.
Well, we have 0 too :) for me 1 is more pleasant because i count and i index. and counting says i have one, i have two, .., i have length? all-that-here and i ask others to give me the red easter-egg, yes, that, the third. in c i have to code while[index < length? something]; hu? stopping before the last?! in rebol while[index <= length? something] which makes more sense to me. and top? stack <> length? stack ? its goes very common after a while, but - try then to talk to normal people.. :) drawback is the slightly less performant index-calculation. of course a good reason in c. in rebol i rarely use clever index-tricks (and have to think then in both worlds). but 0 needs a mental translation allways without (very big) benefit. rebol wants to be "plain english for computers" ;-)
> > > > 2. Should 0, None & False be equivalent
<<quoted lines omitted: 13>>
> ordering of values within a type is a meaningful concept, > whether or not we try to convert to/from some other type?
oops, well, hm, yes, it should be, aerhm, .. ;-) i think sort hits exactly the middle between both interpretations? Ah! the heavier values are right? hm?! fortunally i seldom sort logicals, so i can defer the answer :)
> -- > It's turtles all the way down!
BTW i like the joke.but the first steps were elephants? Terry?! :)
> joel'dot'neely'at'fedex'dot'com
;-) Volker

 [23/66] from: kenneth:nwinet at: 2-Jul-2001 21:14


FWIW, I'd like to add my voice... If I'm counting something I may have one of them, but if I'm ordering something the first element has to be zero. Starting the count from 1 is as arbitrary as starting at negative five (other than the direct mapping to a count) in all other cases I can think of, starting from zero produces cleaner code. I think the Roman numeral analogy is more than apt. Backward compatability is more an issue with a scripting language, but I'd hope for a number of reasons that a switch option base not be added. Consider my chad to be completely removed on this point (as if I had a vote ;-) Mapping True/False to numbers? If we can ignore the pesky undefines then the universal set can either be defined as (true and not true) or (false and not false.) Of course, it doesn't have to be integers we map to... True [ 42, 3.14159, www.rebol.com ] everything else is False! Then we have the rebol way... both zero and one are true! not 0 ; = false not not 0 ; = true not 1 ; = false not not 1 ; = true then again this works for any defined value AFAIK. And along with Or seem to work in a bitwise fashion so I don't believe they can be used to prove anything regarding rebols mapping of values to booleans. My guiding principle is what leads to cleaner code so I'd look for counter example to using an integer zero for false and anything else for true. Bitwise logic can't be used here because it doesn't promote the value to a true boolean before performing it's action leading to apparent inconsistancies (ANDing two or more true values may result in a false.) 1 and 2 ; = false So my question is, how does a boolean value that doesn't map to integers have any validity with regard to a series? Why wouldn't it lead to a scripting error rather than some arbitrary behavior? It seems to me there is an implied mapping in this train of thought.... a: [1 2 3] pick a 1 ; = 1 pick a false ; = 1 pick a 2 ; = 2 pick a true; = 2 What do I see? Looking at it slideways I see false = 0 and true = 1 and a series being counted with the first element being the zeroth. What sees the light of day may be another matter. Does this make sense to anyone else? Regards, Ken.

 [24/66] from: kenneth:nwinet at: 2-Jul-2001 21:36


Sorry, got this wrong... a: [1 2 3] pick a 1 ; = 1 pick a false ; = 1 pick a 2 ; = 2 pick a true; = 2 ...but then I realized this is further evidence (although not proof of course) that the behavior is inconsistant. Ken.

 [25/66] from: rotenca:telvia:it at: 3-Jul-2001 10:57


Ken Anthony <[kenneth--nwinet--com]> :
> If I'm counting something I may have one of them, but if I'm ordering > something the first element has to be zero. Starting the count from 1 is as > arbitrary as starting at negative five (other than the direct mapping to a > count) in all other cases I can think of, starting from zero produces > cleaner code. I think the Roman numeral analogy is more than apt.
Tell me which man, speaking of his old collection of book, says: "The zero book i buyed was ..." The first book is of course the first. When he counts them, he says: "One, two, three..." If a guest asks: "How many books did you buy before this?" he answers: "Zero!" So, the guest understands, with a little calculation, what is the first book of collection. Zero is the OFFSET, the difference of the first book with itself, it is not a true number, is the result of a calculation. So, array[0] is something which make life easy to computer (element=base+offset), but it is an oddity for a not-computer-trained man. The zero element of a series does not exist. ciao (excuse my bad english) romano paolo tenca

 [26/66] from: chris:starforge:demon at: 3-Jul-2001 10:11


Romano Paolo Tenca wrote:
> The zero element of a series does not exist.
Unless you've programmed C for the best part of a decade, in which case all this talk of starting arrays and series at 1 takes a bit of getting used to.... ;) Chris -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk

 [27/66] from: robbo1mark:aol at: 3-Jul-2001 6:06


Everybody, Interesting to note peoples points and reasonings on this thread & for what it's worth I think they all have some validity. Regards Indexing starting at Zero, I have mixed views on this and still haven't firmly decided which side of the fence I fall on although I think I lean towards the zero position. For instance 'HEAD is always index 1 whereas 'TAIL is always ( index? last + 1 ), I see 'TAIL as being correct because it is the position after the last element of a series! If you accept that as true then surely 'HEAD of a series! should be index position zero, agreed? In my view this should be the "correct" behaviour
>> index? head [a b c]
== 0 My Reasoning being 'INSERT joins values to the head of a series! "before" the first element. With regards to me "giving" 'PICK the ability to accept NONE as an index position, this was only done for example purposes to highlight a further inconsistency in REBOL. The Conditional Functions like 'IF & 'EITHER accept NONE as the logical equivalent of 'FALSE.
>> either none [ true ] [ false ]
== false Therefore if you can do this....
>> pick [true false] false
== false
>> pick [true false] true
== true Then why not this......
>> pick [true false] none
== false After all.....
>> to-logic none
== false Either 'none is the logical equivalent of 'false or it isn't? As it currently stands as these examples show that this is the case except when it's not! and that hardly leads to consistency, clarity or ease of learnability and understanding. I think for clarity & consistency & simplicity this should be the case...... FALSE = NONE = 0 Reasoning...
>> to-logic none
== false
>> to-logic 0
== false
>> to-integer false
== 0
>> to-integer none
== 0 And if you give 'PICK the ability to utilise logic! or conditional values then saying
>> pick [true false] false
== false
>> pick [true false] 0
== false
>> pick [true false] none
== false IMHO Should be the "correct" behaviour however ally that to zero indexing for series! and preferably you would have this as the "correct" behaviour....
>> pick [false true] false
== false
>> pick [false true] 0
== false
>> pick [false true] none
== false
>> pick [false true] true
== true
>> pick [false true] 1
== true Simple, Consistent & easy to learn & remember! Certainly easier than False = 0 except when it equals 2 as we currently have. I think it was Volker who said "Plain English for Computers." Well as somebody who speaks english / scots as my natural language plain is hardly a term I would describe for the language. English as a language is an amalgation of Olde English / Germanic, Latin / French, Celtic / British, Norse, Pictish to name but a few of it's origins. I thought REBOL wanted to be "Simple, Powerful, Elegant" English whilst certainly Powerful and often extremely Elegant can in no ways be described as simple. The Cow -> Beef, Pig -> Pork, distinctions are only one example of multi-lingual variation in English. The former terms originate with the odle english / germanic names for the animals whereas the latter derive from french words for the flesh or meat of these animals and were introduced into english language in Norman times. Sure we all want context sensitivity and power of natural languages in REBOL but surely not also all the baggage & idiosyncracies of them as well? For me 'First is logically simple and compatable with Index position zero. I know this is all what-if anyway because what I have suggested is probably too deep a change for REBOL and would break backwards compatability of both source code AND existing documentation / books etc. so REBOL will most probably not be changed. However there is no harm in thinking / suggesting how simple, consistent and easier REBOL could be with no loss of power or expressability or elegance. REBOL 2.x came into being in 1998 so that is only 3 years backwards compatability. Surely we expect REBOL 3++ to be around a LOT longer than that, IMHO better to change now / then than live with inconsistency / the "wrong" way forever! And That is the Microsoft Way! Cheers, Mark Dickson In a message dated Tue, 3 Jul 2001 5:19:52 AM Eastern Daylight Time, Chris <[chris--starforge--demon--co--uk]> writes: << Romano Paolo Tenca wrote:
> The zero element of a series does not exist.
Unless you've programmed C for the best part of a decade, in which case all this talk of starting arrays and series at 1 takes a bit of getting used to.... ;) Chris -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk

 [28/66] from: sqlab:gmx at: 3-Jul-2001 12:47


> Everybody, > > Interesting to note peoples points and reasonings > on this thread & for what it's worth I think they > all have some validity. >
Although it's not my way to join these kinds of discussion, I feel proned to add my comments. Why should everything seen from the view of C? Other languages use other index's offsets or logical representations. I am always glad, when there is no need to recalculate length, offset and position as in C. The Rebol way fits me enough. Regarding the numeric values of logic values, I do not care for the values, but if I should decide I would choose zero for 'NULL. postive values for true and negative for false. There are more things between heaven and earth.) AR

 [29/66] from: ingo:2b1 at: 3-Jul-2001 13:21


Hi Mark, Once upon a time [Robbo1Mark--aol--com] spoketh thus: <...>
> I think I lean towards the zero position. For > instance 'HEAD is always index 1 whereas 'TAIL > is always ( index? last + 1 ), I see 'TAIL as > being correct because it is the position after > the last element of a series!
Yup.
> If you accept that as true then surely 'HEAD of > a series! should be index position zero, agreed?
No. Imagine a queue at a ticket counter: There's someone at the HEAD of the queue, that's the FIRST (1), there's a LAST one, he's at the position length of the queue, and there's the TAIL of the queue, where you have to stand, if you are coming now, that's length + 1. length of queue now, 4 people _____ / \ o o o o o Tickets /O\ /O} {O} /O\ /O\ | | / \ / \ / \ / \ / \ | | | coming late goint to the tail at the head the last will be last position 1 position 4 position 5
> In my view this should be the "correct" behaviour > > >> index? head [a b c] > == 0 > > My Reasoning being 'INSERT joins values to the head > of a series! "before" the first element.
Given these three things on a table apple mushroom orange please insert a glass_of_water at the position of the apple glass_of_water apple mushroom orange now please insert a spoon at position 1 spoon glass_of_water apple mushroom orange looks pretty correct and simple to me.
> With regards to me "giving" 'PICK the ability to > accept NONE as an index position, this was only
<<quoted lines omitted: 20>>
> hardly leads to consistency, clarity or ease of learnability > and understanding.
That's ok so far ...
> I think for clarity & consistency & simplicity this should > be the case......
<<quoted lines omitted: 30>>
> == true > Simple, Consistent & easy to learn & remember!
Except whene it's not:
>> if true [true]
== true
>> either true [true][false]
== true
>> either false [true][false]
== false The "trueth" comes first here, and the "falseth" last, like in pick, if find that "Simple, Consistent & easy to learn & remember!" (quoting somone on this list ;-) <...>
> For me 'First is logically simple and compatable with Index position > zero.
<...>
> REBOL 2.x came into being in 1998 so that is only 3 years > backwards compatability. Surely we expect REBOL 3++ to be around a LOT > longer than that, IMHO better to change now / then than live with > inconsistency / the "wrong" way forever! And That is the Microsoft Way!
<...>
> > The zero element of a series does not exist. > > Unless you've programmed C for the best part of a decade, in which case > all this talk of starting arrays and series at 1 takes a bit of getting > used to.... ;)
Just because people are gotten used to the braindead C, REBOL doesn't have to follow the wrong way, too. Well, that's my opinion. Interestingly the only real advantage of zero based indexing hasn't been stated this time around, the dicontinuity in pick ...
>> a: [ a b c]
== [a b c]
>> a: next a
== [b c]
>> pick a 1
== b
>> pick a 2
== c
>> pick a -1
== a
>> pick a 0
== none kinf regards, Ingo

 [30/66] from: brett:codeconscious at: 3-Jul-2001 22:57


> Unless you've programmed C for the best part of a decade, in which case > all this talk of starting arrays and series at 1 takes a bit of getting > used to.... ;) > > Chris
Surely the whole of Rebol would have to take a bit of getting used to if you've been talking C so long ;-) I know it did for me (thank goodness) though not from a starting point of C. :-) Brett.

 [31/66] from: joel::neely::fedex::com at: 3-Jul-2001 3:12

The Virtues of Zero: Was "Correct" Behaviour? Was False = 2 ?


Hello, all! I've already said enough (and more than enough!) on this topic. For me the issue is *not* The Language That Must Not Be Named, but rather simplicity, consistency, models, and Mathematics. With these few, somewhat random thoughts I respectfully bring to a close my participation in this topic. I'm not trying to agitate for the remaking of REBOL, nor am I trying to foment discontent. I am trying to make the case for the benefits of consistency, and for the long-view tradeoff of a little learning at first vs. a lot of busy-work forever. -jn- If one learns the simple rule "everything begins at zero" then much of computing (and Mathematics) simply falls into place. Peano's postulates for the natural numbers (aka "the counting numbers" in elementary school) are essentially: - zero is a natural number - the successor of a natural number is a natural number upon which the whole of Mathematics is based. Edsger Dijkstra (who, IIRC has no love for TLTMNBN) has been quoted as saying, "Zero is the most natural number." based on the above. (In fact, his custom for years has been to number the pages of his writings beginning with zero. His explanation is that each page is labeled with the number of pages that preceded it.) We call the point labeled zero on the number line "the origin", because that's where everything starts. It seems entirely reasonable to me to label the starting point of a block with zero, as that is the origin of the block. Labeling positions in a data structure is not the same as counting them. House numbers (especially within a single block!) are not consecutive, but this does not surprise anyone I've ever met. Since labels can start anywhere, and can increase in arbitrary quanta, the simplest labeling scheme is to begin at zero and increase by one. WRT to counting, we always implicitly start with zero. If my wife asks me to fetch a dozen apples from the store, the bag contains zero apples when I open it. As I add each apple, the count becomes the successor of the previous count. Shades of Peano! I am totally unconvinced by any appeal to the expectations of non-programmers for many reasons, including the fact that by definition their intuitions are untrained (or I could say trained for other tasks ). Their intuitions have not yet been trained with MANY useful bits of computing knowledge which may strike them as unexpected at first. * REBOL ignores the common conventions of high-school algebra with respect to expressions such as 4 + 5 * 2 and if counter + 1 = limit ... * The digit characters #"0" thru #"9" precede the alphabetic characters #"a" thru #"z". * Strings and integers sort differently (this one is more of a shock to their naive intuitions than any other fact, in my experience!)
>> foo: repeat i 100 [append [] form i - 1]
== ["0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" "12" "13" "14" "15" "16" "17" "18" "19" "20" "21" "22" "23" "24" "25" "26" "2...
>> sort foo
== ["0" "1" "10" "11" "12" "13" "14" "15" "16" "17" "18" "19" "2" "20" "21" "22" "23" "24" "25" "26" "27" "28" "29" "3" "30" "31" "...
>> baz: repeat i 100 [append [] i - 1]
== [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45...
>> sort baz
== [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45... (The following are all "new facts" in programming which become trivial consequences if one first learns the "everything begins at zero" rule.) * The first (lowest) digit is #"0" (although, in my experience, this fact belongs in the next category for most people !) * There are 256 possible characters, the first (lowest) of which is #"^@" = #"^(00)" = to-char 0 * The first IP address in any sub-net is zero (to some number of bits). I also think it insults the intelligence of the civilian to suggest that (s)he cannot understand zero as a starting point, given that (s)he already uses that knowledge in many everyday contexts: * The 24 hours of the day (on the increasingly-common 24-hour clock) are numbered 0 thru 23. * The 60 minutes in an hour are numbered 0 thry 59. * The 60 seconds in a minute are numbered 0 thru 59. (Incidentally, I've used the "labeling" of components of time as a teaching illustration many times over the years. It is usually all the instruction needed.) * A baby's age during its first year of life is zero years old. Its age during its second year of life is one year old. etc. ad mortem * Many common summaries and displays of information (even in such LCD publications as "USA Today") begin with zero. A graph of "number of children in household" resembling 0: ============= 1: ================= 2: ============ 3: ======= 4: ==== 5: ==
>5:
would confuse no-one by the fact that the first category was labeled with zero. There are many programming tasks that involve traversing a flat data structure (e.g. a block). If positions in the structure are labeled beginning at the origin with zero, many such tasks are simplified. * One can cycle through the positions using simple modular (clock) arithmetic:
>> pos: 3 == 3 >> len: 5 == 5
<<quoted lines omitted: 4>>
>> pos: pos + 1 // len == 3 >> pos: pos + 1 // len == 4
Note that this "cycling" can pick up and leave off at any point, and need not be tied to a particular "control function" with any origin assumptions. * All calculations over positions become simplified as "offsets" and "indexes" now share a common origin and are freely interoperable. * Remember the "number of children in household" histogram above? Calculating summaries from a data structure containing such counts has been a common task throughout my career. With 0-origin indexing, the code can use the raw counts directly as the indexes into the histogram data, while with 1-origin indexing, each such operation is complicated with the mandatory "+ 1". * This is typical of MANY situations where one must constantly deal with "+ 1" or "- 1", with the consequences that: * There are more opportunities for bugs (off-by-one errors are notoriously common and often hard to track down) * The code looks uglier because of the insertions * The code is slower because of the extra arithmetic ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [32/66] from: kenneth:nwinet at: 3-Jul-2001 7:19

Re: R: Re: Correct Behaviour? Was False = 2 ????


Romano, I believe you are making my point.
> "Ken Anthony" <[kenneth--nwinet--com]> : > > If I'm counting something I may have one of them, but if I'm ordering > > something the first element has to be zero. > Zero is the OFFSET...
Absolutely! My followup question would be... What number other than zero could you rationally choose to represent the offset of the first book? I would say there is none, regardless of the fact that there is nothing preventing you from choosing any other number. So repeat after me: ...the index of a series is an index, not a count... ...the index of a series is an index, not a count... ...the index of a series is an index, not a count... ...the index of a series is an index, not a count... ...the index of a series is an index, not a count... ...the index of a series is an index, not a count... Hey... it's going to take a while to get rid of that other brainwashing we've all been exposed to ;-)) Cheers, Ken.

 [33/66] from: jelinem1:nationwide at: 3-Jul-2001 10:07


<grabs the bloodied death-club and takes his turn again, beating the dead horse's carcass> Maybe this is not really "flogging the dead horse" (yet?), but I always find it interesting when there are so many passionate (and very well-articulated) arguments on such a "minor" topic. I'll throw in some final replies, then let the chips fall where they may. Feel free to ignore any comments which do not make sense.
> Regarding the numeric values of logic values, I do not care for the
values, but if I should decide I would choose zero for 'NULL. postive values for true and negative for false. What I've actually done in the past (that darn C language again) is: 0 for FALSE, -1 for TRUE, and -2 for ERROR (pretty much used as "none" in REBOL, before the existance of REBOL). The 0 and -1 were for compatability of binary operations; I never performed arithmetic on or assumed a particular value for ERROR.
> For me the issue is *not* The Language That Must Not Be Named, but
rather simplicity, consistency, models, and Mathematics. Mathematics is included in programming to be sure, but I don't see Mathematics as a superset of programming. Just as "art" can be described in the terms of physics, all of programming can be described in the terms of boolean logic (ie mathematics), but IMO there is more to programming than this. So, I do not see any reason to choose programming implementations based on mathematics (probably better stated as numerics ).
> I think it was Volker who said "Plain English for Computers." Well as
somebody who speaks english / scots as my natural language "plain" is hardly a term I would describe for the language. I've heard this observation of the that phrase before. You are attempting to interpret the phrase literally, in the context of other languages; it wasn't meant to be interpreted that way. You are correct, English is a messy language (just ask Larry Wall), but you are missing the intent of the phrase. "Plain English" to me means "intuitively understood". Now don't go telling me how people's intuitive understandings differ (esp among cultures) ;)
> Logic values do have an implicit integer meaning, 0 false, and 1 true.
This is firmly accepted amongst electronics world. Absolutely! This makes great sense in the world of electronics. But why, in the abstract world of logic, should this relation be valid?
>> Zero is the OFFSET... > Absolutely! My followup question would be... What number other than
zero could you rationally choose to represent the offset of the first book? I would say there is none, regardless of the fact that there is nothing preventing you from choosing any other number. To restate from my first post on the topic, we are talking about two different means of accessing list elements. The OFFSET, or INDEX, properly (ie mathematically?) begins with zero. The POSITION, or COUNT begins at one. Then the argument becomes: do we want to reference list items by INDEX or POSITION? Are we mathematicians (INDEX) or, um, not (POSITION)? After programming in C for a decade myself, I STILL had to mentally coerce myself into remembering "array starts at zero, loop until less-than the length...". This came from firm roots in BASIC as a first language. I eventually came up with the terminological distinction of index vs position, and found it very helpful in keeping things straight. I find it very welcome to "come home again" to position-based access. <passes the club, goes back to work> - Michael

 [34/66] from: jeff:rebol at: 3-Jul-2001 8:48


An old argument where no one seems to come away satisfied. I think the reason why it becomes such a frustrating argument is because the nature of the argument and the goals people have in arguing. These are the goals people usually have going into the indexing argument (or really many of these kinds of language definitional arguments): 1. Express desire for different behavior in REBOL. 2. Demonstrate inconsistencies in REBOL. 3. Express preference for current REBOL behavior. 4. Demonstrate consistency in REBOL. On all four points people can successfully deliver arguments. Points 3 and 4 are favored by the status quo which is grist for the mill of advocates of points 1 and 2. Woops.. maybe that should be the "advocates of points 0 and 1" arguing against "points 2 and 3" of the status quo".. anyhow I'm getting confused ... (-: -jeff

 [35/66] from: chris:starforge at: 3-Jul-2001 19:48


#03-Jul-01# Message from [*JELINEM1--nationwide--com*]: Hi [JELINEM1--nationwide--com],
> INDEX or POSITION? Are we mathematicians (INDEX) or, um, not (POSITION)?
We're programmers: we both and neither.
> After programming in C for a decade myself, I STILL had to mentally coerce > myself into remembering "array starts at zero, loop until less-than the > length...". This came from firm roots in BASIC as a first language. I
Learning BASIC is like being taught at a Catholic school (I should know, I went to one;)) - you never get over it. My brush with BASIC was thankfully short, after 6 or 7 years of C, c++ and now Java programming I find myself using 0 indexed values all over the place unless I stop myself! :) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- A straw vote only shows which way the hot air blows. -- O'Henry

 [36/66] from: jeff:rebol at: 4-Jul-2001 11:05


So... let's give it a try.. pick': :pick pick: func [series index][pick' series index + 1] index?': :index? index?: func [series][(index?' series) - 1] at': :at at: func [series index][at' series index + 1] zeroth: func [x][pick x 0] first: :second second: :third third: :fourth fourth: :fifth fifth: func [x][pick x 5] zeroth [1 2 3 4 5] == 1 first [1 2 3 4 5] == 2 pick [1 2 3] 0 == 1 fifth [1 2 3 4 5 6] == 6 zeroth second [[A B C][9 8 7][1 2 3]] == 1 index? "abc" == 0 at "1234" 3 == "4" ;------------------------------------------- The only problem with all this is you have to go and change all occurances of first, second, third, etc. through out the rest of REBOL to reflect the new index.
>> ? help
** Script Error: third expected series argument of type: series money date port tuple event ** Where: ? ** Near: args: third :value prin "USAGE:^/^-"
>>
Maybe some ambitious zero-based indexer would like to create a script that goes through and changes all occurrences of the numbered pickers in the REBOL mezzanine layer. Then all that's left is to figure out some way to change the path pickers. I'll contemplate that zero zeroth thing tomorrow morning. We might need an additional NEEDS field: REBOL [ Title: "My mostly portable script" Needs: [zero-indexing] ] :-) REBOL is the zeroth language of its kind! All for zero and zero for all! And for those here in the US, happy third of July! (-: -jeff

 [37/66] from: robbo1mark:aol at: 4-Jul-2001 14:31


Hello Jeff,
>zeroth: func [x][pick x 0] >first: :second >second: :third >third: :fourth >fourth: :fifth
This part of what you wrote is surely wrong? As we discussed earlier about the series of natural numbers 0 1 2 3 4 5 ...... infinity 0 is the FIRST number there is no ZEROTH, 1 is the second number. The functionality of FIRST, SECOND etc need not change. First would still pick the FIRST element of a series at index position zero. SECOND would pick second element of series at index 1. Repeat after me "Counting is NOT the same as indexing..." Yes it would require an audit of mezzanine code to change / modify affected code and YOU guys would have to amend the native! code but just because it is NOT a cost free task does not mean it is not the "right" thing to do IMHO. Do we stick with the "wrong" way forever just because it is too daunting / too much work to change now? Admittedly "right" and "wrong" are MY subjective opinions on this matter, as well as some other peoples, but that doesn't alter the principle that should you forego the opportunity to DO something differently or better just because of the work involved? However, if you want and I will gladly audit all REBOL mezzanine code and make the necessary changes if you give me sufficient time / incentive / advice. What do you say? will RT Inc take me up on my offer? cheers, Mark Dickson In a message dated Wed, 4 Jul 2001 2:11:34 PM Eastern Daylight Time, Jeff Kreis <[jeff--rebol--net]> writes: << So... let's give it a try.. pick': :pick pick: func [series index][pick' series index + 1] index?': :index? index?: func [series][(index?' series) - 1] at': :at at: func [series index][at' series index + 1] zeroth: func [x][pick x 0] first: :second second: :third third: :fourth fourth: :fifth fifth: func [x][pick x 5] zeroth [1 2 3 4 5] == 1 first [1 2 3 4 5] == 2 pick [1 2 3] 0 == 1 fifth [1 2 3 4 5 6] == 6 zeroth second [[A B C][9 8 7][1 2 3]] == 1 index? "abc" == 0 at "1234" 3 == "4" ;------------------------------------------- The only problem with all this is you have to go and change all occurances of first, second, third, etc. through out the rest of REBOL to reflect the new index.
>> ? help
** Script Error: third expected series argument of type: series money date port tuple event ** Where: ? ** Near: args: third :value prin "USAGE:^/^-"
>>
Maybe some ambitious zero-based indexer would like to create a script that goes through and changes all occurrences of the numbered pickers in the REBOL mezzanine layer. Then all that's left is to figure out some way to change the path pickers. I'll contemplate that zero zeroth thing tomorrow morning. We might need an additional NEEDS field: REBOL [ Title: "My mostly portable script" Needs: [zero-indexing] ] :-) REBOL is the zeroth language of its kind! All for zero and zero for all! And for those here in the US, happy third of July! (-: -jeff

 [38/66] from: chris:starforge at: 4-Jul-2001 17:23


#04-Jul-01# Message from [*Sanghabum--aol--com*]: Hi [Sanghabum--aol--com],
>> I looked at Visual Basic, Pascal, Modula-2, C, C++, C#, Java, >> Javascript, Perl, Python, Fortran amongst others and they ALL use zero >> based indexing. >> > COBOL indexes from 1 too. I always knew my covert COBOL skills would be > vindicated one day.
You're a brave man. Not many people would admit to knowing COBOL in public ;)) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- I have made mistakes but I have never made the mistake of claiming that I have never made one. -- James Gordon Bennett

 [39/66] from: jeff:rebol at: 4-Jul-2001 13:16


Howdy, Robbo0Mark:
> >zeroth: func [x][pick x 0]
. . .
> >fourth: :fifth > > This part of what you wrote is surely wrong?
Nope. It's absolutely right, I've zeroed in on the solution to this confounding dilemma of zeroth principals (or maybe that should be "I negative-oned in on it".. hmmm).
> As we discussed earlier about the series of natural numbers > 0 1 2 3 4 5 ...... infinity > > 0 is the FIRST number there is no ZEROTH, 1 is the second > number.
Right, wrong, no, yes. Zeroth is first, and like you say above, 1 is second, second zeroth to the first and third fourth to the zeroth, but first is the zeroth element after the zeroth, etc. 1 -> 0 0 -> 1 2 -> 3 5 -> 6 4 <-> 3 -1 -> 0 etc... Zero one, one zero, first zeroth, and on and on. It's totally clear in my mind: Zeroth really is first, it only pretends to be zero, but if you turn the zero to the side and look, ah ha! it's really a one!! See, just imagine turning the zero 90 degrees (er... I mean 89 degrees) and ah ha, there's a one! It's really simple once you start thinking sideways about it all!
> The functionality of FIRST, SECOND etc need not change.
It will be much clearer if we just remember that zero is one, and therefore zeroth is really first. First is the second, fifth the sixth, but there's probably no negative-first, which would be really be zeroth because we actually don't have a zeroth, in a real sense, because that would be in the negative-first position, but it's actually first, natural numbers, such that exists for all x in Z+. Now repeat after me "0 1 zeroth first 1 2 first second spin zero sideways make sure to first (zeroth) think of zero first (zeroth), first zeroth first zero".
> First would still pick the FIRST element of a series at > index position zero. SECOND would pick second element of > series at index 1.
Yes, you've almost got it! FIRST is the item at position 1, which is the SECOND item just as we are used to, and ZEROTH is the item at position ZERO, and so 1 zero first 0 zeroth 1 one 0!
> Repeat after me "Counting is NOT the same as indexing..."
Yes. With enough mantras we may help prevent those pesky off by zero (one) errors.
> However, if you want and I will gladly audit all REBOL > mezzanine code and make the necessary changes if you give > me sufficient time / incentive / advice. > > What do you say? will RT Inc take me up on my offer?
I must say, it is very refreshing to see people keeping their sense of humors intact. Wow, that really is a hard offer to resist! (-: Well, Robbo0, I think you should do that, but only if you make the changes typing only with your left pinky finger (the zeroth finger of position zero when you count left to right) while balancing on a 7 (6) foot high pole frying 10 million (9,999,999) pancakes with your free hand and repeatedly singing the zeroth (first) sixty (fifty-nine) verses of the song 99 (98) bottles of beer on the wall. Let us know when you're done! Cheers! -jeff

 [40/66] from: dwhiting:europa at: 4-Jul-2001 13:59


Hello Jeff On 04-Jul-01, Jeff Kreis wrote:
> Right, wrong, no, yes. Zeroth is first, and like you say > above, 1 is second, second zeroth to the first and third
<<quoted lines omitted: 7>>
> one! It's really simple once you start thinking sideways about > it all!
hmmm...Jeff....I think it's time for your dried frog pills:) Dick -- #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# *Dick Whiting* <[dwhiting--europa--com]> _http://www.europa.com/~dwhiting/_ /Satyre/ on Undernet #AmigaCafe# #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=#

 [41/66] from: joel:neely:fedex at: 4-Jul-2001 7:34


Jeff Kreis wrote:
> > This part of what you wrote is surely wrong? > > Nope. It's absolutely right, I've zeroed in on the solution > to this confounding dilemma of zeroth principals (or maybe > that should be "I negative-oned in on it".. hmmm). >
Much as I hate to say it... ;-) First is ordinal, and can map to any number of things besides the cardinal (or natural) numbers. The first natural number is zero. In the example I gave earlier (pardon any typos and forgetfulness regarding Pascal) var StudentPopulation: array [7..12] of integer; the first index of StudentPopulation is 7. In The Language That Must Not Be Named, int charCount [256]; the first index is 0. My "first" name is Joel. And, as I mentioned earlier, the first house in my block has an index (street number) of 1262. Finally, to return to REBOL-relevance, when we discussed the behavior of PICK, some folks were quick to point out that REBOL allows polymorphism, without insisting that we indulge in such neologisms as the "truthth" or "falseth" element in pick ["say" "what?"] value? to-word "zeroeth" any more than we insist on having a hidden 2 in the fact that SECOND gives us a representation of the body of a function. Nicht wahr? -jn- P.S. I wish you all (wherever you are in the world, and whatever your origin ;-) ["sleepy" "dopey" "grumpy" "happy" "sneezy" "bashful" "doc"] (i.e. "happy" fourth! ) ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [42/66] from: joel:neely:fedex at: 4-Jul-2001 7:36


Hi, Dick, Reminding me of one of my favorite sig lines... Dick Whiting wrote:
> Hello Jeff > On 04-Jul-01, Jeff Kreis wrote:
<<quoted lines omitted: 3>>
> > sideways about it all! > hmmm...Jeff....I think it's time for your dried frog pills:)
"We're sorry. The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again." -- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [43/66] from: jeff:rebol at: 4-Jul-2001 16:26


Howdy, Joel:
> Much as I hate to say it... ;-) > > "First" is ordinal, and can map to any number of things > besides the cardinal (or natural) numbers.
Indeed. "First" can map to anything, but how it maps is pretty clear, it refers to the element at position one (whatever position one is defined as). For example, Zeroth is defined in meriam-websters as the element numbered zero (at position zero)-- so we have to have introduce ZEROTH before can reindex all of REBOL and break all existing scripts.
> The first natural number is zero.
That's only if you are indexing the natural numbers 1 based, but if you're indexing the natural numbers zero based, then zero is in position zero, (zero is numbered zero in your list of numbers) so zero is the zeroth number.
> My "first" name is Joel.
Ahh, so you've got a one base indexed name, huh?
> And, as I mentioned earlier, the first house in my block > has an index (street number) of 1262.
Which, I guess, is the house in position 1? If the mailman is a zero based indexer, does the first house get his neighbor's mail? (; -jeff

 [44/66] from: al:bri:xtra at: 5-Jul-2001 11:51


Ken wrote:
> Does anybody know of a use for negative zero?
To help balance the positive zero? :-) Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [45/66] from: joel:neely:fedex at: 4-Jul-2001 14:11


Hello, again, Jeff, Jeff Kreis wrote:
> Indeed. "First" can map to anything, but how it maps is pretty > clear, it refers to the element at position one (whatever > position one is defined as). >
Only if one's head is stuck in 1-origin mode. (Quoth Samuel Jackson in _The_Matrix_, "Free your mind!" ;-) "First" refers to the item in an ordered collection which precedes all others. #"A" is the first upper-case letter, even though its numeric value in ASCII is 65. It remains the first upper-case letter even if you switch to EBCDIC, which gives it a different number.
> > My "first" name is Joel. > > Ahh, so you've got a one base indexed name, huh? >
No. That part of my name simply precedes all other parts. The concept of "one" doesn't even appear.
> > And, as I mentioned earlier, the first house in my block > > has an index (street number) of 1262. > > Which, I guess, is the house in position 1? >
No. It's the house in position 1262. That house precedes all the others in the block.
> If the mailman is a zero based indexer, does the first house > get his neighbor's mail? (; >
The mail man doesn't have to count them to deliver the mail; he only has to match the label on the house to the label on the envelope. SAME? works just as well in either 1-origin or 0-origin! ;-) -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [46/66] from: robbo1mark:aol at: 4-Jul-2001 4:20


Odd Man Out? I did a quick language check last night and it seems REBOL is now odd man out as far as zero indexing is concerned. I looked at Visual Basic, Pascal, Modula-2, C, C++, C#, Java, Javascript, Perl, Python, Fortran amongst others and they ALL use zero based indexing. Now before anybody screams at me about Visual-Sickbay if you check the latest VB.NET you will see they have changed completely to zero based indexing, whereas before with VB6 you had the option of an offset which allowed you to use either 0 or 1 based indexing. Fortran dates from the mid / late Nineteen Fifties so I declare now we can stop attributing blame for this at that Langauage which WE dare Not mention it's name. cheers, Mark Dickson In a message dated Tue, 3 Jul 2001 2:59:30 PM Eastern Daylight Time, Chris <[chris--starforge--co--uk]> writes: << #03-Jul-01# Message from [*JELINEM1--nationwide--com*]: Hi [JELINEM1--nationwide--com],
> INDEX or POSITION? Are we mathematicians (INDEX) or, um, not (POSITION)?
We're programmers: we both and neither.
> After programming in C for a decade myself, I STILL had to mentally coerce > myself into remembering "array starts at zero, loop until less-than the > length...". This came from firm roots in BASIC as a first language. I
Learning BASIC is like being taught at a Catholic school (I should know, I went to one;)) - you never get over it. My brush with BASIC was thankfully short, after 6 or 7 years of C, c++ and now Java programming I find myself using 0 indexed values all over the place unless I stop myself! :) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- A straw vote only shows which way the hot air blows. -- O'Henry

 [47/66] from: alekk:obywatel:pl at: 4-Jul-2001 13:13


----- Original Message ----- From: <[Robbo1Mark--aol--com]> To: <[rebol-list--rebol--com]> Sent: Wednesday, July 04, 2001 10:20 AM Subject: [REBOL] Re: R: Re: Correct Behaviour? Was False = 2 ???? [...]
> I looked at Visual Basic, Pascal, Modula-2, C, C++, C#, Java, Javascript,
Perl, Python, Fortran amongst others and they ALL use zero based indexing. [...] So what? REBOL is different ;) IMO REBOL is designed with people in mind. When You say "all other languages..." it is like "millions of flies can't be wrong. Let's eat ...". 1. First, second ... - increases readability. With zero at start - it would be strange. 2. Length and last index is the same number - no need for another function. 3. Publicity - "Ah, THAT is the language which use ONE based indexing". 4. You can always write Your own dialect. Aleksander K. [alekk--obywatel--pl]

 [48/66] from: robbo1mark:aol at: 4-Jul-2001 8:33


To paraphrase what Ken Antony expressed so eloquently yesterday.. Counting is NOT the same as indexing! the series of natural numbers 0 1 2 3 4 5 ....... infinity which is the first number? 0 or 1 ? YES I too think REBOL is BETTER! but I don't agree that it should / necessarily has to be different in this respect. I previously swayed on this issue but the example
>> a: [ a b c d]
== [a b c d]
>> index? a
== 1
>> a: next a
== [b c d]
>> pick a 1
== b
>> index? a
== 2
>> pick a -1
== a this swayed it for me! IMHO series should be traversed backwards & forwards from the current index point which to me logically is index position ZERO. That's all. Mark Dickson In a message dated Wed, 4 Jul 2001 7:32:54 AM Eastern Daylight Time, "Alekk" <[alekk--obywatel--pl]> writes: << ----- Original Message ----- From: <[Robbo1Mark--aol--com]> To: <[rebol-list--rebol--com]> Sent: Wednesday, July 04, 2001 10:20 AM Subject: [REBOL] Re: R: Re: Correct Behaviour? Was False = 2 ???? [...]
> I looked at Visual Basic, Pascal, Modula-2, C, C++, C#, Java, Javascript,
Perl, Python, Fortran amongst others and they ALL use zero based indexing. [...] So what? REBOL is different ;) IMO REBOL is designed with people in mind. When You say "all other languages..." it is like "millions of flies can't be wrong. Let's eat ...". 1. First, second ... - increases readability. With zero at start - it would be strange. 2. Length and last index is the same number - no need for another function. 3. Publicity - "Ah, THAT is the language which use ONE based indexing". 4. You can always write Your own dialect. Aleksander K. [alekk--obywatel--pl]

 [49/66] from: kenneth:nwinet at: 4-Jul-2001 6:44


Hi All ;-) Have I just been compared to a fly that eats s**t? Now wait a sec. We need to cool off. I say we give the minority a chance here. So lets all quiet down and give those folks that want to start indexing with some number *other* than one or zero a chance to speak! Anyone from the seven crowd have anything to say? Ok, now while they're talking I've got a serious question. (shh, no no, really, be quiet!) Does anybody know of a use for negative zero? Thanks to all for the riot (I just sent a letter to my fiancee telling her about how weird programmers are and is she sure she wants to marry one?) Regards, Ken. PS: then for the first time he notices that the thread is about correct behaviour and gets a chill up his spine.

 [50/66] from: chris:starforge:demon at: 4-Jul-2001 15:11


Ken Anthony wrote:
> Ok, now while they're talking I've got a serious question. (shh, no no, > really, be quiet!) Does anybody know of a use for negative zero?
Or, for that matter, how you'd even represent -0 on a normal, 2s complement signed arithmetic computer ;) Chris -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk

 [51/66] from: sanghabum:aol at: 4-Jul-2001 11:35


[Robbo1Mark--aol--com] writes:
> I did a quick language check last night and it seems > REBOL is now odd man out as far as zero indexing is concerned. > > I looked at Visual Basic, Pascal, Modula-2, C, C++, C#, Java, Javascript, > Perl, Python, Fortran amongst others and they ALL use zero based indexing. >
COBOL indexes from 1 too. I always knew my covert COBOL skills would be vindicated one day. --Colin.

 [52/66] from: joel:neely:fedex at: 4-Jul-2001 5:27


Hi, Ken, Ken Anthony wrote:
> ... I say we give the minority a chance here. So lets all > quiet down and give those folks that want to start indexing > with some number *other* than one or zero a chance to speak! > > Anyone from the seven crowd have anything to say? >
I had considered earlier mentioning that in Pascal (and ADA, IIRC), one is allowed to specify for each array the bounds of its subscripts. This can be highly useful in some settings. As a fairly trivial example, imagine reading a file containing data on junior-high and high-school students and tallying the number of students in each grade. (With apologies to our friends around the world, I'll stick with the US conventions with which I'm familiar!) Since those grades are numbered 7 through 12, it would be handy to be able to create an array containing only those indices, to avoid wasting space and performing explicit grade-to-index translation in my code. Ooops! That example actually started with seven! ;-)
> Does anybody know of a use for negative zero? >
IIRC the computers made by CDC back in the 60's and 70's used 1's-complement arithmetic instead of 2's-complement, which meant that negative zero was actually a possibility. This allowed for some interesting and subtle bugs, as witnessed by the fact that RFC 1624, "Computation of the Internet Checksum via Incremental Update" (May 1994), specifically stated A historical aside: the fact that standard one's complement arithmetic produces negative zero results is one of its main drawbacks; it makes for difficulty in interpretation. In the CDC 6000 series computers [4], this problem was avoided by using subtraction as the primitive in one's complement arithmetic (i.e., addition is subtraction of the complement). Apparently the current IEEE standard allows it as well. As for uses... 1) Since it is logically superflouous, one could use -0 as an indication of "no answer", provided one insured that no other computation (e.g., -1 * (1 - 1)) could produce -0 as a result. HEY!!! true = 1 false = 0 none = -1 NONONONO! (only kidding! ;-) 2) It appears to be a way to crash a Microsoft database! ;-) "If a SQL Server query returns a negative zero, and the client application binds the results as a SQL_C_DOUBLE, the following error is reported to the client: [Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification ... SQL Server is returning a negative zero, and the SQL Server driver is reporting this as an error. To reproduce the error run the following query: SELECT 0.0 * -1 ... Microsoft has confirmed this to be a problem in SQL Server 7.0." -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [53/66] from: jeff:rebol at: 4-Jul-2001 23:04


Howdy, Joel:
> "First" refers to the item in an ordered collection which > precedes all others.
Well, if you wish to define "first" that way, then what is the word 'Zeroth' found in the dictionary for? Does zeroth refer to those elements preceding those that precede all others (first)? If you can squarely locate the zeroth place I will understand much better your more consistent system of the free mind. I think you're a sly dog, slipping in an extra space there with out anyone noticing, no? Hah ha. "Start with zero except when using words to refer to positions, THEN start with FIRST and pretend ZEROTH doesn't exist..." sure.. ha ha. How consistent is that? Why, that's downright irregular, just conveniently assigning the zeroth element to FIRST. Tsk tsk. Weird, deformed, asymmetrical. :-) But seriously, I just think ZERO based indexing really is less intuitive (and one might argue from the history of mathematics, that the relative late "discovery" of zero is suggestive of the fact that humans weren't initially inclined to include zero in their numbering systems-- and it seems you're may be eager to dispose of our friend "zeroth" for the convenience of FIRST's definition. But perhaps I'm missing something-- like an unnamed slot in block of items (-:) Cheers-- -jeff

 [54/66] from: lmecir:mbox:vol:cz at: 5-Jul-2001 11:02


Hi, 1) there is no need to change AT to 0-based, because we have got SKIP 2) based?: func [ f [any-function!] block [block!] i [integer!] ] [ (index? block) + i - (index? f block i) ] a: skip [-1 0 1 2] 2 ; == [1 2] based? :at a 1 ; == 1 based? :at a 2 ; == 1 based? :skip a 0 ; == 0 based? :skip a 1 ; == 0 based? :at a 0 ; == 0 based? :at a -1 ; == 0 based? :at a -2 ; == 0 based? :skip a 0 ; == 0 based? :skip a -1 ; == 0 ==> AT is implemented inconsistently, because it is neither 1-based, nor 0-based! 3) if I look at the functions: FIRST, SECOND, ..., I found their behaviour natural 4) PICK looks OK as a generalization of the FIRST, SECOND, ... for 1<= index <= length? block 5) PICK is neither 1-based, nor 0-based (It is worse than AT, because it's got an "Emental Property" - see a "hole" at zero!). ==> Inconsistent. 6) PICK is "Too Consistent" for me in this case: pick [none] 1 ; == none pick [none] 2 ; == none 7) the following behaviour is inconsistent from the zero-based POV as well as from one-based POV: a: [1] remove a b: skip a 1 index? b ; == 1 while: a: [1] b: skip a 1 remove a index? b ** Script Error: Out of range or past end ** Where: halt-view ** Near: index? b There are two ways how to get a different behaviour here: 7a) define: skipped?: func [ block [block!] ] [ if error? try [return (index? block) - 1] [ (index? tail block) - 1 ] ] a: [1] b: skip a 1 remove a skipped? b ; == 0 7b) define a JUMP and JUMPED? functions having this property: a: [1] b: jump a 1 ; == [] jumped? b ; == 1 remove a jumped? b ; == 1 a: [1] remove a b: jump a 1 jumped? b ; == 1 This would have a capability of allowing any-base indexing, my Rebol Brothers. Howgh

 [55/66] from: joel:neely:fedex at: 4-Jul-2001 22:19


Hi, Jeff, The dried frog pills are in the way via FedEx... ;-) Jeff Kreis wrote:
> Howdy, Joel: > > > "First" refers to the item in an ordered collection > > which precedes all others. > > Well, if you wish to define "first" that way, then what > is the word 'Zeroth' found in the dictionary for? >
Because dictionaries simply document all of the things people say, without any obligation to make a simple, consistent system out of them, of course. I can also supply you a list of arbitrarily weird and contradictory quotations from the evening news, especially during election years! ;) I trust we haven't stooped to using an English dictionary as the basis for defining a programming language! Notice that English dictionaries have cleave, v.t.: to divide, pierce, sever, disunite cleave, v.i.: to split, separate, fall apart immediately followed (at least in mine, yours may use a different ordering -- no matter) by cleave, v.i.: to adhere, cling, be faithful (to) As both my Mathematics and Philosophy professors taught me, when I was a wee lad, A system which asserts the contradictory propositions P and NOT P can be used to prove anything, and therefore proves nothing. But the simplest test of usability is to show anyone (with no prejudicial prompting, of course) an ordered collection of items and simply ask, "Which is the first?" They will likely not find that a challenging question...
> If you can squarely locate the zeroth place I will > understand much better your more consistent system of > the free mind. >
I'm simply not interested in defining that term at all. Nor do I care to add PENULTIMATE to the REBOL lexicon, even though I can find *that* term in some dictionaries.
> ... the relative late "discovery" of zero is suggestive of > the fact that humans weren't initially inclined to include > zero in their numbering systems ... >
We've already covered this. The ancient greeks also didn't consider "one" a true number. Most people of the middle ages still believed that the sun revolved around the earth. The common man in the 1800's had never heard of a computer. In 2001, John Q. Public probably *still* uses neither "parse" nor "data type" in everyday conversation. And I'll be quite surprised if you claim to balance your checkbook using Roman numerals.
> ... and it seems you're may be eager to dispose of our > friend "zeroth" for the convenience of FIRST's definition. > But perhaps I'm missing something... >
Perhaps all of my examples have made my point too easy to miss... Natural language is fuzzy, messy, ambiguous, obscure, and nearly infinitely flexible. That makes it wonderful for conversation, jokes, wordplay, romance, and puns, but terrible for precision (as in treaties, contracts, or program specifications). Computer programming requires precision. Programming languages (along with most other things!) are more easily learned and used if their designs are carefully guided by the values of simplicity and consistency. To lull the newcomer into a false sense of security by offering familiar-looking terminology which is actually used inconsistent and highly subtle/complex ways, is to be penny-wise and pound-foolish IMHO. Neither "zeroth" nor "first" are friends of mine, especially if "first" is overloaded with meanings that have nothing to do with any logically inherent order (as with functions or objects). However, as a way of referring to the elements of an ordered collection, I submit that understanding "first" as meaning preceding all others is sufficiently intuitive as to need little explanation. (Regardless of addressing scheme.) Other languages have used other solutions, such as "head" to refer to the leading element in an ordered collection. If we are going to try to use common, everyday terms in our programming languages, I suggest that we should: 1) give preference to the most common ones (e.g. "first" being much more common than either "penultimate" or "zeroth", 2) scrupulously use those terms as precisely and consistently as possible, following the principle of least surprise, and 3) exercise severe self-control (I assume we won't be seeing definitions for "seventeenth" and "twentythird" in REBOL/View 1.3 ;-) Finally, I should thank you for putting to rest one other issue that has been troubling the list for some time... Based on your absolute insistence that "first" means 1, second means 2, etc., and the fact that
>> sort reduce [true false none]
== [none false true] we are now able to conclude confidently that none = 1 false = 2 true = 3 I'm greatly relieved to have this settled! ;-) -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [56/66] from: jelinem1:nationwide at: 5-Jul-2001 10:00


> Natural language is fuzzy, messy, ambiguous, obscure, and nearly
infinitely flexible. That makes it wonderful for conversation, jokes, wordplay, romance, and puns, but terrible for precision (as in treaties, contracts, or program specifications). Have you read Larry Wall's position on natural languages and computer languages (Programming Perl, Chapter1: an Overview of Perl, Natural and Artificial Languages)? This messiness and obscurity has created a very popular language. This language also uses zero-based arrays and requires holding down the [shift] key alot when coding. Don't mind me, I've been mentally mutilated from a previous language. ;) - Michael

 [57/66] from: jeff:rebol at: 5-Jul-2001 9:13


Howdy, Joel:
> But the simplest test of usability is to show anyone (with > no prejudicial prompting, of course) an ordered collection > of items and simply ask, "Which is the first?" They will > likely not find that a challenging question...
But they will apparently find it challenging if asked "which is the zeroth?"
> I'm simply not interested in defining that term at all.
Why? Why is it so hard to locate zeroth in your simpler system? It seems like zeroth would be a great word for zero based index systems, and yet you want to pretend it's not there, sweep it under the carpet. Tsk tsk. Where is zeroth? We have to conclude one of two (zero of one) things, in our zero indexed system: 1. zeroth position == first position 2. zeroth position comes before the first position. Easy enough right? The zeroth (first) proposition above is the only one that can be right while maintaining the definition of FIRST that you've made. So ZEROTH is FIRST, FIRST is ZEROTH. This is what makes zero based indexing so much more understandable!! The general ease for people to understand the concept of ZEROTH is concomitant with the ease of understanding zero based indexing. No need to hide our good and well suited word.
> We've already covered this. The ancient greeks also didn't > consider "one" a true number. Most people of the middle > ages still believed that the sun revolved around the > earth. . .
The argument is simply that zero based is less intuitive, not that people are incapable of groking it. People are capable of groking base 64, but few people, that I know of, balance their checkbooks in base 64. We commonly start numbering things by one. We teach our children to spread out their fingers and say "one two three.." Or do you teach children to say "zero one two.. " ending on finger nine? David Letterman counts down from 10 to 1 not 9 to 0, NASA does the same. Cars have gears starting with 1 through 4 or 5, not starting with gear zero. It's only some groups of programmers that think it natural to number things starting from zero. The rest of the world orders things starting with 1. Zero based indexing can only be justified based on what it gives you in terms of programming convenience. It can not be justified in terms of common usage. You have to weigh the utility of zero-based indexing against the relatively low "portability" of the concept. So how are we going to reindex date! values?:
>> 0-0-0
** Syntax Error: Invalid date -- 0-0-0 ** Near: (line 1) 0-0-0
>>
Oh come on, REBOL, don't complain about this invalid date! Why it's the zeroth (first) day, month, and year! Isn't that obvious?! Yesterday was: FOURTH of July, 2001, which would be:
>> 3-6-2000
== 3-Jun-2000 Clearly 3-6-2000 is the fourth day, the 7th month and the 2001st year (when we start from zero). Hey, since we're breaking all existing REBOL scripts in the interests of doing things "the right way", why not change the direction of evaluation? Left to right only makes sense in the western world. RIGHT TO LEFT is MUCH MUCH SIMPLER! Right to left is the "RIGHT WAY"!! [[item "Look at this!-->"] print][items of list] item foreach And, how about argument position? Surely it makes more mathematical sense to have the thing to operate with, followed by the thing to operate on, YES? blk: copy [] pick 0 skip -1 insert 0-0-0 blk Much clearer. Especially when we put it the "RIGHT" direction. [] copy blk: blk 0-0-0 insert -1 skip 0 pick Perhaps all statements should be parenthesized. REBOL's free format leads to tremendous ambiguity by offering familiar-looking text which is actually used in inconsistent and highly subtle/complex ways. Arity can become unclear. People should KNOW that they're really programming when they program, so we need parenthesis. ([] copy blk:) (((blk 0-0-0 insert) -1 skip) 0 pick) In fact, this whole concept of words is a little fishy. A given word may evaluate to who knows what. Very tricky, subtle/complex. Perhaps we should not allow people to directly use words but they'll call functions to get and put values based on a name. ("BLK" MAKE-NAME-VALUE) ([] copy "BLK" SET-NAME-VALUE) (((("BLK" GET-NAME-VALUE) 0-0-0 insert) -1 skip) 0 pick) I think it's obvious that if REBOL was like the above it would be cleaner, clearer, and more consistent. (: REBOL's getting easier to understand each day! Take the frog pills and seek the zeroth-- Cheers! -jeff

 [58/66] from: joel:neely:fedex at: 5-Jul-2001 12:16


Jeff Kreis wrote:
> David Letterman counts down from 10 to 1 not 9 to 0, NASA > does the same. >
NASA does, in fact, "count down" to zero. That's the point at which lauch occurs. To be more precise, NASA doesn't "count down" at all. The mission clock is initialized to a negative time, and counts forward (for successful launches, at least) through zero (the time of launch) and then into positive times as the mission proceeds. If you'll listen closely you'll hear this sort of thing: T minus one hour and counting... T minus fifteen minutes and counting... T minus thirty seconds and counting... leading down to T minus ten... nine... eight... where the "T minus..." part is probably omitted because it's hard for slow-talking Southerners to get all of that out in one second... ;-)
> It's only some groups of programmers that think it natural > to number things starting from zero. The rest of the world > orders things starting with 1. >
My watch (which tells 24-hour time) numbers hours as 0 thru 23, minutes as 0 thru 59, and seconds as 0 thru 59. REBOL seems quite willing to go along with that...
>> midnight: 00:00:00
== 0:00
>> type? midnight
== time! I asked a few of my friends, "How many children do you have?" and received answers summarized as follows: 0: 5 1: 1 2: 2 3: 1 So far everyone has found the above summary quite comprehensible. -jn- -- ___________________________________________________________________ The purpose of computing is insight, not numbers! - R. W. Hamming joel'dot'neely'at'fedex'dot'com

 [59/66] from: robbo1mark:aol at: 5-Jul-2001 13:20


JEFF, Are you saying then that almost ALL other computer languages get this wrong then by using zero based indexing? Their language designers & users too presumably have gone through all the same discussions and points that we've gone through this past week, assuming that these points have been discussed ad infinitum previously then why do you think that nearly ALL decided in favour of zero based indexing and that those who previously didn't are now shifting towards that position ie Visual Basic. YES Carl and YOU guys at RT are very smart & REBOL is really cool & a super language but are you really saying your smarter than nearly everyone who's gone before you on this quest? REBOL gets a lot of things right that other languages get wrong or make less intuitive but surely you must admit that zero based indexing aside we've discovered a LOT of inconsistencies & anomolies in REBOL behaviour in these discussions. There is still MUCH room for improvement in terms of the final language design of REBOL IMHO. Do you agree? cheers Mark Dickson In a message dated Thu, 5 Jul 2001 12:21:08 PM Eastern Daylight Time, Jeff Kreis <[jeff--rebol--net]> writes: << Howdy, Joel:
> But the simplest test of usability is to show anyone (with > no prejudicial prompting, of course) an ordered collection > of items and simply ask, "Which is the first?" They will > likely not find that a challenging question...
But they will apparently find it challenging if asked "which is the zeroth?"
> I'm simply not interested in defining that term at all.
Why? Why is it so hard to locate zeroth in your simpler system? It seems like zeroth would be a great word for zero based index systems, and yet you want to pretend it's not there, sweep it under the carpet. Tsk tsk. Where is zeroth? We have to conclude one of two (zero of one) things, in our zero indexed system: 1. zeroth position == first position 2. zeroth position comes before the first position. Easy enough right? The zeroth (first) proposition above is the only one that can be right while maintaining the definition of FIRST that you've made. So ZEROTH is FIRST, FIRST is ZEROTH. This is what makes zero based indexing so much more understandable!! The general ease for people to understand the concept of ZEROTH is concomitant with the ease of understanding zero based indexing. No need to hide our good and well suited word.
> We've already covered this. The ancient greeks also didn't > consider "one" a true number. Most people of the middle > ages still believed that the sun revolved around the > earth. . .
The argument is simply that zero based is less intuitive, not that people are incapable of groking it. People are capable of groking base 64, but few people, that I know of, balance their checkbooks in base 64. We commonly start numbering things by one. We teach our children to spread out their fingers and say "one two three.." Or do you teach children to say "zero one two.. " ending on finger nine? David Letterman counts down from 10 to 1 not 9 to 0, NASA does the same. Cars have gears starting with 1 through 4 or 5, not starting with gear zero. It's only some groups of programmers that think it natural to number things starting from zero. The rest of the world orders things starting with 1. Zero based indexing can only be justified based on what it gives you in terms of programming convenience. It can not be justified in terms of common usage. You have to weigh the utility of zero-based indexing against the relatively low "portability" of the concept. So how are we going to reindex date! values?:
>> 0-0-0
** Syntax Error: Invalid date -- 0-0-0 ** Near: (line 1) 0-0-0
>>
Oh come on, REBOL, don't complain about this invalid date! Why it's the zeroth (first) day, month, and year! Isn't that obvious?! Yesterday was: FOURTH of July, 2001, which would be:
>> 3-6-2000
== 3-Jun-2000 Clearly 3-6-2000 is the fourth day, the 7th month and the 2001st year (when we start from zero). Hey, since we're breaking all existing REBOL scripts in the interests of doing things "the right way", why not change the direction of evaluation? Left to right only makes sense in the western world. RIGHT TO LEFT is MUCH MUCH SIMPLER! Right to left is the "RIGHT WAY"!! [[item "Look at this!-->"] print][items of list] item foreach And, how about argument position? Surely it makes more mathematical sense to have the thing to operate with, followed by the thing to operate on, YES? blk: copy [] pick 0 skip -1 insert 0-0-0 blk Much clearer. Especially when we put it the "RIGHT" direction. [] copy blk: blk 0-0-0 insert -1 skip 0 pick Perhaps all statements should be parenthesized. REBOL's free format leads to tremendous ambiguity by offering familiar-looking text which is actually used in inconsistent and highly subtle/complex ways. Arity can become unclear. People should KNOW that they're really programming when they program, so we need parenthesis. ([] copy blk:) (((blk 0-0-0 insert) -1 skip) 0 pick) In fact, this whole concept of words is a little fishy. A given word may evaluate to who knows what. Very tricky, subtle/complex. Perhaps we should not allow people to directly use words but they'll call functions to get and put values based on a name. ("BLK" MAKE-NAME-VALUE) ([] copy "BLK" SET-NAME-VALUE) (((("BLK" GET-NAME-VALUE) 0-0-0 insert) -1 skip) 0 pick) I think it's obvious that if REBOL was like the above it would be cleaner, clearer, and more consistent. (: REBOL's getting easier to understand each day! Take the frog pills and seek the zeroth-- Cheers! -jeff

 [60/66] from: jeff:rebol at: 5-Jul-2001 11:32


Hello, Robbo:
> Are you saying then that almost ALL other computer > languages get this wrong then by using zero based indexing?
I don't think it's a question of wrong or right. As I said to Joel, previously: "Weigh the advantages of zero based indexing against it's lack of conceptual portability." The fact that people do use zero based indexing in some limited areas is immaterial compared to the areas where one based indexing is used, and no one seems to have argued otherwise. I haven't heard a 0-baser argue that 0-based indexing is what most people are used to in everyday life, only that people can understand it. Sure, we can understand lots of things.. This gets to justifications of REBOL design decisions. I'm not qualified to speak too broadly here, but I have had some experience with what goes into making design decisions in REBOL. One of the mainstays of REBOL's design is to prefer familiarity and intuition to "academic correctness". One big example is REBOL's free format. Free form is less "academically correct" because arity becomes ambiguous. What could the following be? foo bar baz It could be that foo is a function taking two arguments. It could be that foo is a function that takes one argument, and bar is a function that takes one argument... It could be that none of them are functions.. etc.. etc.. So if we're interested in academic correctness we can't have free form code, and scripts look ugly because we have to parenthesize everything, and then I enjoy coding in REBOL less since I now have to fully qualify everything because someone wanted correctness above all. ML is an academically correct language and it is such a pain to create even a simple program in, let alone one that builds GUIs, talks to the net, mines data, etc .. It's not a matter of right or wrong, or if it is, "right" for REBOL is more often defined as being better for more people, easier to use, friendlier to the eye and mind -- and often times that means that "academically correct" is "wrong".
> There is still MUCH room for improvement in terms of the > final language design of REBOL IMHO. > > Do you agree?
Eh.. I like to keep things in perspective. It may be more gratifying for you and those of the "REDESIGN REBOL" mind-set to characterize REBOL's design as very much incomplete. REBOL is a work in progress, true, but personally, I don't see where all this is getting us. Is this really an area crying out for great design improvement? Beyond that I don't see much "alternative" design being offered up that maintains or embraces the hard fought goals of REBOL. I mean, if you're just using vaguely defined notions of "right" and "wrong", "academically correct", or "all the other languages are doing it too" as justifications for your design, then I think you've totally missed the boat. I'm happy with the design decisions in REBOL because I know they were made very consciously, with out haste and always with the best of intentions. There's not a single simple formula to those decisions. Many times there has been much agonizing over the addition of even the smallest piece of functionality. But it's this great conscientiousness of design what makes REBOL such a swell language. It seems fairly obvious to me that the kind of REBOL others might build may not be as thoughtfully constructed -- though perhaps they might be more consistent. :-) -jeff

 [61/66] from: petr:krenzelok:trz:cz at: 5-Jul-2001 20:47


Hello Joel and all :-) first, - let me state, that I hate any kind of inconsistences and I expressed it here for several times. Maybe I am not struggling so much with zero vs one based indexing, like explanation of "polymorphism" of 'first function. Typical question - why should I use "first" on listen port? What will "second" do? I can see it more confusing then using if another 10 special function names existed for various cases. The most ugly part of rebol code is probably getting to objects words and values: "first next", second next . I remember even some discussion re new century. Some of us (including me), celebrated new century once 1999 changed to 2000, some of us, once 2000 changed to 2001. Why the heck 2001? It seems to me a little bit stupid :-) Once we born, we are at 0 .... 1day old, 1week old, 1month old, and we celebrate our 1st birthday at some 365th day. When do we celebrate 100th year of our birthday? Surely once we change from 99 to some + 365days. But, when we say something happened during our first year of life, we mean actually pre 1 period, I mean 0 to +365days. I saw so much flames, that I regard such discussions more philosophical, than practical. I think, that Rebol nowadays, needs completly different things to become more succesfull, usable, and all that ... async behavior, modules, add-on functionality (XML, SOAP), additions to View engine, Core etc. Change to 0 based indexing will not save our lifes here ;-) Cheers, -pekr-

 [62/66] from: jeff:rebol at: 5-Jul-2001 11:48


Howdy, Joel:
> NASA does, in fact, "count down" to zero. That's the point > at which lauch occurs.
They say "lift off" not zero, aye? 3 .. 2 .. 1 .. lift off! not 3 .. 2.. 1... 0... lift off! And rock and roll bands always start songs like: "a one.. a two.. a 1 2 3 4!" not "a zero ... a one .. a zero one two three!!" Maybe there are some bands that do that, but no one ever puts them on the radio because it's so weird sounding. :-) Rock and Roll is definitely one base indexed. -jeff

 [63/66] from: ingo:2b1 at: 4-Jul-2001 20:08


Hi Joel Once upon a time Joel Neely spoketh thus:
> Hi, Ken, > > Ken Anthony wrote:
<...>
> > > > Does anybody know of a use for negative zero? > >
<...>
> 2) It appears to be a way to crash a Microsoft database! ;-)
That's at least a very useful application, I vote to include -0 into Rebol ;-) Ingo

 [64/66] from: robert:lancaster:opennw at: 6-Jul-2001 10:17


Forgive me if I'm on the wrong thread for this observation.. but some people have used an example Number of children in a house hold. 0: 3 1: 5 2: 6 3: 1 4: 4 As an example of zero based indexing. I just think this is a little wrong. What I think you have here, is a number of categories. The first is zero children, the second is 1 Child..... It may be easy to program it into a zero based index. But the storage method does not reflect on the information the data represents. I think this idea is missing from current idea of converstiom. A Series! is basically an abstract data type. If you want to use zero based indexing.. Write your on abstract data type. p.s I also like being able not to write subract length? list 1 every time I write a for loop. He he ha ha he hoo ooo he.... ( Gives up fanactical laughing as he realises it his last day at work and won't be getting paid next month....)

 [65/66] from: joel:neely:fedex at: 6-Jul-2001 9:29


Hi, Robert, Robert Lancaster wrote:
> Forgive me if I'm on the wrong thread for this observation.. > but some people have used an example
<<quoted lines omitted: 5>>
> 4: 4 > As an example of zero based indexing.
Well, sort of... I offered it as an example of a situation where the natural sequence of values (call them "categories" if you wish) runs from 0 upwards, rather than from 1 upwards. Since it had been implied that such a situation would never occur to normal people (systems programmers and academics not being normal ;-), I thought I'd offer a normal-looking example.
> It may be easy to program it into a zero based index. But > the storage method does not reflect on the information the > data represents. >
You're absolutely correct. However, when our programming language allows us to express directly what we're dealing with in the problem domain, that's a very nice situation. As a concrete example (see the thread on "byte frequencies" for another), let's assume we have a block with trivial census data similar to the above example, and write some code to calculate the stats. census: [ "PM" 1 "HD" 0 "SE" 0 "SK" 3 "JV" 2 "AT" 3 "NJ" 2 "JD" 4 "TC" 1 "KK" 1 ] tally: func [ndeps [block!] /local tots] [ tots: array/initial 5 0 foreach [who kids] ndeps [ poke tots 1 + kids 1 + pick tots 1 + kids ] repeat ikids length? tots [ print rejoin [ikids - 1 ":" tab pick tots ikids] ] ] which performs
>> tally census
0: 2 1: 3 2: 2 3: 2 4: 1 My "mental model" of this tally is a collection of buckets labeled 0..4, but the code is sprinkled with "+ 1" and "- 1" because I can't use that model directly. -jn- ___________________________________________________________________ The purpose of computing is insight, not numbers! - R. W. Hamming joel'dot'neely'at'fedex'dot'com

 [66/66] from: robbo1mark:aol at: 6-Jul-2001 10:59


JOEL, Why can't you simply undertsand that your menatl model ( & mine 8) is a MUTILATION of REBOL. Arithmetic is GOOD for you, it expands the mind. cheers, Mark Dickson In a message dated Fri, 6 Jul 2001 10:44:42 AM Eastern Daylight Time, Joel Neely <[joel--neely--fedex--com]> writes: << Hi, Robert, Robert Lancaster wrote:
> Forgive me if I'm on the wrong thread for this observation.. > but some people have used an example
<<quoted lines omitted: 5>>
> 4: 4 > As an example of zero based indexing.
Well, sort of... I offered it as an example of a situation where the natural sequence of values (call them "categories" if you wish) runs from 0 upwards, rather than from 1 upwards. Since it had been implied that such a situation would never occur to normal people (systems programmers and academics not being normal ;-), I thought I'd offer a normal-looking example.
> It may be easy to program it into a zero based index. But > the storage method does not reflect on the information the > data represents. >
You're absolutely correct. However, when our programming language allows us to express directly what we're dealing with in the problem domain, that's a very nice situation. As a concrete example (see the thread on "byte frequencies" for another), let's assume we have a block with trivial census data similar to the above example, and write some code to calculate the stats. census: [ "PM" 1 "HD" 0 "SE" 0 "SK" 3 "JV" 2 "AT" 3 "NJ" 2 "JD" 4 "TC" 1 "KK" 1 ] tally: func [ndeps [block!] /local tots] [ tots: array/initial 5 0 foreach [who kids] ndeps [ poke tots 1 + kids 1 + pick tots 1 + kids ] repeat ikids length? tots [ print rejoin [ikids - 1 ":" tab pick tots ikids] ] ] which performs
>> tally census
0: 2 1: 3 2: 2 3: 2 4: 1 My "mental model" of this tally is a collection of buckets labeled 0..4, but the code is sprinkled with "+ 1" and "- 1" because I can't use that model directly. -jn- ___________________________________________________________________ The purpose of computing is insight, not numbers! - R. W. Hamming joel'dot'neely'at'fedex'dot'com

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted