1 Start-up notes

1.1 Instalation

The splithalf package can be installed from CRAN or Github:

1.2 Version note

Now on github and submitted to CRAN: VERSION 0.7.1 Featuring reliability multiverse analyses!!!

The current version of splithalf is 0.7.1 [unofficial version name: “Kitten Mittens”]

The most noticable difference to this version is the addition of reliability multiverse functions. Now you can take your splithalf object and run it via splithalf.multiverse to estimate reliability across a user-defined list of data-processing specifications. Then, because sometimes science is more art than science, you can plug the multiverse output into multiverse.plot to generate some sweet visualisations. A tutorial will appear in an upcoming preprint and I will also add a page to this site

Additionally, the output of splithalf has been reworked. Now a list is returned including the specific function calls, the processed data. Since version 0.6.2 you can also set plot = TRUE in splithalf to generate a raincloud plot of the distribution of reliability estimates.

1.3 Citing the package

Citing packages is one way for developers to gain some recognition for the time spent maintaining the work. I would like to keep track of how the package is used so that I can solicit feedback and improve the package more generally. This would also help me track the uptake of reporting measurement reliability over time.

Please use the following reference for the code: Parsons, Sam (2020): splithalf: robust estimates of split half reliability. figshare. Software. https://doi.org/10.6084/m9.figshare.11956746.v4

If (eventually) this documentation turns into a publication, this reference will change.

1.4 User feedback

Developing the splithalf package is a labour of love (and occasionally burning hatred). If you have any suggestions for improvement, additional functionality, or anything else, please contact me (sam.parsons@psy.ox.ac.uk) or raise an issue on github (https://github.com/sdparsons/splithalf). Likewise, if you are having trouble using the package (e.g. scream fits at your computer screen – we’ve all been there) do contact me and I will do my best to help as quickly as possible. These kind of help requests are super welcome. In fact, the package has seen several increases in performance and usability due to people asking for help.

1.5 A note on terminology used in this document

It is important that we have a similar understanding of the terminology I use in the package and documentation. Each is also discussed in reference to the functions later in the documentation.

  • Trial – whatever happens in this task, e.g. a stimuli is presented. Importantly, participants give one response per trial
  • Trial type – often trials can be split into different trial types (e.g. to compare congruent and incongruent trials)
  • Condition - this might be different blocks of trials, or something to be assessed separately within the functions. e.g. a task might have a block of ‘positive’ trials and a block of ‘negative’ trials.
  • Datatype - I use this to refer to the outcome of interest. specifically whether one is interested in average response times or accuracy rates
  • Score - I use score to indicate how the final outcome is measured; e.g. the average RT, or the difference between two average RTs, or even the difference between two differences between two RTs (yes, the final one is confusing)