AltME groups: search

it would be more like extract with a /find index.

yes henrik, nice idea in this moment I was thinking similar but with 
copy/part but storing the index is much faster.

cause the word is being used as the index.

foreach will advance to the next index whether or not the series 
was modified:
>> D: [1 2 3 4 5 6 7 8 9]
== [1 2 3 4 5 6 7 8 9]
>> foreach X D [remove find D X]
== []
>> ? D
D is a block of value: [2 4 6 8]

the current changes I'm adding to liquid is the ability to use bidirectional 
messaging... you can now supply arguments to the process, and it 
will use the params within as an index key to match recurring processing

IIRC, Carl explained (at least) once that this behaviour is different 
on purpose. Using path notation with an index value or PICK should 
return NONE while using the prefix notation FIRST, SECOND,...LAST 
should return an error. So you have the choice to either silently 
handle missing values in series or raise an error!.

Even with a simple example like the one you gave, I might add a couple 
funcs to make the intent even clearer. e.g.

insert-from-tail: func [
    series [series!] 
    value  
    index  [integer!]
] [
    insert skip tail series negate abs index value
]

insert-before-tail: func [
    series [series!] 
    value  
][
    insert-from-tail series value 1
]

insert-before-tail series my-value

Transfering memory based hash! (map! in R3) datatype into disk based 
shema automatically keeping the hash table computation and lookup 
hidden from user gives you a RIF. Holly grail of all rebollers :) 
long long time promissed, still waiting to be done. Anyway hash tables 
are always usually unsorted, when necessary to search in usually 
some type of additional index is used (B-tree for example), for simple 
information if the key is in the set, bitmap vectors are used with 
advantage, when the set is really big (and bitmap vector doesn fit 
into memory) comressed bitmap may be used and usually bitwise operations 
on those vectors are much quicker than on uncompressed. 

Thisi is why it should be used for bitset! datatype anyway. The number 
of byte aligned (BBC,Packbit,RLE)od word aligned (WAH) schemes exists. 
 It is used in very large datasets when index also resides in disk 
file. Once again bitwise operation may be much quickier even in memory 
on those schemes.

resolve: func [

 "Copy context by setting values in the target from those in the source."
	[catch]
	target [object! port!]
	source [object! port!]

 /only from [block! integer!] "Only specific words (exports) or new 
 words in target (index to tail)"

 /all "Set all words, even those in the target that already have a 
 value"
][
	either only [
		from: either integer? from [

   ; Only set words in the target positioned at the number from or later
			unless positive? from [throw-error 'script 'out-of-range from]
			intersect words-of source at words-of target from
		] [

   ; Only set the words in the target that are also in the from block
			intersect words-of source intersect words-of target from
		]
		foreach word from pick [

   [unless value? in target word [error? set/any in target word get/any 
   word]]
			[error? set/any in target word get/any word]
		] not all ; See below for what this means
	] [

  either all [ ; Override all target words even if they have values
			error? set/any bind words-of source target get/any source
		] [ ; Only set target words if they aren't yet set
			foreach word intersect words-of source words-of target [

    unless value? in target word [error? set/any in target word get/any 
    word]
			]
		]
	]
	also target set [source target from] none
]
; Note: This is native in R3 and supports module! too.

; Implementation note: INTERSECT returns the values from its first 
argument,

; and WORDS-OF returns a block of words that are bound to its argument, 
so
;     intersect words-of source words-of target
; returns a block of words bound to source.

map! as a primary index , and bitsets for linked indexes when data 
have good localities

Yup. Not a bad project, and it should even be fast in mezzanine code. 
Maybe as a user-defined index type if you like, though a set of related 
functions would do.

Found ...

f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
]

A sparse index lookup with map!/bitset! in R3 would just be: find 
select index to-integer x / period x

I recomend to use compressed bitmap EWAH scheme, in worst case tradeof 
is one 32bit word, in sparse bitmap it will save huge amount of space, 
AND,OR,XOR algorithms described for those bitmaps, usually used (but 
not restricted to) as DB bitmap index

UNIQUE is not used because of this.

I can't remember how many times i wanted an handy way to add unique 
values in an existing serie.
like 
>> unique index [new-values ...]
instead of having such, we do dirty tricks like.
>> unless find index new-value [append index new-value]  
pretty common...

I'm trying to figure out which index comes earlier in two different 
references to the same block and was trying with MIN and MAX, because 
I didn't want to resort to LESSER? INDEX? things.


The result with MIN/MAX doesn't seem to be particularly useful. What 
is the basis of comparison of two blocks when using MIN and MAX?

