<div dir="ltr"><font size="2" face="arial, sans-serif">In their latest e-mail on this subject, PST support told me that "<span style="color: rgb(43, 46, 47); line-height: 22px;">Generally, a List cannot be reset while it is running, though it may be that your experiment falls into a small set of cases when it will work."</span></font><div><font color="#2b2e2f" face="arial, sans-serif" size="2"><span style="line-height: 22px;"><br></span></font></div><div><font color="#2b2e2f" face="arial, sans-serif" size="2"><span style="line-height: 22px;">I think I will have to check whether the other properties of the experiment are also working as intended, but as far as I could tell, nothing out of the ordinary was happening. I did also manage to solve the problem of avoiding more than five consecutive repeats: as I suspected, the problem was that the script declares the variables anew at each trial, which resets them to zero and prevents the counter variables from remembering their values. When I declare them as global variables in the userscript, it works as intended. I did have to increase the weights from 3 to 6 to compensate for the decrease in repeats, but now it does approximate a 1:3 switch ratio.</span></font></div><div><font color="#2b2e2f" face="arial, sans-serif" size="2"><span style="line-height: 22px;"><br></span></font></div><div><font color="#2b2e2f" face="arial, sans-serif" size="2"><span style="line-height: 22px;">I will upload the task here soon if you or anyone else want to have a look at it. For now I am just glad that it works the way I expected it to work!<br></span></font><br>On Thursday, April 3, 2014 6:16:29 PM UTC+2, McFarlane, David wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Well, you do well to not take my word for any of this (nor the word 

<br>of PST staff or documentation) and to test everything for 

<br>yourself.  So I am glad that I brought this up, and that you tested 

<br>my statement and reported back.  Looks like my understanding of 

E-Prime is a little off again.

<br>

<br>I had pretty much assumed that when you run a List (List.Run), it 

<br>looks at all the settings activated with the last List.Reset, and 

<br>then runs using those just settings, goodness know what doing a 

<br>List.Reset during the run would do (terminate the run?  be 

<br>ignored?).  But I confess I never tested that.  Until I do that, your 

<br>empirical result trumps my assumption.  Perhaps a List.Rest can 

<br>construct an Order object for running the List on the fly, in which 

<br>case doing a List.Reset during the run can affect the rest of the run 

<br>in a nicely controlled way such as you found.  Might be worth 

<br>prodding the PST folks and see if they could reveal more about how 

List.Reset and List.Run really work.

<br>

<br>So if your tests show that everything works to your satisfaction, 

<br>then you may as well proceed.  And this opens up more possibilities 

<br>(what happens if you change List.ResetCondition or 

TerminateCondition, etc., during the run?)...

<br>

<br>Thanks,

<br>-- David McFarlane

<br>

<br>

<br>At 4/2/2014 11:42 AM Wednesday, LaurensK90 wrote:

<br>>You mentioned not to use SetWeight while the list is running... but 

<br>>that's actually exactly what I've been doing. I received a reply 

<br>>from PST support saying that this was impossible, but after 

<br>>following your suggestion of adding List.Reset, the switch ratio 

<br>>works exactly as intended. They also sent me an example design 

<br>>(attached) using multiple lists with different weights, like you 

<br>>suggested, but since this is not able to make a trial selection 

<br>>based on the previous trial, it results in a switch ratio of 1:3.5 

<br>>instead of 1:3. I know how to solve this, but again, it involves 

<br>>using SetWeight to set the weight of the inappropriate list to zero 

>while it's running.

<br>>

<br>>Does List.Reset have especially disruptive effects on timing, or 

<br>>does running it on every trial have other negative effects I'm not 

<br>>aware of? I can see why this method is a bit unorthodox, but since 

>it works, I feel like I need a very good reason not to use it.

<br>>

<br>>The cheap solution is probably a good option, but I'd still like to 

>understand why this is so difficult.

<br>>

<br>>On Tuesday, April 1, 2014 4:58:48 PM UTC+2, McFarlane, David wrote:

<br>>Well...  Implementing specific constraints on randomization at

<br>>runtime gets very tricky, try searching for discussions using terms

<br>>such as "random", "pseudorandom", "pseudo-random", "constrain", and

<br>>"constraint".  Offhand, I feel very leery of any approach using

<br>>List.SetWeight, and I especially hope that you do not try that while

>the List itself is running!

<br>>

<br>>PST shows one time-honored (though crude) method for implementing

<br>>on-the-fly randomization with contstraints in their "No Repeats on

<br>>Consecutive Trials" examples on their website, and you might adapt

<br>>that approach for your program.  That method, however, is a sort of

<br>>nondeterministic "bogosort" (look that up on Wikipedia) which suffers

>several problems.

<br>>

<br>>The cheap answer, which you will find in other discussions, is just

<br>>to randomize everything before runtime outside of E-Prime.  Construct

<br>>a "random" sequence that has the properties you seek, then implement

<br>>that as a Sequential List in E-Prime.  If you want different random

<br>>orders for different subjects, then construct a few more sequences

<br>>outside of E-Prime, implement each of your sequences as a nested List

<br>>(running in Sequential order), and then have E-Prime pick one of

<br>>those nested Lists on each run (perhaps using a main List set to

<br>>Counterbalance order).  Or, generate your sequence outside of E-Prime

<br>>as a properly formatted .txt or .xml file, and then use List

>LoadMethod "File" to read in the sequence at runtime.

<br>>

<br>>-- David McFarlane

<br>>

<br>>

<br>>At 4/1/2014 08:10 AM Tuesday, LaurensK90 wrote:

<br>> >Now that I have access to E-Basic help again I see that I was

<br>> >mistaken about the function of List.Reset, and appending this to the

<br>> >end of the script caused the experiment to create the appropriate

> >switch ratio. So thank you very much for that suggestion!

<br>> >

<br>> >However, my attempt at preventing the experiment from running more

<br>> >than five consecutive trials of the same type is still not

<br>> >effective. I suspect there's something wrong with the way I'm trying

<br>> >to increment the counter variable, which leads to the second If

> >statement never getting triggered. Could that be the problem?

<br>

<br></blockquote></div></div>

<p></p>

-- <br />

You received this message because you are subscribed to the Google Groups "E-Prime" group.<br />

To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:e-prime+unsubscribe@googlegroups.com">e-prime+unsubscribe@googlegroups.com</a>.<br />

To post to this group, send email to <a href="mailto:e-prime@googlegroups.com">e-prime@googlegroups.com</a>.<br />

To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/e-prime/46005a30-60dd-4d17-8628-32bdaac21ba5%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/e-prime/46005a30-60dd-4d17-8628-32bdaac21ba5%40googlegroups.com</a>.<br />

For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />