Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 and beta > 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 ]