Millisecond Forums

<trial start> performs various functions crucial to the script working. Just look at the various things in its /ontrialbegin and /branch logic:

<trial start>
/ontrialbegin = [values.countstart += 1]
/ontrialbegin = [values.selectlightbulb_standard = 1; values.selectlightbulb_adjust = 1; values.selectbank = 1]
/ontrialbegin = [values.current_adjustamount = values.adjustamount]
/stimulusframes = [1 = start, standardbox_out, standardbox_in, lightbulb_standard, adjustbox_out, adjustbox_in, lightbulb_adjust,
standard_amount, adjust_amount, bank, total_amount]
/validresponse = (start)
/branch = [if (values.forced == 0 && values.count_consec_standard != 0 && mod(values.count_consec_standard,values.maxsameoption) == 0) {values.response = "forced_adjust"; trial.force_adjust}]
/branch = [if (values.forced == 0 && values.count_consec_adjust != 0 && mod(values.count_consec_adjust,values.maxsameoption) == 0) {values.response = "forced_standard"; trial.force_standard}]
/branch = [trial.choicephase]
/recorddata = false
</trial>

You need to *preserve* that functionality. Make a copy of <trial start> and call it <trial start2>. Edit it to look like so:

<trial start2>
/ontrialbegin = [values.countstart += 1]
/ontrialbegin = [values.selectlightbulb_standard = 1; values.selectlightbulb_adjust = 1; values.selectbank = 1]
/ontrialbegin = [values.current_adjustamount = values.adjustamount]
/stimulusframes = [1 = standardbox_out, standardbox_in, lightbulb_standard, adjustbox_out, adjustbox_in, lightbulb_adjust,
standard_amount, adjust_amount, bank, total_amount]
/validresponse = (0)
/trialduration = 10
/branch = [if (values.forced == 0 && values.count_consec_standard != 0 && mod(values.count_consec_standard,values.maxsameoption) == 0) {values.response = "forced_adjust"; trial.force_adjust}]
/branch = [if (values.forced == 0 && values.count_consec_adjust != 0 && mod(values.count_consec_adjust,values.maxsameoption) == 0) {values.response = "forced_standard"; trial.force_standard}]
/branch = [trial.choicephase]
/recorddata = false
</trial>

Then adjust the various /branch attributes throughout the script to branch to trial.start2 instead of trial.start.

No sorry, my solution does not work. If I remove start button this way it causes looping. If I am understanding it correctly, this is because the start button is tied to branching to forcedoption when maxsameoption met?

How do I remove START-button after trial 1 of each block without affecting the rest of the task?

Thanks a lot for your help, Dave.

Had a bit of a delay getting a copy of Reynold's original EDT as well as finding a computer that would install and run its 32-bit programming. I confirm that the revised Inquisit EDT script makes the rate of adjustment and range of adjusting-option value work the same as those running in Reynold's original EDT.

There seems to be only one minor discrepancy. In Reynold's EDT, the START-button appears only on the first trial in each block, whereas it appears at the beginning of every trial in the Inquisit version. For my study, I would want to limit the amount of the mouse-clicking/movements as much as I possibly can. 

To remove these extra START-button appearances, I've made it so that all <trial intertrialinterval> elements that previously branched to trial.start now branched to trial.choicephase. This seemed to work, but would like to check with you if making such changes might cause any problems (e.g., data recording/collection)?

Thanks for laying out those details -- I agree that this is a reasonable, alternative reading of the adjustment rules, which better comports with the range (0 to 30+) reported in the 2006 paper. The discrepancy is indeed due to a difference in interpretation pertaining to when / where rounding is applied. The Inquisit code calculates a value called "change" (values.change) based on the current adjustment percentage. It rounds this change-value to the nearest cent, and the result is then added to or subtracted from the adjustment amount (values.adjustamount) to produce the new value.

