Re: different wrap behavior for float/integer

That certainly makes sense. I'm not proposing a change and would be among
the last in line to do so — would likely break a lot of code. Still, it
seems like the more consistent thing to do would be to implement
inclusive-exclusive for all cases. Yes, it would probably confuse new
users, but I can think of about 15 other things in SC (and programming
languages in general) that already have that effect. I am also noticing
that the modulo operation, quite similar in function, does not have this
problem:

(
var x = 51;
var y = 10;
x.asFloat.mod(y.asFloat).postln;
x.asFloat.mod(y.asInteger).postln;
x.asInteger.mod(y.asInteger).postln;
x.asInteger.mod(y.asFloat).postln;
nil;
)

It also reminds me of Select.ar, a similar case in which a "normal"-looking
index signal will virtually never select the last item (SelectX of course
does not have this problem):

s.boot;

(
{

Select.ar(

LFNoise1.kr(4).range(0,2).poll,

[SinOsc.ar(200), PinkNoise.ar(1), Saw.ar(50)]

) * 0.1!2

}.play;
)

I can see the value of an inclusive-inclusive version of wrap for integers
only. I guess I've just never seen an inconsistency quite like this, and
initially found it kind of disturbing. But I mostly agree, it's got
problems no matter which way you slice it.
_________________________
Eli Fieldsteel, DMA (he/him/his)
Director, University of Illinois Experimental Music Studios
Assistant Professor of Composition-Theory
Office: 217-300-0956
MB 4008, School of Music
1114 W Nevada Street
Urbana, IL 61801


On Thu, Feb 25, 2021 at 8:05 PM <[email protected]> wrote:

> 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/
>