Re: different wrap behavior for float/integer

On Fri, Feb 26, 2021 at 3:34 AM <[email protected]> wrote:
>
> Interesting - only when all three numbers are integers are the results different:

That's normal for math method dispatch.

I'm not sure whether it's a good thing or not, but they do mean
different things.

When all the numbers involved are integers, then the boundaries are
discrete and all cases are unambiguous. So the wrapping range is
considered to be a <= x <= b and (b+1) wraps to a. Semantically, it's
"integers between a and b, including both boundaries."

As soon as you introduce a float, then: where should the wrapping
cutoff be? Let's say 0.0 - 1.0, and let's assume a <= x <= b as for
integers. So then 1.0 would not wrap.

What about 1.00000000001?

No matter how you try to reconcile this with the integer way, it's
going to get messy. So JMc defined the range of float method as a <= x
< b (inclusive of the lower boundary, exclusive of the upper).

Integer would be the odd case, then -- but if we used an
inclusive-exclusive boundary for integer wrapping, then you would
have:

~inclusiveExclusiveIntegerWrap = { |x, a, b|
    (x - a) % (b - a) + a
};

~inclusiveExclusiveIntegerWrap.value((0 .. 5), 0, 2)

-> [ 0, 1, 0, 1, 0, 1 ]

And I'm willing to bet a lot of users would find it weird that "I
specified an upper bound of 2 I don't see any 2s" or "there are three
integers 0, 1, and 2 but this produces a 2-number cycle" -- that is,
currently it's confusing, but if you change it, then it will not be
"clear" -- it will just be confusing in a different way.

hjh

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/