Chris Muir

On another thread, problems have been discussed with the accum 

object. The smallest patch that I've been able to create to show this 

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

On another thread, problems have been discussed with the accum 
object. The smallest patch that I've been able to create to show this 
problem is this:

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


accum-bug

I also tried other numbers. When using 10000001 (10m + 1), the last digits are wrong, they seem to show only 2^n last digits:

When using 1000001 (1m + 1), there seems to be no problem, but the error occurs after adding 16 times. Is accum in some way limited to 24-bit (16 m)? The problem is only present when accumulating above this point.

This is something for the likes of Peter Castine, who can think in bytecode, haha.

10000001
20000002
30000004
40000004
50000004
60000004
70000008
80000008
90000008
100000008
110000008
120000008
130000008
140000016
150000016
160000016

This is something for the likes of Peter Castine, who can think in bytecode, haha.


> When using 1000001 (1m + 1), there seems to be no problem, but the

> error occurs after adding 16 times. Is accum in some way limited to

> 24-bit (16 m)? The problem is only present when accumulating above

It's pretty obvious that the internal representation is done in floats, 

which are put back to ints. That would explain it.

It looks there is a limitation to 24-bit precision. Don't know if this 

is a "real" problem though... I am sure its fixable, as a simple abhaxed 

versions is fine, though it will wrap around....

This might be actually the simplest way to avoid wrapping, by converting 

to a float and then reconvert to an int...

Bas van der Graaff schrieb:
> When using 1000001 (1m + 1), there seems to be no problem, but the
> error occurs after adding 16 times. Is accum in some way limited to
> 24-bit (16 m)? The problem is only present when accumulating above
> this point.

It's pretty obvious that the internal representation is done in floats, 
which are put back to ints. That would explain it.

It looks there is a limitation to 24-bit precision. Don't know if this 
is a "real" problem though... I am sure its fixable, as a simple abhaxed 
versions is fine, though it will wrap around....
This might be actually the simplest way to avoid wrapping, by converting 
to a float and then reconvert to an int...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


accum bug