is this a single / double precision case ?

yes. you get a similar result with [/ 4] -> [wrap] -> [* 4].

A number like 1/10 can't be accurately represented in binary (just like 1/3 can't be represented in decimal). In short: you shouldn't expect fmod(4.1, 4) to yield exactly 0.1. If you happen to see "0.1", that's the result of rounding.

Your "handmade" version is flawed, e.g. with "4.0002" I get 0.00019.

Just round the output of [expr fmod] to as many fractional digits as you need, e.g. [* 10000] -> [+ 0.5] -> [int] -> [/ 10000] for 4 digits.

BTW, instead of [expr fmod] you can also do [/] -> [wrap] -> [*].

Also note that the behavior of fmod regarding negative numbers is implementation specific, e.g. on my system fmod(-0.1, 1) yields -0.1 (note the negative sign!). On the other hand, [wrap] will *always* yield 0.9 (which I think is also what you would expect).

Christof

On 23.06.2020 01:07, oliver wrote:

hi,

i just stumbled upon a problem when i tried to use [expr fmod] to produce a modified [wrap] object that should be able to produce a float wrapped around an arbitrary limit (not just 1 as in vanilla's [wrap])

i know that there are many ways to do this but i tried the [expr] way and noticed something weird (not sure if that's a bug, though):

i am getting "inconsistent" results from the [expr] object. whereas if i'm cranking out a "handmade" version, the results are what they are supposed to be.

i attached the patch that shows the problem

is this a single / double precision case ?

best

oliver

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list