This is the sequence which is repeated at each trial:
- A random choice is made for each modality, 1/8 chance (even the
numbers are 1/8 because a subset of 8 numbers is chosen at the start
of the round).
- A random number is generated between 0 and 1
- If that number is below CHANCE_OF_GUARANTEED_MATCH, a random
modality is chosen and the stimulus is set to what it was N trials ago
This does not apply to Jaeggi mode which generates a sequence prior to
the start of the round which contains a constant number of matches of
each type (4 audio, 4 position, 2 simultaneous).
Paul
On Sun, Dec 6, 2009 at 7:45 PM, argumzio <
argu...@gmail.com> wrote:
> Recently in another thread the issue of CHANCE_OF_GUARANTEED_MATCH was
> raised. Recalling that this wasn't the first time, I thought about
> this matter in private shortly thereafter and wasn't too sure
> regarding the particulars, but now that I have tested my hypothesis
> first-hand, I think there is something to be said for it, and I hope
> Paul and Jonathan are reading.
>
> For the lower NB modes, like DNB and TNB, higher occurrence of matches
> leads to a perceptibly easier session. This significantly reduces the
> executive load since one need not update n-items in memory as
> frequently. (This updating procedure is probably the most central
> aspect to DNB-style training.) However, with the likes of QNB and PNB
> (more so the latter), the nature of the game has changed. When I had
> passed P2B on the 3rd of December, that was when I had eliminated the
> guaranteed match factor (viz., set it to zero); my performance felt
> significantly easier than it did before, when it was at the default
> value of 0.25. Amazed and puzzled, I inquired into the cause of this.
> After having played a few trials where guaranteed match is set to
> 0.90, I have dropped my performance below threshold levels, and the
> difficulty of the task has increased dramatically, so much so that I
> am again at P2B.
>
> This leads me to think a few things:
>
> (1) 1/8 for n options leads to an uneven distribution of answer
> probability, such that (1/8)^5 would be the actual value for an answer
> like PCIAA in PNB, whereas it's ideal frequency would be something
> like 1/32 (based on 2^n = nNB, where n=5)
> (2) Weighted probabilities would better reflect a more evenly
> distributed occurrence of possible answers.
> (3) The cognitive load of recalling 5 items as opposed to 2 items
> instantaneously must be accounted for in the software design; since
> recalling 5 items has such a minimal chance of happening (where
> guaranteed match = 0), decreasing chance of guaranteed match would NOT
> make the task more difficult but the reverse: easier.
>
> Here are the possible outcomes of PNB (PCIAa form):
>
> {Nil response}, {P, C, I, A, a}, {PC, PI, PA, Pa, CI, CA, Ca, IA, Ia,
> Aa}, {PCI, PCA, PCa, CIA, CIa, CAa, PAa, PIA, PIa, IAa}, {PCIA, PCIa,
> PCAa, PIAa, CIAa}, {PCIAa}
>
> Generalizing therefrom, we get:
>
> Nil response: 1/32
> Single response: 5/32
> Double response: 10/32 = 5/16
> Triple response: 10/32 = 5/16
> Quadr. response: 5/32
> Pentu. response: 1/32
>
> The program may have to reflect the actual possible answers'
> distribution, because as it stands this is what it looks like with
> guaranteed match set to zero:
>
> P = 1/8 (8 spaces)
> C = 1/8 (8 colors)
> I = 1/8 (8 pentominoes)
> A = 1/8 (8 letters)
> a = 1/8 (8 letters; 14 numbers -> 1/14)
>
> (Thus, probabilities are analogous to flipping 5 octahedral dice at
> once. Deviating from the item types, as in the case of numbers, would
> serve to amplify the problem, if their value is greater than 8 total.)
>
> CHANCE_OF_GUARANTEED_MATCH = 0.375 would lead to 1/8 -> 1/2, which
> would reflect the actual possible answers' distribution (including nil
> response). Even if this were the setting, it may still be too easy,
> because the overall distribution would not quite be weighted to the
> more difficult triple, quadruple, and quintuple response items. So
> something like .4 would be the minimum to achieve a balance between
> cognitive load and non-repetition.
>
> Be all this what it may, this is simply a general outline of the
> issue, and may not reflect an actual solution to what I see as a
> problem. Note that I am following this description in the config.ini
> in addition to my observations of the nature of the task:
>
> # The chance that a match will be generated by force, in addition to
> the
> # inherent 1/8 chance. Setting this to 1 will guarantee at least one
> match
> # each trial (and will cause some repetitive sequences to be
> generated).
> # The value must be a decimal from 0 to 1
> # Increasing this value will make the n-back task significantly
> easier.
>
> Any clarifications (e.g., the nature of "force" in the above, etc.),
> thoughts (e.g., refinement of the design, etc.), etc. would be very
> helpful on this matter. Since I have clearly thought this over, I do
> not think a "variable match" (as I had said earlier) would be adequate
> to ameliorating the situation; the matter is a little more subtle than
> pure "randomness" since we have to figure in cognitive demands (not
> just pure probabilities).
>
> argumzio
>
> --
>
> You received this message because you are subscribed to the Google Groups "Dual N-Back, Brain Training & Intelligence" group.
> To post to this group, send email to
brain-t...@googlegroups.com.
> To unsubscribe from this group, send email to
brain-trainin...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/brain-training?hl=en.
>
>
>