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