• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Andreas
15-Nov-2012
[3533]
The problem with no meaningful index 0 is that potentially meaningful 
index values are no longer isomorphic to integers. And as REBOL has 
no actual datatype for indices, all we can compute with are integers 
while relying on a correspondence of those integers to indices.


If you only ever compute indices for series positioned at the head, 
you get a nice correspondence of integers to indices, because meaningful 
indices for this series correspond to the positive integers.


But if you also want to compute indices for series positioned elsewhere, 
this nice integer-to-index correspondence breaks down as you suddenly 
have an undefined "gap" for the integer 0, whereas negative integers 
and positive integers are fine.
Kaj
15-Nov-2012
[3534]
Yes, ordinal! would fix that, or the index! I proposed earlier
Andreas
15-Nov-2012
[3535]
I also think that an ordinal! (or index!) datatype may be an intriguing 
possiblity to get the best of both worlds.
DocKimbel
15-Nov-2012
[3536]
Andreas: do you have a short code example involving index 0 in computation? 
I don't remember ever having issues with index 0 and I use series 
with offsets a lot! Though, Ladislav claims he and Carl did encounter 
such issue at least once...the use cases for this issues remain a 
mystery well kept by Ladislav. ;-)
Andreas
15-Nov-2012
[3537x2]
I personally avoid computing with non-head positioned series wherever 
possible.
So sorry, I don't have a particular example at hand, but I can easily 
imagine it coming up with e.g. forall or forskip and trying to access 
previous values in an iteration.
Ladislav
15-Nov-2012
[3539]
Though, Ladislav claims he and Carl did encounter such issue at least 
once

 - I am claiming that I have revealed a bug in Carl's code caused 
 by the fact that indices are not isomorphic to integers, i.e. they 
 "contain a gap". That is a totally different issue than whether indexing 
 should be 1-based or 0-based.
DocKimbel
15-Nov-2012
[3540]
Ladislav: I think it is relevant to this topic as findind out if 
the index 0 gap is a real practical issue or not, could help decide 
about the indexing base.
Ladislav
15-Nov-2012
[3541x6]
Then: gap is a practical issue, causing bugs.
(no matter whether indexing is 0-based or 1-based)
That is caused by the fact that there is no gap in the series, the 
gap is only caused by "unreasonable thinking".
Also, if we define 0-gap (possible) then we do not have any right 
to use negative indices.
, i.e. the gap needs to be prolonged to infinity, otherwise we are 
simply inconsistent
I'm inclined to continue on the one-based convention that worked 
pretty well in R2 for many years
 - actually, R2 is "hybrid", since SKIP is zero-based, in fact.
DocKimbel
15-Nov-2012
[3547]
Can you define "unreasonable thinking"?
Andreas
15-Nov-2012
[3548]
Have a look at the following illustration:
https://gist.github.com/5af73d4ecf93ac94680a
DocKimbel
15-Nov-2012
[3549]
SKIP works with offsets only, it's not related to indexing.
Andreas
15-Nov-2012
[3550]
About the only somewhat reasonable use I can come up with for R2's 
behaviour is that to allow writing literal -1 indices in paths (values/-1) 
to access the value preceding the current position.
Ladislav
15-Nov-2012
[3551x3]
Yes, I can in this case: "unreasonable thinking" here is the fact 
that the "mathematical model" - in this case the numbering of positions 
in series differs substantially from the properties of the object 
it is modelling - in this case there is a difference between the 
"no-gap in the series" versus "gap in the mathematical model".
Also, there is one more mathematical inconsistency: if I "hate zero", 
I simply cannot use negative numbers, otherwise I am being inconsistent.
SKIP works with offsets only, it's not related to indexing.

 - that is not true, in fact. It *is* related to indexing, since we 
 may always use PICK SKIP SERIES N M versus PICK SERIES K and these 
 things are realted, like ir or not.
