Re: Fix for 687497, for loop with integer increment and big limit doesn't work

Alex,

Thank you for explanation.

Unfortunately now I have no time for digging into this problem,
because I have several high priority issues open.
Probably I'll have a time after a week or two.

My immediate feeling is that there should exist a better solution.
Since the bug isn't a high priority, it can wait for a while.
If you want a faster resolution for your results,
please ask Ray to review it. 
I guess he is busy also, but he is more familiar with
this part of the codebase.

In any case, please add your explanation to the log message,
and put a comment into the code explaining about the
estack contents.

Igor.

----- Original Message ----- 
From: "Alex Cherepanov" <[email protected]>
To: "Igor V. Melichev" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, June 08, 2004 2:07 AM
Subject: Re: Fix for 687497, for loop with integer increment and big limit doesn't work


> Before I answer Igor's questions I'd like to bring up the approach
> suggested by the user. Instead of calculating new value of the loop
> variable as a sum of the previous value and a step he recommends
> to pre-calculate the number of steps and do:
> 
> uint32 iterations = uint32( (to - from) / step )
> for(uint32 i=0; i<=iterations; i++)
>    value = from + step * i / iterations
> 
> Althoug this avoids an infinite loop, with the limited float precision
> loop control variable won't change on every iteration.
> It is not clear what to do if the number of steps exceeds max_uint32.
> 
>  > Please explain your patch better.
> 
> The old patch tries to reduce the changes in the existing code.
> It includes 2 fixes.
> - Detection of the integer overflow in the control variable.
>    The loop is terminated when the control variable becomes less than
>    the initial value FROM. Since FROM value was not available to
>    the continuation procedure, it was added to the operand stack.
> 
> - In PostScript implementation the type of the control variable is
>    determined by FROM and STEP arguments. TO is converted to integer
>    when both FROM and STEP are integers. This was done by the system
>    conversion: int TO_int = (int)TO regardless of the value. The patch
>    switches to floating point when TO cannot represented by int.
> 
> > What more do you push ?
> I allways push the value of FROM . It is not used by the float loop.
> 
> > Hmm, floating numbers have a 3 bytes mantissa, right ?
> > So the precision of floating numbers is smaller.
> > What happens with this program :
> > 
> > 0 1 65536.0 65536.0 mul {pop} for
> 
> An infinite loop.
> The following is also an infinite loop, which existed before my patch. 
> 0. 1. 65536.0 65536.0 mul {pop} for
> 
> Regards,
> Alex
> 
>