Hi IOhannes, thanks, your explanation helped finding a way to solve this for my specific problem.
-- Orm ---------------------------------------------------------------------- Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main Am Donnerstag, den 07. März 2019 um 11:15:54 Uhr (+0100) schrieb IOhannes m zmoelnig: > On 07.03.19 10:53, Orm Finnendahl wrote: > > Hi, > > > > today I encountered something which seems to be a bug in wrap~ > > (pd-0.49.0) on my architecture. > > probably not a bug in [wrap~]. > > > The attached patch shows that wrap~ > > ist outputting a 1 instead of the expected 0 when inputting the > > division of 880 by 220. Inputting the value 4 with sig~ to wrap~ > > doesn't cause this, so I assume the result of the division is > > represented differently internally. > > yes. > > just connect: > > | > [< 1] > | > [print] > > to see that what you perceive as "1" is really a wee bit smaller. > > > after that, try getting the error by replacing the above with: > > | > [* 262144] > | > [- 262144] > | > > any big number would do, but 262144 is a power of two (2^18), so it > keeps additional errors (introduced by the scaling) low. > > the scale/subtraction gives an error of "-0.0625" (it should be "0", if > "1" really was "1"), which is -1/16. > > unscaling gives an (absolute) error of 2^-22, which is about to be > expected when dealing with numbers in the 128-1024 range. > > fgm,asdr > IOhannes > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
