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: 19-Jun-2002 10:49

Hi, Gabriele, I had the compression ratio set too high... Sorry! On Wednesday, June 19, 2002, at 05:34 AM, Gabriele Santilli wrote:
> Hi Joel, > > On Wednesday, June 19, 2002, 5:49:56 AM, you wrote: > > JN> 1) Integer ranges wider than the maximum integral value break > JN> the computation of iteration count; with the existing FOR: > > LOOP only accepts integers... OTOH we could nest two LOOPs to have > 64bit wide integer ranges. :)
What I was thinking about was a range with widely-spaced endpoints (wider than maxint), but also with a large step value, so that the actual number of loop cycles would be integral, but the intermediate calculation would break, as in newfor i -2147483647 1147483647 1000000000 [print i] ** Math Error: Math or number overflow ** Where: newfor ** Near: times: 1 + to-integer divide Given the desire to get the performance and behavioral improvements, I've only been able to come up with a "mixed" strategy (something like FOR already does for series vs. range iterations) as follows: - if the number of values in the range is within maxint, then set up for using LOOP to manage the work, - if the number of values in range exceeds maxint, but there are no boundary problems to address, use a simple WHILE (similar to current FOR), - if the number of values in range exceeds maxint, and there *are* some boundary problems to address, use a WHILE with additional error handling for bailout. I'll play "reader" when I get the chance. ;-) -jn-