Thanks - so, knowing solution was possible in seconds,  I cleaned up my
approach,  also using blocks,  but specifiying their size in advance. 

Rather surprisingly,  it's somewhat faster than Raul's - maybe because 
it
keeps more constant data between block-loops. 

It uses that property I tried explaining to Brian Schott,   but 
incorrectly, 
I now realise.  The property should be that the probe is detected if 
the range's
cycle period divides the (depth plus the delay) exactly.

Here's the listing:


NB. optional left argument to limit the number of loops
NB. right argument is 2 row table of depths and ranges
rrr =: 3 : 0    NB. rubbish name!
_ rrr y
:
'depth range' =. y
period        =. +:<:range
block         =. bsize =. 100000
NB. similar performance for block sizes between 
NB.    1000 and 1000000, on my laptop
delays        =. >: i. bsize
deladddepths  =. depth +/~ delays
max           =. x         NB. maximum number of blocks 
nb            =. 0
while. max > nb =. >:nb do.
   ok            =. period (0 < <./@: |)"1 deladddepths
   if. +/ ok do. break. end.
   deladddepths  =. deladddepths + bsize
end.
>: ((i.&1) ok ) + bsize * nb - 1
)

   timer'rrr input13'    NB. elapsed time rather than cpu
+------+-------+
|10.679|3943252|
+------+-------+
   timer'safe input13'
+------+-------+
|29.603|3943252|
+------+-------+

   7!:2@] 'rrr input13'   NB. for block-size = 100000
68426240
   7!:2@] 'safe input13'
9231616

Both routines spend nearly all their time in the main 
line within the loop. 

Happy End of Advent,

Cheers,

Mike







On 22/12/2017 18:56, Raul Miller wrote:
>    timespacex 'safe s13'
> 3.16326 1.03136e7
>
> Thanks,
>


----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to