World: r4wp

Another case of the common case is that Red's intended common audience 
is common people, not mathematicians. While R3 "works" for mathematicians, 
R2 is the one that works for common people

So, if we consider Peter Wood a "common man"(no offense intended), 
do you state that his solution works?

I already stated I'm not talking about your mathematical exercise, 
but about common programming patterns in REBOL, such as series/-1

OK, so you feel offended that Peter considered my exercise worth 
trying?

Not at all

Kaj is write I wouldn't write such a function.

...but you did...?

To oblige you, because Peter is such a nice commoner :-)

I do not think he really felt obliged?

Also, optimization (as many programmers know) is not about making 
something incorrect or non-working. It is about making something 
better in some sense.

Yes, and that's what Andreas' formulation of the ordinal! proposal 
does

Well, I would state that my task looks like a "simple enough task 
to tackle", and the one even inexperienced users (surely not only 
mathematicians) should be able to tackle, and they would, as Peter 
demonstrated, if the index arithmetic weren't broken.

That's not the point; as Peter said, a common REBOL programmer wouldn't 
program this function exactly because there are better solutions

Give us a better solution than PICK/POKE then.

One note: as far as I can tell, s/-1 is not a common pattern at all, 
but rather a quite "uncommon" one in as far as it is rarely encountered 
in real REBOL code. FIRST and /1 are the common patterns, which are 
not touched by R3.


Actually, the only thing different in R3 that arguably "works for 
common people" in R2 is this uncommon pattern of s/-1 and s/-2. Every 
other use of negative indices is broken in R2 (and as such, works 
for neither mathematicians nor common people) but works in R3.

I really don't care about path syntax with computed indexes, it's 
ugly and awkward, and broken because of the 0 hole. I'd really rather 
use a function. As long as we get PICKZ/POKEZ, I'll be good. We already 
have SKIP to act as a non-broken AT. But at least plug the hole with 
a triggered error, so it won't mess people up silently. It's a huge 
failure, at least make not fail silently.

As Ladislav demonstrated, 0-based is better anyway for computed indexes, 
so PICKZ and POKEZ would be better to use even if PICK and POKE didn't 
have the hole

Nenad already counted a lot of occurrences of /-1 in Red. Most others 
have failed to contribute analyses of real code

14 occurrences of /-[1-9] in current Red sources, 1 is from makedoc2.

Which means that either Doc prefers path syntax over function syntax, 
or path syntax was implemented first, or both. Nonetheless, it's 
real code of any significant complexity, so it probably includes 
backward index use.

I just counted three occurrences in PowerMezz, and two occurrences 
of /-2

Most Red code is currently R2 code, so implementation order doesn't 
come into it

Just for comparison: Red's sources are 13k lines (including whitespace 
and comments) of code.

The preference then. So, at least 2 people like to use path syntax 
(PowerMezz was written by one guy). It was bound to happen that someone 
wouldn't find that syntax ugly :)

The above counts are not about path syntax, but specifically about 
_negative indices_ in paths.

In the ancient (!!) rebol.org snapshot I have locally, I counted 
11 occurrences in 8 files (blog, new-blog, make-doc, make-doc-pro, 
makedoc2, json, translate, xml-dom) in a total of ~1000 files and 
255k lines of code.

Yup, that's what I think is ugly, almost as bad as paths with parens. 
That's why I tend to use PICK when I'm doing negative indexes.

Personal preference :)

Same code though.

People have been discouraged to use fixed path indexes because they 
are supposedly slower in R2 than FIRST and such, but I like path 
syntax because it is shorter and unambiguous

Just to make myself more clear for "common people": I think that 
the programming language should be designed so that "common people" 
should not need a specialized mathematical training to be able to 
define the HEAD-INDEX? function; rather I think that they should 
be able to successfully tackle a problem of such a low complexity 
without any problem. Also, I noticed that Kaj's opinion differs.

They were slower in R2. I think that they're faster in R3.

That's what I said

supposedly
 :)

Brian, just for the record, I find your proposal reasonable and pragmatic.


If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices 
and falling into the 0 hole. Maybe a bit egoistic, but well.

The reason I'm not finding negative indexes in paths in my own CMS 
code is that I had to replace them because they're not compatible 
between R2 and R3

If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices

 - if I know you well, you would actually explain to them the advantages 
 of the simple approach (especially when being asked about some index 
 arithmetic problem), and I am sure that the "reasonable souls" would 
 join you soon, and the others would either stop programming in the 
 language or follow suit as well.

Hopefully :)

I'm not bothered by the zero hole, but I was bothered by R3 being 
incompatible

I was bothered by them not fixing AT in R3 as well. There's a lot 
wrong with R2.

Bug-for-bug compatibility is overrated. But if the 0 hole was restored 
to R3, as triggering an error, I would be more than happy to have 
R2 trigger the same error.

..but you did...?

 - people do crosswords, sudoko and play mindless computer games too.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s]]]


This should also return none if i is 0, which replicates the hole.

Wait, it's supposed to return the index, not the result.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s] i = 0 [0]]]

The hole roams with the position of s, so the result would be a constant 
regardless of that position.

Welcome to R2 index arithmetic :-/

Yes, Brian is right, that is R2 index "arithmetic", the only problem 
is that CASE is not "arithmetic", as you might have guessed.

That is the "broken arithmetic workaround" that can be used. However, 
my point was: "Why use the broken arithmetic and make common people 
unable to solve this task, which should be actually trivial for anybody 
to solve?". Kaj's answer to this question above actually is: "because 
its intended audience is common people". Phew!

You keep ignoring the ordinal! solution

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?