# wrap~ (Was: Re: [PD] wave morphing)

Steffen stffn at dibidut.dk
Wed Jan 17 13:51:24 CET 2007

On 15/01/2007, at 14.37, Steffen wrote:

>
> On 15/01/2007, at 11.49, Roman Haefeli wrote:
>
>> exactly, and since [wrap~] gives you the difference between the
>> largest
>> integer not exceeding X and X, it will always give you 0, when X
>> is an
>> integer.
>
> That's how i read it too. But following that: If 0 (zero) is an
> integer (it normally is, right?), then the largest integer not
> exceeding 0 is 0, and the difference is 0-0=0. Problem being that
> wrap~ of the signal 0 gives 1, not 0.
>
> I'd like to know too, as i find the description from the help patch
> confusing (when the input is  integers). As i understand what wrap~
> does (again, on the integer domain), it's like a function f: Z ->
> {0,1} where f(N)=0 and f(Z\N)=1 (where N is the numbers 1,2,3,..
> and Z is the numbers ...,-1,0,1,...).
>
>> the output of [wrap~] is always => 0 and < 1.
>
> Again, i agree that from the description it would make sense if
> that intact was the output domain.  But it doesn't match the
> experience using wrap~.

Can someone give an explanation of why wrap~ behaves as it does for 0
and negative integer signals?

If it is meant do behave like it does, i think it would make sense to
changed the help patch so it matches the behavior. - As the
functionality is described now, i find it expected that it works on
signals as wrap from zexy does on the numbers (when wrap from zexy is
called without arguments).

That said. Why does wrap~ of fx. the signal -0.99 return 0.00999999?
and wrap~ of fx. -5.99 return 0.0100002?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrap~tests.pd
Type: application/octet-stream
Size: 585 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070117/b0c865b5/attachment.obj>
-------------- next part --------------