Since the current version of ADOPy (0.3.1) largely focus on the binary choice response, it cannot be extended to tasks with both choice and RT. To make it generalizable to multiple response variables, Task and Engine classes should be updated.

After the posteriors on model parameters converge to a certain degree, ADO provides the same design as an optimal one repeatedly. However, providing the same design repeatedly makes participants feel "something wrong" on the task, which distracts their task performance.

To avoid it, researchers can use filler trials as randomly chosen or pre-determined. However, I thought it would be better for ADOpy engines to consider the history of designs used by themselves. So, inspired by the SARSA(λ) model in the reinforcement learning field (Sutton & Barto, 1998; 2018), using eligibility traces for choosing an optimal design independently to Bayesian updating may solve the issue.

As ADOpy includes several implementations for specific tasks and models, it would be great to include detailed examples for these implementations. However, the current examples somewhat lack descriptions in plain English.

The example files should be included in /docs/source/examples as Jupyter notebook files. If the notebook file is properly executed, it can be automatically integrated into the Sphinx-based documentation (based on nbsphinx).

I recommend placing the Psychopy and Jupyter examples in this repo. Keep everything associated with ADOypy in a single repo. Merge /psychopy-tasks into this one. The main repo should be a one-stop shop for everything ADOpy.

Am I overlooking something?

The current implementation of ADOpy uses the uniform prior by default, and there is no explicit way to use custom priors. Although users can overwrite Engine.log_prior with custom log priors even in the current version, it is not straightforward. Adding a new feature for custom priors would help users customize the ADOpy engine for their preferences.

After installing adopy, I attempt to load the module but I get the following error:
AttributeError: module 'numpy' has no attribute 'int'. 'np.int' was a deprecated alias for the builtin 'int'. To avoid this error in existing code, use 'int' by itself. Doing this will not modify any behavior and is safe. When replacing 'np.int', you may wish to use e.g. 'np.int64' or 'np.int32' to specify the precision. If you wish to review your current use, check the release note link for additional information.

I found a solution online to change the code in ~/opt/miniconda/envs/adopy/lib/python3.9/site-packages/adopy/types.py from np.int to np.int_ and np.float to np.float_
Potential solution: https://stackoverflow.com/questions/74946845/attributeerror-module-numpy-has-no-attribute-int

Make the documentation more easily accessible. There is only one link. Is it part of the repo or not? There is a folder named "docs."

A detailed example of how to use each task needs to be provided, with lots of text explaining what is going on and why. I see one for psychometric function estimation. In addition to breaking the code up into commented sections, include in the repo under "examples" the full Psychopy program that works. Use the same keyboard response for all tasks. Maybe 10 trials. Maybe also add a version in simulation mode, too. As you note in the ms, it is really valuable to see ADO work with differing grid resolutions.

We want users to copy and paste the code into an IDE and have ADO working immediately for them.
.

From issue #3, I stuck with a problem dealing with models with a different number of parameters. So, I'd like to solve it by adding new classes for tasks and models, e.g., TaskInfo, ModelInfo. I'll add comments with detailed ideas.

did not see an existing same issue...can't see how to delete the issue. sorry for the mess

Why the restriction to 3.6? I worry a bit that some will not want to upgrade. 3.5 is still a default for versions of tensorflow, for example. Maybe there will be few in our workshop who use it. Are there issues with 3.5?

• Exponential model (Samuelson, 1937)
• Hyperbolic model (Mazur, 1987)
• Generalized Hyperbolic model (Loewenstein & Prelec, 1992; Green & Myerson 2004)
• Quasi-Hyperbolic (Beta-Delta) model (Phelps & Pollak, 1968)
• Double Exponential model (McClure et al., 2007)
• Constant Sensitivity model (Ebert & Prelec, 2007)

As suggested in issue #8, N-alternative forced choice task should be supported.

Prior to submission of the ADOpy ms, how much of this site should be user-ready?

• The application examples should be embedded in the Wiki or in the Readme. Should the examples be expanded? We need some minimal amount of documentation here. It could be quite elaborate.
• I suggest we support only Python 3. By not supporting 2.7 we might lose some customers, but they should switch to 3.
• We need to add links on how to install the other dependencies. Should we recommend Ananconda or Miniconda? What is the easiest way to ensure a clean and trouble-free installation of Python? This is what we want to recommend.

With the release and publication, we should start using versioning explicitly on the site so users can keep track of updates. I know Jaeyeong has been using it, but it should be explicit on GH and in the manuscript.

The release should be updated in README.md. THere must be automated ways to do this.

To increase the usefulness of the package, it is important to have a method of estimating the threshold of a psychometric function (two choices). This will be very popular in some disciplines. I cannot remember whether we discussed this before, so decided to create this issue. To be most useful, the more complex model should be used with parameters for lapse rate and guessing, but set defaults for these values as I suspect many users will not be interested in them.

I found that travis-ci.org is ceased since June 15th, 2021, and it might be better to find one to replace it for continuous integration. One good candidate is Github Actions, which provides an automative workflow integrated with the Github repository.