[REBOL] Re: for bug?
From: joel:neely:fedex at: 18-Jun-2002 7:28
Hi, Romano,
Romano Paolo Tenca wrote:
> 1) it is strange, but your simulation code is more slow on my
> system (W98 - Celeron 333 view 1.2.1.3.1 and beta 1.2.5.3.1)
> than the standard simulated 'for
>
> >>race 500000
>
> 0:00:03.52 0:00:04.01
>
May I suggest
- increasing the argument at least one order of magnitude
- running multiple times
I've seen situations where some transient condition could easily
throw a half-second glitch into a small benchmark. The first
run I made of (an earlier version of) RACE the result favored
the WHILE version over the UNTIL version, but over a large number
of subsequent runs with larger loop counts the UNTIL version was
the consistent winner.
> 2) neither your code can check this case:
>
> for i #"^(00)" #"^(01)" 256 []
>
You're right. Ooops.
> 3) the right solution should be a consistent math overflow error
> with all scalar datatype! and not a
>
> pseudo-random [error wrap stop bug]
>
> like it is in the actual implementation (bug is for the time!
> datatype!) :-)
>
> 4) I always think that
>
> for i #"^(00)" #"^(ff)" 1 []
>
> should stop at #"^(ff)", with or without math overflow and with
>
I assume you mean "after" instead of "at", that is the #"^(ff)"
should be processed but should be the last value to be processed.
> or without wrap, so 'for should check the end condition at the
> end of the loop and before adding the bump value.
>
I'm beginning to think that the optimal solution to all of the
above would be something like the following:
1) perform type consistency checks and throw an error if bounds
and increment are not suitable
2) calculate the number of values that actually satisfy both the
bounds/increment constraints and the domain constraints of
the bounds types
3) if the number of such values is zero, the range is empty, so
do nothing gracefully and exit
4) if the number of such value is non-zero, set CURRENT to the
lower bound, then...
5) use LOOP (controlled by the number of values calculated in
step 2) to perform the body and then increment CURRENT by the
supplied "bump" argument.
This strategy would push all of the boundary issues into step 2,
eliminating the attempted evaluation of an out-of-bounds value
within the loop, no matter what the types of the data, nor the
handling of edge effects by REBOL.
The added overhead would go into loop setup rather than loop body
and the iteration would actually be performed by LOOP, so for
sufficiently large iteration counts, there should be a net gain
of performance.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
