World: r3wp

It's because you can't match an integer like a word

looks like foreach is still the winner (on r2)

Against a block with 100,000 integers

Lad's : 0.047
foreach: 0.044

Terry, you did not write the Foreach-base algo here, so nobody can 
compare...

1 1 value means to run the rule once and only once where value is 
the rule

A bit adapted Lad's version (does not use substraction):

indices?-4: func [
	series [series!]
	value
	/local result
] [
	result: make series 0
	parse series [
		any [series: 1 1 value (append result index? series) | skip]
	]
	result
]


>> time-block [indices?-2 blk 23] 0,05
== 0.000003936767578125

>> time-block [indices?-4 blk 23] 0,05
== 0.000003753662109375

interesting, I thought, that this modification would be slower

(index?-2 spares four assignments, while index?-4 spares two subtract 
calls)

what are your results compared to foreach?

gotta go.. bedtime in the pacific northwest

Is there any other way of how to put word in, instead of 1 1 value? 
Quote? Hmm, probably not ... I don't like the form ....

if we have 'set, we could have 'get, no?

Replacing "1 1 value" by "quote (value)" as variant 5:

indices?-5: func [
	series [series!]
	value
	/local result
] [
	result: make series 0
	parse series [

  any [series: quote (value) (append result index? series) | skip]
	]
	result
]

>> time-block [indices?-1 blk 23] 0,05
== 0.0000047607421875

>> time-block [indices?-2 blk 23] 0,05
== 0.000003936767578125

>> time-block [indices?-3 blk 23] 0,05
== 0.0000059814453125

>> time-block [indices?-4 blk 23] 0,05
== 0.00000372314453125

>> time-block [indices?-5 blk 23] 0,05
== 0.000003692626953125

Nice .. we don't have quote in r2

Wonder if that could be back ported to r2 ...

Matrix - There is no spoon ...
REBOL - There is no R2 ....

... forget R2 :-)

Brian will object anyway ...

I think that backporting parse, which is totally rewritten for R3, 
is really meaningless waste of energy ...

except for those of us using R2

Remember that we are paying R2 customers .. and R3 is not going to 
be usable for a few more years

If you would not use GUI, what exactly would be holding you back? 
You created even basic networking schemes? As for me, I miss fixed 
'call - it is still hugely crippled and absolutly useless ...

I don't do any non gui apps

Graham - that is nonsense, no? I mean - not being usable for few 
more years ... but we should move the discussion to R3, or advocacy 
...

Pekr, it's still alpha!

It took 4 years to reach alpha

e.g. for me, RebGUI is a dead end. I talked to Bobik, and he is back 
to VID for simple stuff. There were many changes lately, and some 
things got broken, and it does not seem to be supported anymore. 
As for GUI, I believe that in 2-3 months, you will be able to talk 
otherwise, as Robert wants to move his tools to R3 definitely ...

I don't care about the stickers. Someone said it is alpha, so tell 
to your brain, that it is a beta, and you are OK, easy as that :-) 
I use products according to functionality, not its official alpha/beta/theta 
status ...

I used Mozilla since 0.96 and it worked for me :-)

sorry, it's still alpha quality

Henrik: ahttp works basically like async:// - there are no docs other 
than the Detective sources.

Cheyenne is R2. I need something that works with it.

>> a

== [23 43 55 28 345 99 320 48 22 23 95 884 1000000 999999 999998 
999997 999996 999995 999994 999993 999992 999991 999990 999989 999...
>>

(a is a block with 1, 000,012  integers) 


ind: func[series value x][


	st: now/time/precise
		
	while [x > 0][
		
		result: make series 0
		series: head series

  parse series[any [series: 1 1 value (append result index? series) 
  | skip]] 
		x: x - 1
	]
	et: now/time/precise
	fin: et - st
	print fin
	result 
]

feach: func[series value x][

	result: make series 0 
	st: now/time/precise
	
	while [x > 0][

  foreach[s p v] series [if s = value [append result reduce [s p v]]]
		x: x - 1
	]
	et: now/time/precise
	fin: et - st
	print fin
	result 
]

>> ind a 23 10
0:00:01.249
== [1 10 999990]
>>

>> feach a 23 10
0:00:01.01

== [23 43 55 23 95 884 23 43 55 23 95 884 23 43 55 23 95 884 23 43 
55 23 95 884 23 43 55 23 95 884 23 43 55 23 95 884 23 43 55 23 9...
>>

10 iterations each.. 


foreach is the winner speed wise.. as a bonus, If i use foreach, 
I don't need the index?

Still this is too slow.. it's fine for 1M data, but 10M and it grinds 
hard.

.. there must be a faster way to find integers in a block (or hash) 
using SELECT, FIND or INDEX?

yes... you do a find, within a while block.   that was the fastest 
loop I did for matching exact SAME? strings.  I'd bet its the best 
here too.

or did you test that already?

the problem is that with hash! find will return both keys and data 
though.

also, until is a bit faster than while IIRC.

might want to refer to this big loop analysis I did last year...


http://www.pointillistic.com/open-REBOL/moa/scream/rebol-iterator-comparison.txt

you'd be surprised that the fastest search method is remove-each 
(if you account for inserting/appending as part of the loop).   but 
you'll need to copy the initial block each time, which might take 
its own time.

in your tests, this causes your loops to slow down a lot:

result: make series 0

you should:

result: make series length? series. 


because when appending, you will be re-allocating the result over 
and over... and the GC is the loop killer in every single big dataset 
tests I've done.  not because its bad, per se, but because you are 
forcing it to operate.

Thanks Maxim, I'll check it out.

I'm building a little example which I think will outperform your 
examples... I'm curious.

I'm just about to test it.

moving the result: make series 0 out of the while loop had a 10 milli 
improvement over 10 iterations.

that might account for the rarity of results.  if your data has a 
lot of occurences, then that number will increase, since your result 
block will grow much more.

You may need to move beyond brute force Terry, and set up a data 
structure to optimize the searching.

There must be a way.

An index is a symbol that represents some value. What I need is to 
add some metadata to that index, and make that searchable.

the goal is a blazing key/value store that's as fast as pulling by 
index
:)

I thought i had it with find/any .. but it doesn't work on blocks

I haven't tried it, but my guess is storing or converting values 
to string to use find/any on will be slower than foreach. as in foreach 
[key value] n [...