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
_______________________________________________
[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