here's my fastest one yet... I tried two so far...

	;-----------------
	;-     find-same()
	;-----------------
	find-same: func [
		series [block!]
		item [series! object!]
		/local s i
	][
		i: 1
		repeat s series [
			i: i + 1
			if same? s item [
				break
			]
		]
		unless i > length? series [
			at series i - 1
		]
	]
	

using until was slower probably because REPEAT is faster than UNTIL 
(no exit condition or series index to increase).

I wouldn't say We MUST add /SAME to FIND, though it could be useful 
in special cases. Another posssibility, though I want to think about 
it more before standing behind it, would be to allow AT to take an 
index value that is a reference. Hmmm, no, maybe not. It would then 
have to return NONE if the item wasn't in the block. Nevermind.

Use SORT/compare with an integer argument for the index of the records 
you want compared, and don't forget /skip for the record length. 
Like this:
>> sort/skip/compare [1 5 2 4 3 3 4 2 5 1] 2 2
== [5 1 4 2 3 3 2 4 1 5]

Didn't know you could put the /compare index in a block. Can you 
specify more than one index?

Well, most functions care about the series index. We can easily test 
if FUNC does:
>> body: tail [print "hello"]
== []
>> f: func [] body
>> f
<---- nothing is printed

head clear find site: select load-thru http://www.rebol.net/reb/index.r
[folder "Anton"] %index.r
do do-thru/update/args site/do.r [update "gui/style-gallery.r"]

Use this code to check for newer versions and update your cache:


 head clear find site: select load-thru/update http://www.rebol.net/reb/index.r
 [folder "Anton"] %index.r
	do do-thru/update/args site/do.r [update "gui/style-gallery.r"]


Use the code below when you are happy with the cached files you have 
and want to do those only:


 head clear find site: select load-thru http://www.rebol.net/reb/index.r
 [folder "Anton"] %index.r
	do do-thru/args site/do.r [cache-only "gui/style-gallery.r"]

its even fully documented!


http://www.pointillistic.com/open-REBOL/moa/steel/retools/retask/index.html

Chris had same trouble. Problem is at rebol.net. I think since the 
server crash, the Sites rebsite index reverted to an old one. I also 
can't update it at the moment because the cgi updater hasn't been 
restored yet either.

This fixes the rebsite index temporarily:

; Needed until rebol.net Sites rebsite index is updateable and updated.
old: as-string read-thru http://www.rebol.net/reb/index.r

replace (new: copy old) "www.lexicon.net/antonr" "anton.wildit.net.au"
write/binary path-thru http://www.rebol.net/reb/index.rnew

view layout [
	button "reset" [n: 0]
	button "read" [
		;remove find system/ports/wait-list system/view/event-port
		
		old-wake-event: get in system/view 'wake-event
		
		system/view/wake-event: func [port][
			while [pick port 1][] ; remove and ignore all queued events
			false
		]
		
		print n: n + 1
		probe length? read http://anton.wildit.net.au/rebol/index.html
		
		; clean queued events
		wait 0.0001
		
		system/view/wake-event: :old-wake-event
		
		;insert system/ports/wait-list system/view/event-port
	]
]

Unfamiliar with View: Is there a way to have Rebol/View rebuild it's 
local index automaticaly when you add scripts to the folder? It would 
ease the process of getting into the stuff if I could just shove 
a bunch of .r files in there without having to build an index manually 
before running them. Someone must have solved this already, I'm sure! 
;-)

There is a script called update_index.r that probably is supposed 
to do this - but it bombs when not finding "desktop/icons".

Actually, the index.r updater script works pretty well. I started 
with the idea that I wanted to manually select which files I would 
like indexed and thus publically viewable. I did not want it to automatically 
add files to the index just because they were in a directory.

I may be biased ... no, I know I'm biased.  I'd start here;
http://developer.kde.org/documentation/design/ui/index.htmland

http://developer.kde.org/documentation/standards/kde/style/basics/index.html

of note;  http://developer.kde.org/documentation/standards/kde/style/basics/badInterface.html

unless it returns the index of the string and not a pair.

http://www.rebol.net/builds/index.html

Graham... Check out http://www.maani.us/xml_charts/index.php?menu=Gallery&submenu=Floating_Bar

Still working with Anton's Scroll-panel...

I found a way to "index" the text location in the scroll panel as 
I build the layout. But when I try to set the offset to a specific 
position in the scroll panel I offset the whole "face" and not a 
reposition of the scroller. 
Example- 
I set my_scroll_panel/offset/y: 200

