[PD] [expr] - fmod weirdness

[Christof Ressi]

> 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200623/e2cfb6c1/attachment.html>