World: r3wp

Though sparse-bitset! would be a more accurate name due to the integer/char 
restriction for contents.

i remember having an algo done with R2 to simulate hash! using bitsets 
and blocks

i should search for...

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
	]
]

.Hum...  it was not finished...

Obviously it was done to speed up the search

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

You could wrap the structure in accessors that would do the work. 
It's doable.

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

Bitmap = bitset in this case

Nothing to do with images

IIS question http://synapse-ehr.com/forums/showthread.php?28-REBOL-on-Microsoft-Web-Server-2008

by just making your own INCLUDE function, while one is added to the 
default REBOL language, I find its pretty easy to manage sets.


Use all the  Data Set functions and remove-each.   combining sets, 
excluding sets, etc.. its all there.

I also often use a FILTER function which is just a wrapper around 
remove-each which does a copy on the source input and adds a NOT 
to the comparison block you provide.


this means you keep data instead of removing it and don't break the 
original series.

a keep-each

a keep-each

Actually, it's so easy to add a copy where you need, that i think 
all the  serie's constructing native functions should update the 
input by default, rather than construncting new ones.
Think About UNION, UNIQUE, INTERSECT etc...

They are handy functions but involve too much overhead on big series.

I would love the /INTO refinement be added to all series manipulators.

This way we can make a huge buffer and reuse it all the time.

much less work for the GC and big speed gains on large series.

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...

didn't I suggest we have a set! datatype?

and yes, it's common to want to maintain a set ...

steeve, that is what BrianH and I are talking about with the 'INCLUDE 
function.

basically, ALTER should disapear and be replaced with 'INCLUDE

ALTER has no use except for Carl

It should be renamed 'TOGGLE, and then I might use it, cause I'd 
understand what it means and think about it.

INCLUDE isn't a good name for it, though, because of conflicting 
with the much more common INCLUDE for dependencies.

If the set functions are made in-place, that would just be 'union, 
wouldn't it?

Right, i was talking about UNION, not UNIQUE.

Steeve, you are presuming that Carl has a use for ALTER - I haven't 
seen him use it yet.

Is that not used somewhere in VID ?

Not that I've noticed, but I seem to recall that VID flags is what 
ALTER was originally for.

If that's so, Who's  asked for that clumsy function :)

Gregg, we already have dependencies covered without using 'include. 
Using the word 'include has the advantage of discouraging people 
from reinventing the wheel, making yet another dependencies system.

Fortunately people can redefine the word as they like in R3, and 
it won't disturb existing code because of its module/dependency system.

BrianH, in 2.7.7:

types-of :now

returns a lot of type blocks. Is that correct?

It returns nine blocks which correspond to the nine refinements the 
NOW function has. I guess it's somewhat intended behaviour ...

Refinement arguments are either of type NONE! or of type LOGIC!, 
so there is a reasoning.

R3 does it too, so I suppose that is correct.

Yes, it is. And it makes sense:

>> apply :now [true none none none none none none none none]
== 2010
>> apply :now [none true none none none none none none none none]
== 2
>> apply :now [none true none none none none none none none]
== 2
>> apply :now [none none true none none none none none none]
== 28
>> apply :now [none none none true none none none none none]
== 13:26:18
>> apply :now [none none none none true none none none none]
== 1:00
>> apply :now [none none none none none true none none none]
== 28-Feb-2010
>> apply :now [none none none none none none true none none]
== 7
>> apply :now [none none none none none none none true none]
== 59
>> apply :now [none none none none none none none none none]
== 28-Feb-2010/13:26:47+1:00

(overfluous example no. 2 above)

With TYPES-OF you can decide about the argument ordering for APPLY 
and where to put the refinement switches.

>> apply :now []
== 28-Feb-2010/6:58:05-6:00

Any arguments you leave off the end are passed the value none, at 
least in R3. That should be the case in R2 as well.

The blocks of types returned by TYPES-OF in R2 can be used mostly 
the same as the typesets returned in R3. The typeset! datatype was 
faked in R2 - see also the TO-TYPESET and TYPESET? functions. You 
can use them with FIND and the set functions, but otherwise be careful. 
Be sure to use the FOUND? function on the result of FIND to get the 
same result, which is TRUE? but not true. There are some built-in 
fake typesets too; look at the source of ANY-OBJECT? for an example 
of use.

Btw, that APPLY trick with the missing arguments is used in USE in 
R3 to initialize the words to none. The source:
use: make function! [[
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]]

Regarding cutting off arguments, that was "just another" typo. The 
last should have been 8 NONEs ending in a TRUE for the /PRECISE refinement.

Ah, that makes more sense.

Extra arguments in the block are ignored too, though the block is 
still reduced unless you use APPLY/only.

Oh, I never realised that USE is just a mezzanine ... cool stuff!