<expressions>
...
/adjust_noreversal = {
if (list.adjust_next.itemcount == 0) values.percentchange_adjust = values.startadjustamount
else {
        values.percentchange_adjust = list.adjust_next.item(1);
        values.percentchange_adjust -= values.adjustvalue};
if (values.percentchange_adjust < values.min_adjustvalue) values.percentchange_adjust = values.min_adjustvalue;
values.change = (round((values.percentchange_adjust * values.startadjustamount) *100))/100;
values.adjustamount -= values.change;
if (values.reversaloption == 1) list.adjust_next.insertitem(values.percentchange_adjust, 1);
if (values.reversaloption == 2 && values.percentchange_adjust > values.min_adjustvalue) list.adjust_next.insertitem(values.percentchange_adjust, 1)
}
...
</expressions>

At the 2% change-level, values.change rounds to 0, i.e. effectively values.adjustamount does not / can not change anymore. (You can replicate this in your Excel sheet by rounding the AMOUNT DECREASED column to the nearest cent.)

Removing the above rounding of values.change should effectively bring the Inquisit code in line with your (in all likelihood correct) reading of the adjustment procedure. A revision of the script with the rounding removed is attached, and values.adjustamount should take on values in line with the 0 to 30+ range.

Hope this helps

Hi Dave,

Thank you very much for your speedy response to this post. 

I've attached text from Reynolds (2006) to confirm that the EDT adjusting option value should range from 0.0 to >0.30. The Inquisit version right now is 0.06 to 0.24.

I see what you mean by ambiguity. I've tried a number of different ways and places to round, and it seemed whenever rounding was implemented during calculations (for scenario where only the adjusted option was being selected) the adjusting option value would get stuck somewhere before zero (0.08, 0.06, etc.). So far, the only place I could find  the "(rounded to nearest cent)" being applied, and would still allow the adjusting option to reach 0.0, is if rounding occurred only for the value being displayed. Perhaps where you highlighted in Reynolds & Schiffbauer (2004), the word "starting" means starting for the trial, so that the "(rounded to nearest cent)" describes the value of the adjusting option displayed at the start of each trial. If I am not mistaken, the adjusting option value displayed is the only thing that is rounded while all calculations in the background retain exact numbers?

Attached is an excel sheet showing adjusting-option reaching zero in a scenario where only the adjusting option is selected and the calculations follow the above interpretation (exact numbers calculated and rounded numbers displayed). (For a standard-option only scenario, the adjusting option will reach >.30 if the same rules are followed, but this is not shown). 

> If you do the math by hand/excel, based on the adjusting parameters specified in Reynolds' and Smit's paper,
> the lowest value of the adjusting option should be around $0.00 not $0.06.

This might sound like a dumb question, but could you show me that math? FWIW, the adjustment rules are those detailed in Reynolds & Schiffbauer (2004), which Smits et al. (2013) state to use as well ("The EDT was programmed and implemented exactly as described by Reynolds and Schiffbauer (2004).").

The below excerpt is the description of the adjustment rules from Reynolds & Schiffbauer (2004).



While I did not implement the EDT, as far as I can see the code mirrors that description. The problem may be that there is some ambiguity, i.e. other readings / interpretations of the rule description may be possible -- for example as to when or how exactly rounding occurs -- which would lead to different outcomes in terms of implementation.

So, if you could clarify your reading of the above, ideally including the exact math you're applying, that would be great.

I've run into the same infinite loop problem and would like some help... 

It seems that there is a problem with the default script for the EDT program found in the Inquisit library. I've confirmed with Reynolds that the adjusting (right) amount should reach a value lower than $0.06. I am assuming this is where participants were having the infinite loop?

If you do the math by hand/excel, based on the adjusting parameters specified in Reynolds' and Smit's paper, the lowest value of the adjusting option should be around $0.00 not $0.06. What happens is the participants end up continuously choose the $0.06 option over the standard $0.30 triggering the infinite loop.

Would really like some help in finding and fixing the problem.  The /maxtimeofscript is not a good solution because the program would essentially err' out without establishing a true indifference point, particularly problematic at lengthier delay blocks!

To clarify, you've set

<values>
...
/maxtimeofscript = 600000
</values>

(10 minutes)

Correct?

In addition, I'd change the /stop logic to

/stop = [script.elapsedtime >= values.maxtimeofscript]