# Chapter 3 Scripting

The designated outcome of this document is for you to roughly understand the R scripts in the following subsections. The word “roughly” was explicitly chosen, as we are well aware that this document only provides a small outline of all of the included functions in the R package Luminescence. Also, whether you can follow the script or not also highly depends on the individual knowledge or basic R data structures and functions.

What is a script? A script is a sequence of R commands issued in consecutive order that build on each other and which act on a common data origin to produce a desired outcome. Something like the following can be considered a script:

my_value <- 4

x <- my_value
y <- 2
z <- x/y
print(z)
## [1] 2

Of course, this is a very simple script, but ultimately the very essence of a “script”. As soon as you do not run each function directly from the R console, but write the code to a file and then run the whole code at once, it can be considered scripting. Alas, this very document is a script!

The following subsections each contain a self-contained script for a designated purpose (e.g., to calculate the age of a sample starting from *.bin file). There will be no line-by-line code explanations, but only short summaries on what these scripts do and what the intended outcome is.

Writing a script for the analyses of luminescence data is not about the knowledge of the functions in the Luminescence package, but about knowing about data structures and types in R and how to access and process them. To write your own script it is essential to know, e.g., the differences between data.frames and lists and how to index them properly. Since we often operate on multiple data sets (e.g., multipe *.bin files and/or aliquots/grains) it is also mandatory to be well familiar with writing for-loops and how to the *apply-function family.

There are certain good practices to consider when writing a script. First of all, scripts should be concise. Before writing a script you should spend at least some time on thinking about the required input data as well as to clearly define what the outcome of the script should be. There is always a risk of a script to become too convoluted, to a point where it is both slow and hard to comprehend, even for the author. Even if you understand your own script at the time of writing, ask yourself the question if you would also be able to understand it when re-visiting the script a week or a month later. The longer a script and the more convoluted, the harder it will be to re-use a script at a later point in time. This is especially true when a previously working script fails and you have to fix the code first. So instead of writing a very, very long script that does everything consider writing multiple shorter scripts that each specialises in a certain task.

Scripts should be as dynamically coded as possible. This is the very bane of many scripts, because they fail to