World: r3wp

just my 2 cents :)

Yes, but he wants it to repeat.

on large datasets a copyless repartitioning would be more efficent 
more like adding pointers to delimiters within the block

If you want it to speed up, use until.

argh, i meant until, not unless

grrrrrrrrrrr.....

Tomc, you can't do copyless and get subseries, but you can build 
a block of before and after references.

thanks steeve  that is about  what I am doing  but while[ not tail 
block ] [change...

brian yes that is what bugs me

if it was in a file  or an un loaded string I could insert  brackets 
to my hearts content . but not once i start useing it.

new: make blk 2 * divide length? blk span
while [not tail? blk] [
	new: insert/only insert/only blk blk: skip blk span
]
new: head new

Then use /part references.

uh !?

make blk -> make block!

not only that :)

The resluting block will be pairs of references to the beginning 
and end of his subseries. He can then get any subseries he needs 
by referencing it using the beginning and references with the /part 
option of COPY or INSERT, though using CHANGE or REMOVE will mess 
up the offsets of any subsequent references unless he is referring 
to a list! type.

a rose by any name ....  new and block both end up with the data 
so it is still copying

No, you are not inserting copies, you are inserting *references to 
the original*.

ok Brian, but still missing something, (insert/only new) :)

Yeah. I am actually working on something else right now, so errors 
are to be expected here.

Ahhh! I see  hmmm  I think all I will  need to do is reorder *between* 
references and subject those  sub-blocks 
 to further partitioning

The new block is really an index (in the database sense). You can 
sort and manipulate the index, then use the result to build a new 
version of the data if you like.

yep

the only thing you can't do is a mold or a form of this index :)

I'm backporting the last of the R3 reflection functions to R2 right 
now...

TYPES-OF - it's a nasty one to implement.

what are the costs when a (sub)block is reordered ?

skiped or sorted ?

both actually

You want to make all of your planned changes to the index, then build 
them all at once into new data.

Otherwise the positions get messed up.

skiping a block has no cost (no data modified), sorting has cost 
(data modified)

SORT with a custom compare function would be fast to use here.

positions get messed up if and only if the end points of the sub 
range are shuffled in the sort ...

and as their index can be known  beefore hand they can be reset if 
needed. i think

No, positions get messed up if the length of the data series *anywhere 
before the position* changes. The only datatype this is not true 
for is list!, which is not future compatible.

but reordering should not change a length

but if the sort on the default data block is applied with a skip 
size equal to your span, then positions are not messed up, is that 
what you mean ?

in that case, it's right

Reordering will change the length of the portion of the series before 
the moved segments, depending on where they are moved.

but not if he's sorting data with a skip size equal to the span

However, sorting the index won't change any of the references that 
the index is pointing to, because the underlying data doesn't change. 
Once you are done sorting and manipulating your index you can commit 
the changes, which means building new data from the index references.

all movement between (and including ) two reffrences stays between 
those same two reffrences

and yes the span (# of columns) is the same  for sorting and skipping

so no prob, if you don't insert or remove data

Right. I am more concerned with movement that happens *before both* 
of the two references. That is what can mess up positions.

the initial offset  (which column)  the sort is on changes, but that 
is 
sort/skip/compare/part  ref1 span   column  ref2

Brian's concern is what does this sort do to ref5 and ref 6  position. 
are they still valid.

time to experiment

as this is building a tree, structure later operations always occur 
strictly within earlier operation boundaries

thanks Brian and Steeve. good night

Good night.

how can this avoided?


does a object! defined within a object! (embedded) breaks with the 
clone/ingherit rule?

calling a function within a object! which e.g. changing a value within 
the embedded object!
changing the parent AND the child object!.

template: make object! [
	obj-in-obj: 	make object! [a: make integer! 0]
	b: 		make integer! 0
	c: func [val] [
		obj-in-obj/a:   val
		b:		val
	]
]  

wcopy: make template []
probe template
probe wcopy
wcopy/c 1000
probe template
probe wcopy

what I am doing wrong here?
and is there any easy way to clear a object at once
without resetting every single variable in the object

I have a big loop (20.000+) which fills many objects with datas.
the objects contains also functions writing and calculating
data within other objects (all within a global context/object). 

each loop is a new run, so I need a new or cleared set of objects 

for every loop. looks like cloning doesn't work for me (see above). 

I could reset every single value, but this will cost me a day minimum.

do I overseen some simple solution here?