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

World: r4wp

[#Red] Red language group

Andreas
16-Nov-2012
[3749x2]
0 is before 1, so pick 0 should give you the element before 1.
Actualy, as Ladislav repeatedly explained, having "pick -1" _not_ 
giving you the current element is just as awkward.
BrianH
16-Nov-2012
[3751]
Andreas, oh good, whew. In R3 we're already having to replace all 
system options that affect MOLD with options to the MOLD function 
itself. It would be a shame to have to do the same for all of the 
indexing functions. Nonetheless, that meaning of BASIS? doesn't make 
sense for the name either, so I don't like it.
Andreas
16-Nov-2012
[3752]
You can basically do:
- no 0 or negative indices at all

- disallow 0, have 1 return the next element forward, -1 the next 
element backward (R2)

- disallow 0, have 1 return the current element forward, -1 the current 
element backward

- allow 0, have 1 return the next element forward, 0 return the element 
before that


All have their advantages and disadvantages. All require explaining 
and may not be obvious depending on what you expect.
DocKimbel
16-Nov-2012
[3753]
Yes, but that's not how my brain see it by default, I need to make 
a conscious effort for that. Also, I might be tempted to then use 
0 to access the first item instead of 1...This is a pitfall where 
almost every new (and maybe some older too) will fall in.
Andreas
16-Nov-2012
[3754x2]
Yes, but don't try to generalise from your brain to "most" or "new" 
users.
The only somewhat arguable generalisation is to "those who are well-used 
to R2's behaviour".
DocKimbel
16-Nov-2012
[3756]
I know, but I must try to put myself in future Red users shoes to 
be able to make decisions.
Andreas
16-Nov-2012
[3757]
I think for future Red users, R2's model is actually the worst choice.
BrianH
16-Nov-2012
[3758]
If we do R2's behavior, make sure that PICKZ and POKEZ exist so I 
have something to use. They can call PICK and POKE internally. I 
need something that does computed indexes/offsets, and I can't afford 
to have a hole in the list (0 for R2), and I can't count on the port 
scheme supporting SKIP.
Andreas
16-Nov-2012
[3759]
Just erroring out on index 0 is ann improvement.

Making "pick 1" and "pick -1" return the same element is an improvement.
R3's behaviour is an improvement.

R2's messy behaviour with a clean set of SKIP, PICKZ, POKEZ is an 
improvement.
BrianH
16-Nov-2012
[3760]
If I'm not doing computed indices/offsets, or doing negative/0 offsets, 
or using using port scheme4s where PICK/POKE mean something different, 
then I don't use PICK/POKE at all.
DocKimbel
16-Nov-2012
[3761]
and I can't afford to have a hole in the list

 Brian, could you give us some short code cases where this was a problem 
 for you? This would really help.
BrianH
16-Nov-2012
[3762]
pick ser idx + off
DocKimbel
16-Nov-2012
[3763]
Just erroring out on index 0 is ann improvement.

 That's my intention for Red until we get a consensus on a better 
 overall solution.
Andreas
16-Nov-2012
[3764]
We won't get consensus on this.
DocKimbel
16-Nov-2012
[3765]
We won't if we stick to only R2/R3 options. Fortunately, there are 
other ones, maybe we'll find more.
BrianH
16-Nov-2012
[3766]
Sorry, I didn't mean off in the sense of false, I meant short for 
an offset. Any place where you have computed indexes can have a computation 
that turns out to be less than 1, especially if your base position 
is offset.
Andreas
16-Nov-2012
[3767x2]
Error out and add PICKZ, POKEZ while at it. That would at least give 
us a base to work with.
The problem with keeping most of R2's behaviour much longer is that 
switching to something different will only get harder.
DocKimbel
16-Nov-2012
[3769]
Agreed.
BrianH
16-Nov-2012
[3770]
Remember, R3's behavior isn't done either. There's a standing consistency 
bug, for instance. If we come to a consensus, R3 is likely to adopt 
it too.
Andreas
16-Nov-2012
[3771x2]
So if, for example, we were to switch to 0-based indices-as-offsets 
complemented with an ordinal! type, it's better to do this sooner 
rather than later.
BrianH: CC for this consistency bug?
BrianH
16-Nov-2012
[3773]
http://issue.cc/r3/609
Andreas
16-Nov-2012
[3774]
Thanks.
BrianH
16-Nov-2012
[3775]
I wouldn't even mind if PICKZ/POKEZ were the actions and PICK/POKE 
were the native wrapper functions. Not as pretty for port scheme 
implementors though.
DocKimbel
16-Nov-2012
[3776]
Brian: in `pick ser idx + off`, how often do you need `idx + off` 
to give you both positive and negative results from the same expression?
BrianH
16-Nov-2012
[3777]
Usually, the number I'm passing to PICK or POKE is computed elsewhere. 
That was a one-line example for simplicity.
DocKimbel
16-Nov-2012
[3778x3]
I would just like to know if it's an issue (the 0 gap) you hit once 
in your lifetime or if it's something people encounter from time 
ot time or even often (depending on the coding style).
(just curious)
We should write a short-list of possible options that would solve 
the whole issue and see if we can get a large consensus on one of 
them. Anyone kind enough to extract the different options we've discussed 
and put them somewhere online with the main pros/cons?
BrianH
16-Nov-2012
[3781x3]
I use computed indexes for computed lookup lists, such as for precomputed 
intermediate results of computations, translation tables, etc. If 
the computation uses signed numbers, you have to do an offset base 
position to get the results from the positions less than 1. Having 
a hole slows down the computation because it has to be handled in 
mezzanine code. PICKZ/POKEZ would actually be better for most of 
these situations because the computations work better with 0-based 
numbers (modulus, for instance). It's pretty common in code that 
actually *needs* to use PICK/POKE on series.
I've found that aside from computed indexes, the only times I use 
PICK/POKE on series are for negative/0 indexes, or indexes greater 
than 10. For the rest the ordinal functions are faster.
Of course port schemes and datatypes actually need to implement PICK/POKE, 
but at least for datatypes the implementation is usually native so 
the hole is less expensive to implement.
Andreas
16-Nov-2012
[3784x2]
It's pretty common in code that actually *needs* to use PICK/POKE 
on series.


That's the sticking point. We can categorise the uses for PICK/POKE:

(a) with large positive literals
(b) with literals -1, -2
(c) with computed indices and series in "head position"
(d) with computed indices and an offset series
More categories welcome.
DocKimbel
16-Nov-2012
[3786]
Having a hole slows down the computation because it has to be handled 
in mezzanine code.


Have you ever had to actually write such "0 gap" workaround in your 
code, or is Carl the only one that had ever been bitten by this isssue?
Andreas
16-Nov-2012
[3787]
I think it's more common to rewrite the code to something different, 
where possible, than to try and workaround the 0 gap.
BrianH
16-Nov-2012
[3788x2]
Anyone who does computed indices from offset base positions would 
run into that issue. However, given that this only tends to happen 
in heavy-math code, I wouldn't be surprised if Ladislav and I would 
be caught by it more often than anyone else in the REBOL community, 
even Carl.
Maybe the other Saphiron guys too.
Andreas
16-Nov-2012
[3790x2]
It will also happen in data-heavy code.
E.g. pure-REBOL database implementations an such.
BrianH
16-Nov-2012
[3792]
I use that pattern in structure-tricky code, like those databases 
Andreas mentioned.
Andreas
16-Nov-2012
[3793]
I'm pretty sure I ran across this problem when trying to implement 
a triple store ages ago (and ended up switching to a different implementation 
approach).
BrianH
16-Nov-2012
[3794x2]
I'm not as much of a math head as Ladislav, so I can't always do 
the algebraic transformations necessary to switch to unsigned arithmetic.
Strangely enough, Red's native code compiler means that I'm more 
likely to use it for this than I would REBOL. Mathematical computation 
isn't REBOL's strong suit.
DocKimbel
16-Nov-2012
[3796]
Brian: that's also the kind of usage where Red should give you the 
best performances, as math expressions can be highly optimized.
BrianH
16-Nov-2012
[3797]
Yup. But that doesn't mean that I can switch to unsigned arithmetic. 
For that matter, sometimes switching to unsigned arithmetic means 
mostly indices at the top and bottom of a large range, skipping the 
middle (basically what you'd have to do with the Python model). By 
"large" I mean allocating a 2GB series or more and only using the 
100MB or so at both ends. Not always a good idea.
Oldes
16-Nov-2012
[3798]
If you don't want to be hit by the pick 0, you can stay at head position 
of the series cannot you?