Combining design objects into a single block

[adammorrissirrommada]

As far as I can tell, there is no way to interleave design objects into a single block:

myBlock=block('myBlock', myDesign1, myDesign2);

i.e. to present trials from myDesign1 and myDesign2 mixed together into a random order of trials. I thought this used to work, so maybe it changed during one of the re-designs of design.m / block.m ?

@bartkrekelberg - is that right?

[bartkrekelberg]

Not sure if it is currently possible, but it should be...

---

Bart Krekelberg, PhD

Professor, Rutgers University - Newark

Co-Director, Center for Molecular and Behavioral Neuroscience

Associate Director, Rutgers University Brain Imaging Center

197 University Avenue

Newark, NJ 07102

T: 973 419 5118

E: bart@rutgers.edu

W: vision.rutgers.edu

---

From: Adam Morris notifications@github.com Sent: Tuesday, July 17, 2018 6:20:55 AM To: klabhub/neurostim-ptb Cc: Bart Krekelberg; Mention Subject: [klabhub/neurostim-ptb] Combining design objects into a single block (#92)

As far as I can tell, there is no way to interleave design objects into a single block:

myBlock=block('myBlock', myDesign1, myDesign2);

i.e. to present trials from myDesign1 and myDesign2 mixed together into a random order of trials. I thought this used to work, so maybe it changed during one of the re-designs of design.m / block.m ?

@bartkrekelberghttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbartkrekelberg&data=02%7C01%7Cbart%40rutgers.edu%7C23723043e75945df204308d5eb9cb364%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636673980652240603&sdata=Pjqjjj6GyrX5NH4rytRIGY4%2BYfC4sloty9iQIe7Oce0%3D&reserved=0 - is that right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fklabhub%2Fneurostim-ptb%2Fissues%2F92&data=02%7C01%7Cbart%40rutgers.edu%7C23723043e75945df204308d5eb9cb364%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636673980652240603&sdata=QPzISTmGQJFqNcXK63tNYrWAJPXP8xYZbQliBhV7wcg%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALbI06YDb0uEFt5eMYNs2dCXym7tHFAlks5uHWYngaJpZM4VSKNd&data=02%7C01%7Cbart%40rutgers.edu%7C23723043e75945df204308d5eb9cb364%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636673980652250612&sdata=QLEqOhylZsbvBjN7nSgRqq8i72R2VOSF8k1Y%2Bq0SNCM%3D&reserved=0.

[bartkrekelberg]

The array->cell array conversion is not a good idea after all (As @cnuahs pointed out). |The change to loadobj does not fix backward comptability (becuase it creates a cell of an array of design objects, not a cell array of design objects) and other code depends on them being a simple array.

Anyway, this is just a placeholder comment, I will get back to this after my summer vacation.

Maybe @adammorrissirrommada can summarize the problems he was trying to address with teh cell arrays, then we can probably find a more elegant solution.

[adammorrissirrommada]

@bartkrekelberg All these objects (experiment, blocks, designs, conditions. etc) are essentially the same: they have one or more children that should be presented in order, or shuffled, and that can succeed or fail. For example, a block could be repeated if it failed (e.g. the subject failed to reach a certain performance level), just like a trial could.

I played around with a tree architecture the other day, built by chaining together instances of a single class. Control flows down a branch until it hits a leaf, where it sets parameter values for a trial, then comes back up as far as it needs to go before descending again. Randomisation can be done at any level. Do you see any merit in something along these lines? This isn't a FSM, but I suppose it could be.

https://github.com/SysNeuroHub/designTree

[duijnhouwer]

FSM? Flying spaghetti monster?

On Thu, Aug 2, 2018, 3:23 AM Adam Morris notifications@github.com wrote:

@bartkrekelberg https://github.com/bartkrekelberg All these objects (experiment, blocks, designs, conditions. etc) are essentially the same: they have one or more children that should be presented in order, or shuffled, and that can succeed or fail. For example, a block could be repeated if it failed (e.g. the subject failed to reach a certain performance level), just like a trial could.

I played around with a tree architecture the other day, built by chaining together instances of a single class. Control flows down a branch until it hits a leaf, where it sets parameter values for a trial, then comes back up as far as it needs to go before descending again. Randomisation can be done at any level. Do you see any merit in something along these lines? This isn't a FSM, but I suppose it could be.

https://github.com/SysNeuroHub/designTree

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/klabhub/neurostim-ptb/issues/92#issuecomment-409831980, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPheH6El0WLOXxC33bQftRTO61bDpv1ks5uMqj3gaJpZM4VSKNd .

[adammorrissirrommada]

@bartkrekelberg, just a reminder to look over this at some stage.

[bartkrekelberg]

It is not an FSM because the number of states (blocks/trials) is not finite... That said, you are right that there are many things that are similar in blocks and trials and currently treated differently.

I like the idea of using recursion and a tree to determine the flow through blocks and trials, that gives good flexibility. Recursive code is hard to read, but it can be very powerful, especially for this situation with infinite "states".

I am working on something similar to @adammorrissirrommada 's sequence.m that does this and it is going in the right direction. I'll do a few more tests and will then share the code.

Just posting this now to avoid duplicate effort.

[bartkrekelberg]

The blocktree branch has a proposed implementation that gets rid of some of the duplication we had in desigs/blocks etc.

It also solves the problem that the trial and block counters were wacky and that condition numbers were not globally unique.