<div dir="ltr"><DIV>Ahhh, now I see what's happening. It turns out List.Reset does do something like what I expected of it initially: when the script is run, instead of selecting the next item in the list, it simply starts from the beginning again. In practice, this is equivalent to setting the selection to "random with replacement", as it does not remember which of the items it has already selected. In a sample of three blocks where I expected all of my 96 stimuli to be used exactly three times, there was one omitted and one repeated stimulus. That wouldn't happen if the list kept running like it was supposed to.</DIV>
<DIV> </DIV>
<DIV>Now, I <EM>could</EM> fix this by mucking up the item weights <EM>even more</EM>, with a giant If statement that sets the weight of each individual stimulus to zero once it is used so that it cannot be selected on the next trial, but I think I'm pushing my luck as it is, and the random selection is doing a pretty good job of it on its own.</DIV>
<DIV> </DIV>
<DIV>I attached the final version of my experiment, but I didn't include the stimulus files because I don't know if I'm permitted to distribute those. If anyone wants to test it I suggest you modify the experiment to work with placeholder images.</DIV>
<DIV><BR>On Thursday, April 3, 2014 6:16:29 PM UTC+2, McFarlane, David wrote:</DIV>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>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 <BR>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 <BR>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 <BR>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 <BR>>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 <BR>>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 <BR>>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 <BR>>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 <BR>>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 <BR>>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 <BR>> >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 <BR>> >statement never getting triggered. Could that be the problem? <BR><BR></BLOCKQUOTE></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/70462f84-bf29-4bf2-a1cd-7129e934e93e%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/e-prime/70462f84-bf29-4bf2-a1cd-7129e934e93e%40googlegroups.com</a>.<br />
For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />