Csound Csound-dev Csound-tekno Search About

[Csnd-dev] wrap opcode bug?

Date2023-01-27 13:33
FromOeyvind Brandtsegg
Subject[Csnd-dev] wrap opcode bug?
The wrap opcode seems to work differently for negative values than it does for positive.

The issue is that for positive values, when ksig == khigh it wraps around to klow (desired behaviour)
For negative values, when -ksig == khigh it outputs khigh.

In the example below I would expect k1 to continue in the same pattern (2,1,0,2,1,0,...) also when the input goes negative. I get (2,1,3,2,1,3,...)
Is there a bug in the opcode (or in my expectation)?

all best
Øyvind

instr 1
  kval init 5
  ktrig metro 1
  k1 wrap kval, 0, 3
  printf "%d %d \n", ktrig, kval, k1
  kval -= ktrig
endin

score:
i1 0 11



Date2023-01-27 14:02
FromVictor Lazzarini
SubjectRe: [Csnd-dev] [EXTERNAL] [Csnd-dev] wrap opcode bug?
I never knew this existed ;)

Anyway, I checked and maybe it’s expected behaviour that is badly documented. The way it seems to work is that negative numbers are wrapped
around the interval [high, low) and non-negative numbers [low, high), so with your example we have counting up from 0

0, 1, 2, 0, 1, 2.,..

and counting down from 0

0,2,1,3,2,1  

I don’t know whether that was the behaviour intended, but that’s what you get.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 27 Jan 2023, at 13:33, Oeyvind Brandtsegg  wrote:
> 
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> The wrap opcode seems to work differently for negative values than it does for positive.
> 
> The issue is that for positive values, when ksig == khigh it wraps around to klow (desired behaviour)
> For negative values, when -ksig == khigh it outputs khigh.
> 
> In the example below I would expect k1 to continue in the same pattern (2,1,0,2,1,0,...) also when the input goes negative. I get (2,1,3,2,1,3,...)
> Is there a bug in the opcode (or in my expectation)?
> 
> all best
> Øyvind
> 
> instr 1
>   kval init 5
>   ktrig metro 1
>   k1 wrap kval, 0, 3
>   printf "%d %d \n", ktrig, kval, k1
>   kval -= ktrig
> endin
> 
> score:
> i1 0 11
> 
> 


Date2023-01-27 14:22
FromOeyvind Brandtsegg
SubjectRe: [Csnd-dev] [EXTERNAL] [Csnd-dev] wrap opcode bug?
Yes, I see that it is what I get ;-)
But don't you think my expectation of how it should work is logical? It might be considered a bug.
I know, backwards compatibility ... but we have fixed clear errors in opcodes earlier too, even if it changes backwards compatibility.

Here's a UDO that behaves like I would expect

opcode wrapping, k, kk
  ; this works like the opcode wrap, but with correct wrapping of negative values
  kval, khigh xin
  if kval>=0 then
    kwrap = kval%khigh
  elseif kval%khigh==0 then
    kwrap = 0
  else
    kwrap = khigh+kval%khigh
  endif
  xout kwrap
endop

Øyvind

fre. 27. jan. 2023 kl. 15:02 skrev Victor Lazzarini <Victor.Lazzarini@mu.ie>:
I never knew this existed ;)

Anyway, I checked and maybe it’s expected behaviour that is badly documented. The way it seems to work is that negative numbers are wrapped
around the interval [high, low) and non-negative numbers [low, high), so with your example we have counting up from 0

0, 1, 2, 0, 1, 2.,..

and counting down from 0

0,2,1,3,2,1 

I don’t know whether that was the behaviour intended, but that’s what you get.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 27 Jan 2023, at 13:33, Oeyvind Brandtsegg <obrandts@GMAIL.COM> wrote:
>
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> The wrap opcode seems to work differently for negative values than it does for positive.
>
> The issue is that for positive values, when ksig == khigh it wraps around to klow (desired behaviour)
> For negative values, when -ksig == khigh it outputs khigh.
>
> In the example below I would expect k1 to continue in the same pattern (2,1,0,2,1,0,...) also when the input goes negative. I get (2,1,3,2,1,3,...)
> Is there a bug in the opcode (or in my expectation)?
>
> all best
> Øyvind
>
> instr 1
>   kval init 5
>   ktrig metro 1
>   k1 wrap kval, 0, 3
>   printf "%d %d \n", ktrig, kval, k1
>   kval -= ktrig
> endin
>
> score:
> i1 0 11
>
>


Date2023-01-27 14:39
FromVictor Lazzarini
SubjectRe: [Csnd-dev] [EXTERNAL] [Csnd-dev] wrap opcode bug?
I actually don't know. Yes, I would expect wrap-around like an oscillator if 0,3 was the range, which is 0,1,2,0,1,2  going up and 0,2,1,0,2,1, going negative, as you said. But maybe it's not what it was meant? Hard to know but it could be a bug ok

Prof. Victor Lazzarini
Maynooth University
Ireland

On 27 Jan 2023, at 14:23, Oeyvind Brandtsegg <obrandts@gmail.com> wrote:


Yes, I see that it is what I get ;-)
But don't you think my expectation of how it should work is logical? It might be considered a bug.
I know, backwards compatibility ... but we have fixed clear errors in opcodes earlier too, even if it changes backwards compatibility.

Here's a UDO that behaves like I would expect

opcode wrapping, k, kk
  ; this works like the opcode wrap, but with correct wrapping of negative values
  kval, khigh xin
  if kval>=0 then
    kwrap = kval%khigh
  elseif kval%khigh==0 then
    kwrap = 0
  else
    kwrap = khigh+kval%khigh
  endif
  xout kwrap
endop

Øyvind

fre. 27. jan. 2023 kl. 15:02 skrev Victor Lazzarini <Victor.Lazzarini@mu.ie>:
I never knew this existed ;)

Anyway, I checked and maybe it’s expected behaviour that is badly documented. The way it seems to work is that negative numbers are wrapped
around the interval [high, low) and non-negative numbers [low, high), so with your example we have counting up from 0

0, 1, 2, 0, 1, 2.,..

and counting down from 0

0,2,1,3,2,1 

I don’t know whether that was the behaviour intended, but that’s what you get.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 27 Jan 2023, at 13:33, Oeyvind Brandtsegg <obrandts@GMAIL.COM> wrote:
>
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> The wrap opcode seems to work differently for negative values than it does for positive.
>
> The issue is that for positive values, when ksig == khigh it wraps around to klow (desired behaviour)
> For negative values, when -ksig == khigh it outputs khigh.
>
> In the example below I would expect k1 to continue in the same pattern (2,1,0,2,1,0,...) also when the input goes negative. I get (2,1,3,2,1,3,...)
> Is there a bug in the opcode (or in my expectation)?
>
> all best
> Øyvind
>
> instr 1
>   kval init 5
>   ktrig metro 1
>   k1 wrap kval, 0, 3
>   printf "%d %d \n", ktrig, kval, k1
>   kval -= ktrig
> endin
>
> score:
> i1 0 11
>
>