in reply to Instructive bug

It's got to be the 
$balance * $i / $slice_count

[download]
that is causing the problem. My guess is that $balance * $i ends up greater than 32 bits, so it converts to a float, and when divided by $slice_count it ends up larger than $cur_balance even when $i == $slice_count.

Michael

Replies are listed 'Best First'.
Re: Re: Instructive bug
by perrin (Chancellor) on Mar 05, 2002 at 16:41 UTC
    That's what I thought too, but won't $cur_balance just keep getting bigger until it's larger than $balance anyway?

    UPDATE: No, it won't. It will run out of balances, and if there's a floating point error (inaccuracy?) the loop might never end.

[reply]
Re (tilly) 2: Instructive bug
by tilly (Archbishop) on Mar 05, 2002 at 17:36 UTC
    You have the right idea. I actually got floats earlier than the 32-bit barrier though. Can anyone other than mpeppler guess why?

    And for perrin, what I did about it was put in a slight fudge factor to handle small roundoffs, and on the inner loop I put a fatal check for overrunning the balances array in case the hack failed. I have had no problems since.

[reply]
      Well, it seems rather as if you were dealing with money here, in which case I imagine that you started out with floating-point values, no?


      If God had meant us to fly, he would *never* have given us the railroads.
          --Michael Flanders

[reply]
      The division will cause a floating point coversion, I believe.
[reply]
        And when dealing with money they arise before that because...?
[reply]
Re: Re: Instructive bug
by mdillon (Priest) on Mar 05, 2002 at 16:48 UTC

    Spoiler? ...don't cheat

    I think that the reason tilly noted that the sum is less that 2 billion was to indicate that the 32-bit barrier is not the problem.

    update: I just realized that you said that $balance * $i could have 32 bit problems, not $balance; my bad.

[reply]
[d/l]
[select]

In Section Meditations