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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list