World: r3wp

so at present I think I generate all possible combinations and check 
to see if they're in the same set and if not do the sql query

that's my contribution to lazy programming :)

Would you kind enough and give us the expecting output from the input. 
I can't read all your lines currently.

drug1 [ id1 id2 id3 .. ] drug2 [ id1 id5 id6 .. ] drug3 [ id4 id7 
.. ]
-->

combinations = pairs

If you use these 
 855348
211885
541713
849339
108911

as input to this page https://fd.cloud-ehr.net/drugrx.rsp

you'll see the output of the original script which produces html 
and not json

Well I was doing reference to this input ->

drug1 [ id1 id2 id3 .. ] drug2 [ id1 id5 id6 .. ] drug3 [ id4 id7 
.. ]

["IBUPROFEN" [1113 2214 3359 3441 200017 200085] "HEPARIN" [706 1397 
5027 200078 200081 200082 200085] "ABCIXIMAB" [730 200018] "WARFARIN" 
[698 200023] "ASPIRIN" [40 724 1707 1733 3411 3688 3689 3704 3709 
4339 4876 200018]]

interaction found on ATC pair 40 200017 Knowledge IDs	: 6 7 289 

interaction found on ATC pair 40 200023 Knowledge IDs	: 3 4 5 164 
interaction found on ATC pair 40 200081 Knowledge IDs	: 15 1159 
interaction found on ATC pair 40 200082 Knowledge IDs	: 16 1164 
interaction found on ATC pair 724 200017 Knowledge IDs	: 6 7 289 
....

I suspect optimizing this part of the code is only going to save 
ms

the real cost is the sql queries

And what about purchasing a faster computer ? 

(I'm in a deep shit right know, I don't understand what he's talking 
about)

There's a big difference in price between the various CPU configurations 
on amazon

We have find/only for this

a: [ [ 1 2 ] [ 3 4 ] [ 5 6 ]]
find/only a [ 3 4 ]


but what if we wanted to find [ 4 3 ] where we want [ 3 4 ] to be 
equal [ 4 3 ] ie. same set?

Store sorted in a and sort the query before find.

seems expensive to sort each element first

Cheaper than sorting it during each find.

intersect I guess

Sort the elements on insert and keep them sorted. Then sort the value 
you are comparing to before looking for it.

Thanks, Brian, for reformulating what I wrote above.

Ah yes :)

Interesting R3 "bug" btw:
>> intersect [[1 2] [3 4] [5 6]] [[4 3]]
** Script error: block! type is not allowed here

Works fine in R2.

There is a ticket for that.

very odd ... I changed to using blocks instead of sql, and the query 
increased from 1.7 s to 7 seconds!

I guess the sql indices are just faster than using a brute force 
search thru blocks

does a REBOL tar dearchiver exist? I can find an archiver in rebol.org, 
but not one the other way around.

Graham, you can do your own indices using hash!, but that might be 
pushing your complexity budget. Try it and see.

Henrik, just run the program backwards.
...... sorry.

Is there some function for switching two values in series? Ie. I 
have [1 2 3 4 5 6] and want to switch second and third element so 
result is [1 3 2 4 5 6].

reverse/part

I'm afraid this will not help very much if I want to switch second 
and fifth element.

MOVE

thanks!

:-)

Also SWAP.

SWAP is designed for just this situation, and has been backported 
to R2 as well. Here is the source if you have an old R2 version:
swap: func [
    "Swaps elements of a series. (Modifies)"
    series1 [series!]
    series2 [series!]
][
    unless any [empty? series1 empty? series2] [

        poke series1 1 also pick series2 1 poke series2 1 pick series1 1
    ]
    series1
]

SWAP is not mezanine, better!

In R3, true :)

Ah, sorry, I was looking for R3 sollution.

Note that the unless guard above is compatible with the R3 version. 
If either series is empty or at its tail at that position, it's a 
noop, silently.

So watch out.

Watch out for this limit in R3 too (which I forgot to backport):
>> swap a: "a" b: %b
** Script error: values must be of the same type
** Where: swap
** Near: swap a: "a" b: %b

I need it for blocks that has been sanitized before, so no problem 
here.

As far as I can tell, the single type restriction is so the implementation 
of the action in the various datatypes can be simplified. I am interested 
to see how well SWAP works for gobs though. Can you test this and 
see if there are bugs?

Yeah, I will. But I expect problems, gob! series support is very 
limited.

There shouldn't be any problems with this particular operation being 
defined, but I haven't done much bug testing since I don't need any 
graphics support most of the time. All I do is core.

As expected:

>> swap g next g
** Script error: cannot use swap on gob! value
** Where: swap
** Near: swap g next g

this IS core stuff. i haven't called view ;)