Document pytry-many

[jgosmann]

I only learned about it because of #14. Format of the arguments needs to be looked up and parsed from the source code.

Does anyone else think that pytries instead of pytry-many would be a cute name? 😉

[jgosmann]

Actually I wonder whether it makes sense to integrate Psyrun and Pytry for this sort of functionality. Psyrun could provide more powerful methods of defining the parameter space to explore, could allow for easy parallelization of the the trial, and could add the possibilitiy to easily submit such a parameter space exploration jobs on a cluster like Sharcnet.

Not sure if such functionality would rather be part of Psyrun, pytry, or separate project depending on both Psyrun and pytry.

[tcstewar]

I'm actually more tempted to remove pytry-many altogether. I'm worried about feature-creep -- there are a lot of interesting complications in running lots of simulations... I'm tempted to just encourage people to take the programmatic approach, or to use some other package (like Psyrun) if we want multiple runs....

[jgosmann]

Sounds good, I might think about a convenient way of interfacing these projects. Could call “psytry-many” or just “psytry”. 😉 Though especially for the second one, the one letter difference is way to easy to miss.

[tcstewar]

(I'll also note that the reason that I didn't document pytry-many is that I wasn't sure it should even exist, and completely wasn't sure about the syntax. And the current syntax is horrible. I'm very annoyed at past-Terry for choosing ~ of all things.... the hand position needed to type that is just awkward and it's just completely horrendous in general)

[jgosmann]

the hand position needed to type that is just awkward

That's a bias from the US keyboard layout ;) It's perfectly fine on the [Neo2 layout] that I use.

(to be clear: I'm not seriously saying that it is a good choice.)