[REBOL] Re: Limitation coming from the "initialize" refinement usedwiththe "Arra
From: joel:neely:fedex at: 27-Jun-2002 11:30
Hi, again, Gerard...
One more thing I forgot earlier...
Joel Neely wrote:
> 8<----
>
> table1: array/initial [3 2 1] 0
>
> tally1: func [n [integer!] /local t row col] [
> t: now/time/precise
> table1: array/initial [3 2 1] 0
> row: col: 1
> loop n [
> change table1/:row/:col 1 + table1/:row/:col/1
> row: row // 3 + 1
> col: col // 2 + 1
> ]
> t: now/time/precise - t
> print mold table1
> print t
> ]
>
> 8<----
>
There's an additional improvement to be had by replacing the line:
change table1/:row/:col 1 + table1/:row/:col/1
with the equivalent
table1/:row/:col/1: 1 + table1/:row/:col/1
(improving both performance and notational consistency!) With this
container-based scheme, one can always access an elementary data
value with
arrayname/...path.../1
and change the contained value with
arrayname/...path.../1: expressionfornewvalue
where, of course, the
...path...
part can contain literals and get-words as apprpriate. Making a new
version (tally1a) with this last change and rerunning the benchmarks
(this time using an average of five runs of half-a-million cycles
each -- on a faster computer ;-) we get these stats
version strategy avg time ratio lo/med/hi times
------- -------- -------- ----- --------------------
tally0 join 35.3388 19.71 35.311 35.331 35.37
tally0a rejoin 21.2766 11.55 21.25 21.271 21.301
tally0b compose 11.4544 5.84 11.426 11.447 11.486
tally1 change 3.453 1.20 3.435 3.455 3.465
tally1a path 3.1106 1 3.104 3.105 3.124
tallyx baseline 1.388 0 1.382 1.392 1.392
-jn-
