World: r3wp

its like reading... there is nothing here and here too  hehehe  I 
see none like a portable hole (remember in bugs bunny ;-)

:)

the irony of the portable hole, is that you can actually Take the 
hole... a pretty nice oxymoron  ;-)

(I mean grasp it, move it around)

So the question is whether we want /skip < 1 to be an out of range 
error, like DIFFERENCE, or to constrain to 1 silently, like MOVE.

I say it should react the same as skip > length of series.

Nah, Bugs Bunny had just figured out how to manipulate higher dimensions. 
:-) No wonder Elmer Fudd can't beat him.

Not the same thing. If you have skip > length of the series, it will 
only do one iteration and your access to the results off the end 
will usally be none, unless you constrain it yourself. The question 
is whether negative skip should be silently constrained or generate 
an error, as a general rule.

By the way, when you have 1-based indexing, 0 is a negative index 
:)

yep... not the best for the math in index calculations.... hehehe 
but much more human readable for code and human interaction, so I 
still prefer one indexing after 9 years... even if the techy in me 
sometimes lets out a little <sigh>  in trying to get to the proper 
start/end of complex series extractions  hehehe

well, I just realised that it should do the exact same as for the 
end... if you are not currently record  aligned  and are doing reverse 
operations, its possible you'll encounter incomplete records at the 
start.f

having an error in this case would make it toocomplicated to code 
around the error, methinks

so fill with nones. to prevent the start of the records to shift 
and corrupt the first record.

the algorythm using the /skip is responsible for ensuring that it 
treats the unaligned first value in any case... but the algorythm 
will much simple to write if the offset which is returned by the 
use of /skip doesn't change.

if we align to first item of the block, then what would be the third, 
will become something else, when you hit the head of the series.... 
this adds a lot of complexity to the loop for nothing I think.

Maxim, once you have 1-based indexing (which we are stuck with for 
historical reasons), then having 0 be negative *is* the best for 
math calculations. That way you can count on offset = index - base.

but functions like insert are a bit simpler to use with 0 based, 
since a length is used as the value past an item in a series not 
the last character in it.


they both have advantages.   but trying to explain to someone that 
an index of 0 moves backwards isn't very obvious to promote as a 
feature ;-)


I'd have trouble justifying this to my kid which is learning to do 
math  :-D

brian: any reflections on my post regarding the /skip past start?

/skip is a length, not a index or an offset. I'm not sure what effect 
/skip past start should have.

an example?

gimme me a minute will try to build a little example.

No, I just don't know which post you are talking about so I don't 
get what you are saying.

hum... implementing an example to show, I realise that using skip 
should return an error in the case of series, cause alignment is 
broken, just like sort.

ex:

a: next "1234567890"

probe head move/skip a 4 2

== "1456789023"

in reality there should be something between 0 and 2  if "23" was 
to keep its alignment with its original position within the series.

this sort of stumps me philosophically on how to manage the /skip 
in either direction when you go past bounds.

with blocks we could decide to add nones, but would it be any usefull?

same for going beyond head.

I guess the best action to take is to specify explicitely that /skip 
is meant to handle records when they are aligned. results of un-aligned 
/skip operations are un-defined at best.

(they are aligned === when the series is aligned with the records)

with this detail in place, and with blocks, I'd say it would be usefull 
to pad with nones.

Give me a moment and I can answer your concerns.

with strings... I guess you stick to head.

to create an empty record set of 30 records would be as easy as:

rs: move/skip [] 30 3

I have difficulcy to get Chat files. I do nf, to list new files, 
then I submit get * but nothing is synced. I try other aproach, going 
to e.g. R3 mezzanines section, and doing get * does either report, 
that there was no change to files, or that my local copy is changed, 
and hence it can't be synced. I am sure I did not do any local changes 
here ... So - how do you usually work with Chat file facility?

I usually purge the directory when I'm not working on the files. 
Then when I want to work with them I get the specific files I want 
to edit, edit them, test them locally, submit the changes, then empty 
my work directory. If my submission sucks I deny it, if it is good 
I accept it.

If I want to keep local versions to compare to I keep them in another 
directory, then compare to the changes made by others. I only need 
to do this when I am working on the same file that others are working 
on, usually a sign that there is too much in the file (it needs to 
be broken up), or that I need to do a better job of talking to the 
other person.

Situations like that are why DevBase and chat are integrated now.

OK, Maxim, the MOVE/skip example you specify is not an error in MOVE, 
it is an error in the code calling MOVE in that example. MOVE was 
specifically designed to do something useful in that case, rather 
than generate an error.


The whole reason that MOVE takes one position and one offset is because 
that limit gets rid of a host of potential aliasing errors. MOVE 
is designed to be the most efficient and safe solution to the problem 
of moving stuff, and it should *never fail* unless the series is 
protected from changes. MOVE is a DWIM function: Do What I Mean. 
This goes for treating negative /skip lengths as an error too - having 
it magically constrain the /skip length to 1 or greater was a deliberate 
design choice, the result of a lot of discussion.


So the question is whether the error of having /skip lengths being 
less than 1 is worth worrying about, worth the overhead of generating 
an error and checking for that error every time you use the function. 
Don't be fooled, that overhead is really significant.


We've already changed other functions so they don't generate errors 
anymore, and just DWIM, like FIRST not complaining about bounds and 
acting like PICK 1 now. These changes have made these functions faster, 
and better to use. Generating an error is considered something to 
do when it is really important, as it sometimes is. How important 
is the /skip < 1 error?

you have been talking about the actual /skip parameter value, and 
all along I was talking about the effect of using /skip which causes 
the function to go outside of bounds of the series based on the skip 
size... 

doh!   hahahaha

I was so off, I could have landed in ireland, while trying to go 
to the corner store!  ;-)

No, I got that about your example. The behavior you describe was 
deliberately chosen.

The behavior that Henrik is concerned with is /skip lengths < 1. 
MOVE was designed to just up that to one, DWIM.

but *I* didn't get your point  ;-)

/skip size < 1 should effectively just be bound to 1


as long as its explicitely documented.   there is no real use in 
/skip < 1

and I understand that adding too much verification to series handling 
code really slows the whole a lot.

cause its exponential in the long run.  1 % becomes 1.5 then 2.  
the slowdown rate accelerates as mezz code uses other mezz code.

its like when I discovered that using 'RETURN was slowing down some 
code I had by more than 20%!

is 'RETURN any faster in R3, btw?

The problem is that DIFFERENCE/skip < 1 generates an error, and every 
other function /skip < 1 hangs. So the question is whether they should 
*all* be changed to act like MOVE (silently DWIM), or all be changed 
to act like DIFFERENCE (generate an error).

tough call, but if it can't lead to data corruption, I'd say the 
later.

No, RETURN, EXIT, BREAK, CONTINUE and error throws are just as slow 
in R3. It's the setjmp/longjmp exception frame overhead.