Ed Hall wrote:
> 
> The phenomenon you report is normal.  (I'm not saying it's intuitive, but
> it's normal.)  What's happening is that the result of dividing by 12 is
> usually (2/3rds of the time) not able to be exactly represented as a
> binary fraction.  This inexact result is either rounded up or down (exactly
> how is based on the binary representation and thus isn't necessarily what
> you'd expect looking at the decimal result).  If it's rounded down,
> multiplying the result by 12 will yield a number just slightly less than
> the original.  Printed to three decimal points, it will look exactly
> like the original number, but taking the int() will show that it falls
> slightly short of the full integer value.  Of course, if the result of
> the devision happened to be rounded up, int() would simply remove the
> miniscule fraction involved.
> 

> 
> Welcome to the world that people who write numeric software have to deal
> with every day.
> 
> To fix your original problem, I'd not divide at all, but instead multiply
> by a number slightly greater than 1/12:
> 
>     i1 = frac(p4 * .08333334)
> 
> I've tested it, and it seems to work as you intended.  (By the way, it
> is almost always better to multiply by the reciprocal than to divide--
> it is much faster on just about any CPU made.  This is especially true
> when scaling at audio rates, for example.)
> 
>                 -Ed

Thanks for your explanation - another victory over the forces of numerical darkness!


Andre

--------------------------------------------------
Andre Bartetzki http://www.kgw.tu-berlin.de/~abart
Studio fuer elektroakustische Musik http://www.kgw.tu-berlin.de/~abart/Steam/steam.html
Hochschule fuer Musik Berlin http://www.hfm-berlin.de

Tel. +49-30-4726629
Tel. +49-30-203092488