DocKimbel
15-Nov-2012
[3554]
 in this case the numbering of positions in series differs substantially 
 from the properties of the object it is modelling


Is this again the "inbetween position" vs values counting intepretation 
difference?
Andreas
15-Nov-2012
[3555]
No.
Ladislav
15-Nov-2012
[3556]
No
DocKimbel
15-Nov-2012
[3557]
Ok. :-)
Andreas
15-Nov-2012
[3558x3]
It is because the series values actually are a contiguous concept, 
but their respective indices are not a contiguous space of integers.
Which is, frankly, awful when having to compute with indices with 
integers.
... when having to compute indices with integers*
Ladislav
15-Nov-2012
[3561]
Numbering positions in a series is, in other words, characterized 
as "mathematically modelling 'positions' in a series". Your "inbetween 
positions" are something that does not exist in the series in fact.
Andreas
15-Nov-2012
[3562]
Even if you talk about "inbetween", there is _no_ integer in between 
1 and 2, but there is an integer between -1 and 1.
DocKimbel
15-Nov-2012
[3563]
Tail position is inbetween, underlying implementation details cannot 
change that fact.
Ladislav
15-Nov-2012
[3564x2]
Tail position is inbetween - actually not. You can write: INSERT 
TAIL SERIES #"a". You do not insert the character "inbetween", in 
fact.
Also, the SKIP function demonstrates the same behaviour quite well 
and consistently.
Andreas
15-Nov-2012
[3566]
tail position

 is actually a misnomer, in as far as it corresponds to no proper 
 index of a series. The special behaviour series seen in some functions 
 when operating on series in "tail position" would warrant "tail mode" 
 as a more sensible description of the state the series is in.
Ladislav
15-Nov-2012
[3567]
as it corresponds to no proper index of a series

 - I reserve the right to disagree. INDEX? TAIL gives some correspondence
Andreas
15-Nov-2012
[3568]
Yes, it gives an index that can I'd consider "improper" for the series, 
in as far as the series does not contain a value at that position.
Ladislav
15-Nov-2012
[3569]
that is arguable, while the INDEX? TAIL is not arguable, giving actual 
correspondence
Andreas
15-Nov-2012
[3570]
A rather meaningless correspondence, though.
DocKimbel
15-Nov-2012
[3571]
Subjective interpretations of series tail position are possible, 
as TAIL position exists without pointing to any value.
Andreas
15-Nov-2012
[3572]
(And an index that does not correspond to a value in the series, 
at this point in time.)
Ladislav
15-Nov-2012
[3573x2]
It is not meaningless as far as I am concerned. Reson: it would be 
meaningless only if you agreed that INDEX? should not yield a value 
for TAIL
Actually, I can demonstrate that even past-tail indices are meaningful 
for blocks, and I did.
Andreas
15-Nov-2012
[3575]
Actually, what I was trying to say is that the discussion of "tail 
position" unnecessarily clouds the discussion.
DocKimbel
15-Nov-2012
[3576]
http://www.rebol.com/r3/docs/concepts/series-traversing.html


The first position of the block is called its head. This is the position 
occupied by the word red. The last position of the block is called 
its tail. This is the position immediately after the last word in 
the block. If you were to draw a diagram of the block, it would look 
like this: [...] Notice that the tail is just past the end of the 
block.

Too bad the images are missing...
Ladislav
15-Nov-2012
[3577x2]
Well, that is arguable....
(I meant that as a reaction to Andreas' contrib above)
Andreas
15-Nov-2012
[3579x2]
Yes, that's certainly arguable. I say that because I think that "head 
position" and "tail position" sound like dual concepts, whereas they 
are not.
Image is here:
http://www.rebol.com/docs/core23/rebolcore-6.html#section-1.1
Ladislav
15-Nov-2012
[3581]
The first position of the block is called its head.
 - that is actually false
DocKimbel
15-Nov-2012
[3582]
Hasn't Carl wrote that? :-)