I'm beginning to understand.

It looks like you have to watch out for if/then's as much as for if/goto's. 
(I was led to believe that if/then's were much "safer.")

There is one further complicating factor: even if instr 1 starts a bit 
*later* than instr 2, the if comparison in instr 1 still evaluates to 0 (or 
something other than 2) - executing the then condition.

It must have to do with the global variable (givar) being evaluated at 
*orch* initialization rather than at instrument initialization time. I 
gather that orch initialization is done by instrument number order rather 
than start time.

Does this make sense?

Art Hunkins

----- Original Message ----- 
From: "Steven Yi" 
To: 
Sent: Friday, February 17, 2012 8:13 PM
Subject: Re: [Csnd] gi variable evaluation?


Hmm, interesting!  I think I had either looked at this before, forgot
it, and remembered something wrong, or maybe just had it wrong in my
head all this time, and the side effect was that it got me the right
results. (!!)  I went and looked at the code.  In the old parser,
if-then uses cngoto, and if-ithen uses cogoto.  In the new parser, it
looks like it is only using cngoto (that's a bug that should be
fixed...).

So, Matt's correct and the current Csound *does* what he says.

However, I think I do understand what is going on with Art's
situation.  The value that is compared on the first pass is cached as
a boolean on that init-pass.  At that time, the value evaluated to
false, and that is stored in a synthetic b variable.  So going back to
the translated code:

#b0 = (ival == 2)
cngoto #b0, __label0
printk kval
__label0:

That #b0 stores the initial comparison.  Therefore, if it's true or
false at init-time, it's going to stay that way through
performance-time.  If the gival changes, it won't affect the value
used in the conditional check.

This is great that you chimed in Matt, thanks!  Now I've got it
clearer in my head.

(Rory: You may want to revise what you present! :P)

steven


On Fri, Feb 17, 2012 at 11:58 PM, matt ingalls  wrote:
> and just to clarify a bit more, i think this is
> how it should work (at least how it used to)
>
> ival init 0
> if (ival != 0) then
> ; never gets here at i or k passes
> endif
>
> if (kval == kotherval) then
> ; always here at i-pass
> ; could be here or not at k-pass depending on conditional
> endif
>
> if (xval) ithen
> ; here during the i-pass (if conditional was true)
> ; never here during k-pass
> endif
>
> On Feb 17, 2012, at 3:47 PM, matt ingalls wrote:
>
>> steven:
>> if this is how it works now, then
>> this is a change from the original implementation.
>>
>> if/then is supposed to be the equivalent to if/goto
>> and as should do the conditional at BOTH i and k rates.
>>
>>
>>
>> On Feb 17, 2012, at 2:33 PM, Steven Yi wrote:
>>
>>> if (ival != 2) then
>>> printk kval
>>> endif
>>>
>>> becomes:
>>> #b0 = (ival == 2)
>>> cigoto #b0, __label0
>>> printk kval
>>> __label0:
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"

= 

hi art -

you did really start an interesting thread ...

i can't confirm that  "even if instr 1 starts a bit  *later* than instr
2, the if comparison in instr 1 still evaluates to 0 (or something other
than 2) - executing the then condition" (see below, case 3).

i think there are three cases. i have simplified your instrument
slightly to this form:



gival init 0
instr 1
if gival != 2 then
printk .5, gival
endif
print gival
endin
instr 2
gival = 2
endin


i1 0 1
i2 0 1
e



CASE 1
running the csd as here (or in your original post) evaluates the
condition 'gival != 2' as true. so the gate to the 'then' statement is
open, both: at the initialization path and at the performance time.
the change of gival in instr 2 has no effect to this, because it's "too
late" now. but it changes the value of gival from 0 to 2, so this will
be printed during performance time in instr 1 via printk. (printk will
ask for the actual value of gival at its printing time, not for the
first value ever been there.) my output:
instr 1:  gival = 0.000
new alloc for instr 2:
 i   1 time     0.00023:     2.00000
 i   1 time     0.50000:     2.00000
 i   1 time     1.00000:     2.00000

CASE 2
changing the instrument numbers (instr 1 becomes instr 2 and vice versa)
performs the statement 'gival = 2' first, because it now has the lower
instrument number. so the if-condition is false, the gate stays closed,
and the printk is not evaluated at all. this is my output:
new alloc for instr 1:
new alloc for instr 2:
instr 2:  gival = 2.000

CASE 3
going back to the original numbering of instr 1 and instr 2 (as in the
csd above), but now starting instr 1 after instr 2 (at least one k-cycle
after instr 2, for instance 0.001). now instr 2 can change gival to 2,
so when instr 1 starts, the expression 'gival != 2' is false, and the
printk statement is not evaluated at all. this is my printout:
new alloc for instr 2:
B  0.000 ..  0.001 T  0.001 TT  0.001 M:      0.0
new alloc for instr 1:
instr 1:  gival = 2.000
B  0.001 ..  1.000 T  1.000 TT  1.000 M:      0.0
B  1.000 ..  1.001 T  1.001 TT  1.001 M:      0.0

this is with the old parser (csound 5.16). i get the same result with
the new parser. so, no bug / incompatibility, steven?!

thanks, matt, for the condensed overview. i never ever used ithen, but
it might be very useful in certain cases.

	joachim


Am 18.02.2012 03:13, schrieb Art Hunkins:
> I'm beginning to understand.
> 
> It looks like you have to watch out for if/then's as much as for 
> if/goto's. (I was led to believe that if/then's were much "safer.")
> 
> There is one further complicating factor: even if instr 1 starts a
> bit *later* than instr 2, the if comparison in instr 1 still
> evaluates to 0 (or something other than 2) - executing the then
> condition.
> 
> It must have to do with the global variable (givar) being evaluated
> at *orch* initialization rather than at instrument initialization
> time. I gather that orch initialization is done by instrument number
> order rather than start time.
> 
> Does this make sense?
> 
> Art Hunkins
> 
> ----- Original Message ----- From: "Steven Yi"  
> To:  Sent: Friday, February 17, 2012 8:13
> PM Subject: Re: [Csnd] gi variable evaluation?
> 
> 
> Hmm, interesting!  I think I had either looked at this before,
> forgot it, and remembered something wrong, or maybe just had it wrong
> in my head all this time, and the side effect was that it got me the
> right results. (!!)  I went and looked at the code.  In the old
> parser, if-then uses cngoto, and if-ithen uses cogoto.  In the new
> parser, it looks like it is only using cngoto (that's a bug that
> should be fixed...).
> 
> So, Matt's correct and the current Csound *does* what he says.
> 
> However, I think I do understand what is going on with Art's 
> situation.  The value that is compared on the first pass is cached
> as a boolean on that init-pass.  At that time, the value evaluated
> to false, and that is stored in a synthetic b variable.  So going
> back to the translated code:
> 
> #b0 = (ival == 2) cngoto #b0, __label0 printk kval __label0:
> 
> That #b0 stores the initial comparison.  Therefore, if it's true or 
> false at init-time, it's going to stay that way through 
> performance-time.  If the gival changes, it won't affect the value 
> used in the conditional check.
> 
> This is great that you chimed in Matt, thanks!  Now I've got it 
> clearer in my head.
> 
> (Rory: You may want to revise what you present! :P)
> 
> steven
> 
> 
> On Fri, Feb 17, 2012 at 11:58 PM, matt ingalls 
> wrote:
>> and just to clarify a bit more, i think this is how it should work
>> (at least how it used to)
>> 
>> ival init 0 if (ival != 0) then ; never gets here at i or k passes 
>> endif
>> 
>> if (kval == kotherval) then ; always here at i-pass ; could be here
>> or not at k-pass depending on conditional endif
>> 
>> if (xval) ithen ; here during the i-pass (if conditional was true) 
>> ; never here during k-pass endif
>> 
>> On Feb 17, 2012, at 3:47 PM, matt ingalls wrote:
>> 
>>> steven: if this is how it works now, then this is a change from
>>> the original implementation.
>>> 
>>> if/then is supposed to be the equivalent to if/goto and as should
>>> do the conditional at BOTH i and k rates.
>>> 
>>> 
>>> 
>>> On Feb 17, 2012, at 2:33 PM, Steven Yi wrote:
>>> 
>>>> if (ival != 2) then printk kval endif
>>>> 
>>>> becomes: #b0 = (ival == 2) cigoto #b0, __label0 printk kval 
>>>> __label0:
>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker 
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 
>>> Discussions of bugs and features can be posted here To
>>> unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>> "unsubscribe csound"
>>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker 
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 
>> Discussions of bugs and features can be posted here To unsubscribe,
>> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker 
> https://sourceforge.net/tracker/?group_id=81968&atid=564599 
> Discussions of bugs and features can be posted here To unsubscribe,
> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> =
> 
> 
> Send bugs reports to the Sourceforge bug tracker 
> https://sourceforge.net/tracker/?group_id=81968&atid=564599 
> Discussions of bugs and features can be posted here To unsubscribe,
> send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
>