Problem with per-trial weight adjustment using setweight

[David McFarlane]

Well, you do well to not take my word for any of this (nor the word 
of PST staff or documentation) and to test everything for 
yourself.  So I am glad that I brought this up, and that you tested 
my statement and reported back.  Looks like my understanding of 
E-Prime is a little off again.

I had pretty much assumed that when you run a List (List.Run), it 
looks at all the settings activated with the last List.Reset, and 
then runs using those just settings, goodness know what doing a 
List.Reset during the run would do (terminate the run?  be 
ignored?).  But I confess I never tested that.  Until I do that, your 
empirical result trumps my assumption.  Perhaps a List.Rest can 
construct an Order object for running the List on the fly, in which 
case doing a List.Reset during the run can affect the rest of the run 
in a nicely controlled way such as you found.  Might be worth 
prodding the PST folks and see if they could reveal more about how 
List.Reset and List.Run really work.

So if your tests show that everything works to your satisfaction, 
then you may as well proceed.  And this opens up more possibilities 
(what happens if you change List.ResetCondition or 
TerminateCondition, etc., during the run?)...

Thanks,
-- David McFarlane


At 4/2/2014 11:42 AM Wednesday, LaurensK90 wrote:
>You mentioned not to use SetWeight while the list is running... but 
>that's actually exactly what I've been doing. I received a reply 
>from PST support saying that this was impossible, but after 
>following your suggestion of adding List.Reset, the switch ratio 
>works exactly as intended. They also sent me an example design 
>(attached) using multiple lists with different weights, like you 
>suggested, but since this is not able to make a trial selection 
>based on the previous trial, it results in a switch ratio of 1:3.5 
>instead of 1:3. I know how to solve this, but again, it involves 
>using SetWeight to set the weight of the inappropriate list to zero 
>while it's running.
>
>Does List.Reset have especially disruptive effects on timing, or 
>does running it on every trial have other negative effects I'm not 
>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.
>
>The cheap solution is probably a good option, but I'd still like to 
>understand why this is so difficult.
>
>On Tuesday, April 1, 2014 4:58:48 PM UTC+2, McFarlane, David wrote:
>Well...  Implementing specific constraints on randomization at
>runtime gets very tricky, try searching for discussions using terms
>such as "random", "pseudorandom", "pseudo-random", "constrain", and
>"constraint".  Offhand, I feel very leery of any approach using
>List.SetWeight, and I especially hope that you do not try that while
>the List itself is running!
>
>PST shows one time-honored (though crude) method for implementing
>on-the-fly randomization with contstraints in their "No Repeats on
>Consecutive Trials" examples on their website, and you might adapt
>that approach for your program.  That method, however, is a sort of
>nondeterministic "bogosort" (look that up on Wikipedia) which suffers
>several problems.
>
>The cheap answer, which you will find in other discussions, is just
>to randomize everything before runtime outside of E-Prime.  Construct
>a "random" sequence that has the properties you seek, then implement
>that as a Sequential List in E-Prime.  If you want different random
>orders for different subjects, then construct a few more sequences
>outside of E-Prime, implement each of your sequences as a nested List
>(running in Sequential order), and then have E-Prime pick one of
>those nested Lists on each run (perhaps using a main List set to
>Counterbalance order).  Or, generate your sequence outside of E-Prime
>as a properly formatted .txt or .xml file, and then use List
>LoadMethod "File" to read in the sequence at runtime.
>
>-- David McFarlane
>
>
>At 4/1/2014 08:10 AM Tuesday, LaurensK90 wrote:
> >Now that I have access to E-Basic help again I see that I was
> >mistaken about the function of List.Reset, and appending this to the
> >end of the script caused the experiment to create the appropriate
> >switch ratio. So thank you very much for that suggestion!
> >
> >However, my attempt at preventing the experiment from running more
> >than five consecutive trials of the same type is still not
> >effective. I suspect there's something wrong with the way I'm trying
> >to increment the counter variable, which leads to the second If
> >statement never getting triggered. Could that be the problem?

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/533d895e.8770320a.7697.ffffa831SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.