I feel I should be setting the scroller's value but I can  not seem 
to figure out how...

I got it to scroll to my index point but I acn't find the fuction 
to update the scroll bar.

Is there a way to get an index # from a text list selection?

text-list in R2 has this problem cause it works on text value, not 
index. So it can't handle the same text value several times.
VID 3.4 actually return the index AFAIK.

REBOL []

index: func [dir list /local files] [
	files: sort load dir
	foreach file files [append list join dir file]

 foreach file files [attempt [if find file "/" [index dir/:file list]]]
] index %/c/ files: []

l: layout [
	f: field 600 [call t/picked]
	t: text-list 600x400 data copy files] 

search: func [f-string] [
	t/data: copy files  

 foreach s parse f-string none [remove-each f t/data [not find f s]]
	show t]


append blk: select select second get in f/feel 'engage [switch act][key] 
bind [search f/text] blk/2

focus f view l



if I type something into the field, then I click the slider, it calls 
t/picked. Why? i can't figure it out.

index: func [dir list /local files] [
	files: sort load dir
	foreach file files [append list join dir file]

 foreach file files [attempt [if find file "/" [index dir/:file list]]]
] index %/c/ files: []

l: layout [
	f: field 600 [call t/picked]
	t: text-list 600x400 data copy files] 

search: func [f-string] [
	t/data: copy files  

 foreach s parse f-string none [remove-each f t/data [not find f s]]
	append clear t/picked t/data/1
	show t]


append blk: select select second get in f/feel 'engage [switch act][key] 
bind [search f/text] blk/2

append clear t/picked t/data/1
focus f view l



if I type something into the field, then I click the slider, it calls 
t/picked.

view layout [
        below
        p-list: list 550x180 [
                across origin 2x2
                chk: 	check true 
		a1: 	text wrap 100
                a2: 	text wrap 100
		pg1: 	progress 40x20 0.5
		pg2: 	progress 40x20 0.2
		a3: 	text wrap 20
		arr-1: 	box 40x20 effect [ draw arrow red rotate  180 ]
        ] supply [
                if count > length? t [face/show?: false exit]
                face/show?: true
                face/text: t/:count/:index
		;; face/data: d/:count/:index
        ]
	
	btn "set" [ ] 
]

Maxim, do you know how the iterated faces function is used in View? 
I'm stuck in a situation where the index is sometimes returned as 
none.

data: make block! 16

loop 16 [repend/only data [random "012345789" random "abcdefghij"]]

visible: 5					; number of visible lines
window: (length? data) - visible	; sliding window size
cursor: 0

view layout [
	across
	space 0x0
	
	grid: list 200x100 [
		across
		txt 100
		txt 100
	] supply [	
		if row: pick data count + cursor [face/text: pick row index]
	]
	sc: scroller 16x100 [
		cursor: sc/data * window
		show grid
	]
	do [
		sc/step: 1 / window		; initializing scroller steps granularity
	]
]

In case you're wondering about the block after SUPPLY, it's used 
internally by the LIST style to build an iterating function defining 
a local context where COUNT refers to the current row and INDEX to 
the current column. Each horizontally positionned face (purpose of 
the ACROSS keyword) defined in the LIST layout block, is counted 
as a column, so: txt 100 txt 100 => 2 columns.

I think part of the problem is that the index is not moving for the 
highlight, when you insert text into the string, so you would have 
to manually move the index for highlight start/end.

Max, a task for you :) http://www.the8pen.com/index.html

I wrote a function to get a copy of a wrapped text in a face object. 
Please have a look at it. If you have a better idea please let me 
know:
http://rebolforum.com/index.cgi?f=printtopic&topicnumber=46


it uses offset-to-carret to find the line positions and inserts a 
newline to that position in the text.

Henrik, I wrote another version of the function which is a bit better. 
It could help about the bug you told.

The only problem is it it makes a copy of the given text. So it is 
not the same text anymore.
http://rebolforum.com/index.cgi?f=printtopic&topicnumber=46

I'm running the latest Rebcore and Rebview on an Xubuntu box. My 
issue is that when I click on the REBOL folder icon at the top left 
of the "sidebar", I get a message saying something like: "Cannot 
open location http://www.rebol.com/index.r.Any ideas??

Nope I just tried, and it doesn't work. Try http://www.rebol.com/index.r
on your browser you'll see a 404 page.

RebGUI expert needed on REBOLTalk:
http://www.reboltalk.com/forum/index.php/topic,739.0.html

Couldn't the data block *index* of the currently shown string be 
stored in an attribute of the drop-list face ? When the action is 
called, you could then access the index and refer to your list of 
ids which you maintain separately (and however you like).

index: Changes if you have entries order changes. Alphabetical sorted 
list of same things in different languages can have different order. 
Solution must be position independent.

e.g. you have a list-box for fruits: ["apples" "bananas" "cherries"] 
.... that can't be sufficient in any way - it could be, if those 
"texts" could serve you as index to some localisation table:

langs: [cz "Cesky" us "English" de "German"]
fruits: ["apples" "bananas" "cherries"]

trans: [ ;table-id (name), lang, key, translation
fruits  [
    cz  [
       "apples" "jablka"
       "bananas" "banany"
       "cherries"  "tresne"
    ]
 ]
] 

select trans/fruits/cz "apples"

just an example (not practical one :-)

Alas, I won't be there to see it ... http://www.medrecinst.com/conference/tepr/index.asp

New error for me ..


An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 501
    type: 'access
    id: 'not-open
    arg1: "Port"
    arg2: none
    arg3: none
    near: [repeat i p/cols [
            line/pane/:i/offset/x: col-offset 
            line/pane/:i/size/x: p/widths/:i - sizes/cell 
            all [
                p/pane/2/show? 
                i = p/cols 

                line/pane/:i/size/x: line/pane/:i/size/x + (p/size/x - p/pane/2/size/x 
                - (line/pane/:i/offset/x + line/pane/:i/size/x))
            ] 

            line/pane/:i/text: replace/all form pick p/data index - 1 * cols 
            + i "^/" "¶" 

            line/pane/:i/font/color: either find p/options 'no-action [
                black
            ] [
                either find picked index [white] [black]
            ] 
            col-offset: col-offset + pick widths i
        ]]
    where: 'confirm
]

The current tab is connected to the content area, just as it would 
be if we were shuffling several physical index cards that had tabs 
stuck to them. This emphasizes which panel is being shown, and also 
helps tell users which tab is selected when there are only 2 tabs. 
Having the same color for the selected tab and the panel area reinforces 
the connection between the two and is a reason to support the use 
of reverse highlighting. 

If I have tree data like this [ A [  B B B ] ]


how can I tell which of the B's that I am clicking on?  Do we need 
some type of index or picked?

You need a unique id, like the index.

Now, yes I could use the CCRDataObjectID to index into the object 
... but that would not look intuitive for a tree choice.

I wrote a lengthy post, hoping to start a constructive discussion 
on how we could increase Rebol's popularity and enbiggen (I know 
it's not a real word, but I didn't want to use "increase" twice in 
one sentense :P) it's userbase. I hope this is something more people 
are thinking about now that Rebol 3 is imminent. Please have a look 
at http://www.reboltalk.com/forum/index.php/topic,1513.0.html


(I'm not trying to draw people away from Altme, but I think there's 
a need for a good Rebol forum too! :))

i use as "index" for my seachies into the list the offset position 
of each char displayed

so my idea to speed the search process instead of having to use foreach 
loops would be to convert my list into an hash table like data structure 
using the postions as index

yo all, i don't find any index property in the new port file scheme 
in R3, how can we seek in a opened file ?

Ports can't be treated like series anymore. The seek option has been 
moved to READ and WRITE, which correspond loosely to COPY and INSERT 
on R2 ports. The index or offset is an internal property of the port, 
not of the port reference like in R2.

ok, the prob with the new file port is that we can not have a direct 
access using an index.

Instead we have to maintain a relative offset because we only can 
use read/seek wich use negative and positive offset. I think READ 
should allow to use an absolute index  too. (like with a refinement 
 /at )

Sorry, I said offsets when I meant indexes. And read/seek doesn't 
allow negative indexes - the index parameter is always a non-negative 
offset from the beginning, 0-based.

I'm testing it now. All read/seek calls go to a 0-based index from 
the beginning of the file. Negative offsets cause an error. What 
version of REBOL are you using?

Brian, i'm sorry i made a mistake, it was not the /seek refinement 
i used (which don't exist) with the 'read function but the /skip 
refinement.

Anyway, it seems that we can do a seek position with an obsolute 
index only when opening the file. After that, we can only skip the 
port. with relative offset. I think a /seek  refinement is missing 
in 'read function

http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Easier access to images.

Steeve, http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Pekr: http://www.antigrain.com/research/font_rasterization/index.html

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

If I get to do it, sorting will be non-destructive, like LIST-VIEW. 
This means keeping a sort index. But that depends on how complex 
it will be. Carl tolerates only little complexity.

My response to a query aboit REBOL3 on REBOLtalk would not make a 
marketing person happy:
-- year old alpha
-- no obvious contact details for those wanting to get involved.
Could someone better connected do a better job, please?

http://www.reboltalk.com/forum/index.php/topic,1827.msg4644.html#msg4644

So does it maintain the index order of the individual blocks within 
it?

yes Paul it uses 2 files: an index and the data

Tretbase uses data and a index.

[Virtual blocks] What do you think of an option to allow fixed-size 
records only, so that there is no need to create a file index (faster 
access but data file possibly bigger)

http://development.syllable.org/pages/index.html

I think it is the amount of movement via the index that is time consuming 
for the other method.

It also shifts the index twice, whether the function needs it or 
not.

The one compare is dwarfed by the copy overhead though. Shifting 
the index only has significant overhead for ports, not series.

The list! type is gone from R3, and that was the only type with index 
overhead.

Brian Block as key would be good for reversed index IMO. Question 
if it would be usefull.

something related, in the past i made some tests to simulate hashs 
with integer keys in R2. I used a bitset as an index, mixed with 
block of blocks to store data.

my tests show that for 10000 records,  finding data is near as fast 
as with hashs. 
actually it's incomplete but you have the idea with this:

REBOL []
f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
] 

t: now/time/precise
loop 10000 bind [flag random 99999] f
print now/time/precise - t
t: now/time/precise
loop 10000 bind [flag? random 99999] f
print now/time/precise - t

I'm not sure that you're wrong though. There's also the index to 
consider.

The only thing I could dispute would be the "huge" part. References 
wouldn't necessarily need to be stored as full 64-bit integers if 
there is an index, so there could be even more space savings, though 
speed would be king for RIF I expect. In any case I expect much more 
space savings than REBOL text syntax.

If you want index to be zero, copy the block.

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.

Indexes are calculated by adding the base to the offset. The new 
behavior for PICK and POKE makes that consistent, though AT should 
be fixed as well as it is the only index-based native left (unless 
I've forgotten something). I've added bug tickets for all of this.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

Consider if we had a COUNTER! datatype. The counter would create 
a series of integers, each holding a separate base. The trick to 
COUNTER! is that it is a structure that holds more information than 
just the numbers, but also states, in the same way that a block holds 
an index or whether a port! is open or closed.

First the bad things:


- It can be complex and there are many things to consider. Many functions 
would be affected.

Now the good:


- This takes all the thinking out of building trivial counters and 
could greatly simplify it.
- It could be used as an any-base converter.
- No new functions to add specifically for it.

It should be possible to:

- Specify as many numbers per counter as we like.

- Each number would be within the limits of positive integers and 
each number would act as an integer! type.

- Extract information about which digit is currently counting or 
which number was last changed.
- Extract base information.
- Perform basic math (add/subtract).
- Perform base conversion for the entire counter.
- Perform base conversion between a counter and an integer.

A counter would hold four pieces of information:

- The base for each number
- The numbers themselves
- The last changed number as a one-based integer index

- The last numbers that were reset at last count as a block of one-based 
integer indexes

The nature of a counter:

- It would be a number!.
- It would not be a series!.

Specifying a counter:

- The above four pieces would be specified in order
- Each piece is separated by an exclamation mark
- Possible to skip pieces by leaving the field empty

- Syntax: !<base definition>!<number>!<last changed number>!<last 
reset numbers>
- Counter base alone: !12.14.16
- Counter base with number: !12.14.16!0.0.0

- Counter base with number and last changed number: !12.14.16!0.0.0!3

- Counter base with number and last changed number and last reset 
indexes: !12.14.16!0.0.0!3![2 1]
- Number without base: !!0.0.0

There's more, but it's a little much to write. :-)

If it can be used to maintain large index on any data structure efficiently, 
it could be usefull. I'm waiting for your code

You can use path (index) with objects in R3, like you can with blocks 
in R2. Like:
o: make object! [a: 1 b: 2]
o/1: 42

My God... path notation (with parents) is faster than PICK  to get 
a value from a serie with a calculated index, even in the current 
R2.

t/(x) faster than pick t x


I was always thinking  the reverse since a while (true in older R2 
release).
How may this happen to me, i'm fooled...

but does t/:x still return none when the index doesn't exist? cause 
that is the main advantage of pick for me...

Perter showed you that is the case now in R3.
t/:x == none
if the index X doesn't exist in T