Agricultural Statistics & Data Science · Statistical computing, data science and practice · also Data Analysis Using Statistical Packages, Statistical Software
Running real analyses in R, SAS, SPSS, Python and Genstat: importing and managing agricultural data, running designed-experiment, survey and genetics analyses, checking outputs, and making the work reproducible with scripts, literate documents and version control. Includes spreadsheet analysis tools that AIEEA-PG names.
In the exams: AIEEA-PG Group 07 'Excel data analysis tools, correlation and regression, t-test and one-way ANOVA' (heavy); AICE-JRF Ag Stat (applied); SAS certifications (heavy)
Statistical analysis in agricultural research is done with software, and the choice and use of that software decide whether results are correct, checkable and repeatable. A variety trial analysed with the wrong error term, a survey analysed without its weights and clusters, a spreadsheet whose formulas were overwritten, or a script that no longer runs because a package changed, all produce numbers that look authoritative and are wrong or irreproducible. This subject teaches how to run real agricultural analyses in the main tools, spreadsheets, R, SAS, SPSS-type point-and-click packages, Genstat and other specialist programs, survey software and web portals, how to check their output, and how to make the whole workflow reproducible with good data management, literate programming and version control.
The manual covers spreadsheet statistical functions and data-analysis tools; R for designed experiments, with linear models, analysis of variance, estimated marginal means and packages for agricultural research; SAS procedures for linear models, mixed models, regression and surveys; SPSS and point-and-click tools, with their uses and limits; Genstat and specialist software for agricultural research; survey analysis software and design-based estimation with weights; data management, with cleaning, validation and metadata; literate programming with R Markdown, Quarto and notebooks; version control with Git; and web-based statistical computing portals for agricultural researchers. Software is described by what it does and how to check it, because versions and interfaces change; principles do not.
Master's admission examinations in agricultural statistics ask about spreadsheet data-analysis tools, correlation and regression, t-tests and one-way analysis of variance; doctoral examinations in agricultural statistics assume applied competence in analysing experiments and surveys with software; and professional statistical-software certifications test procedures, options and output interpretation in detail. Typical questions ask which test or procedure fits a design, how to specify a model with its error structure, what an output value means, and which practice makes an analysis reproducible.
Spreadsheets provide statistical functions for averages, medians, standard deviations (sample and population forms), variances, correlation, the slope, intercept and coefficient of determination of a simple regression, and distribution functions and inverses for the normal, t, chi-square and F distributions, so that p-values and critical values can be computed directly: for example, the two-tailed p-value for t = 2.5 with 10 degrees of freedom, or the critical t for a 95% interval. Most spreadsheet programs also include a data-analysis add-in offering menu-driven procedures: descriptive statistics, histograms, correlation and covariance matrices, multiple regression, t-tests of three kinds (paired, two-sample assuming equal variances and two-sample assuming unequal variances, the Welch test), z-tests, F-tests for two variances, single-factor ANOVA, two-factor ANOVA with and without replication, moving averages, exponential smoothing, random number generation and sampling. These tools are named explicitly in some admission syllabi, and students should be able to set them up and read their output: for a one-way ANOVA with between-group sum of squares 40 on 3 degrees of freedom and within-group sum of squares 120 on 16 degrees of freedom, the output reports mean squares 13.33 and 7.5, F = 1.78, and the p-value; for a regression with regression sum of squares 30 and total sum of squares 40, R² = 0.75.
The paired t-test applies when each observation in one group is matched with one in the other, such as yields of two varieties grown side by side in the same plots or measurements before and after treatment on the same animals; it analyses the differences and removes between-pair variation. The two-sample test assuming equal variances pools the variances of independent groups, while the unequal-variance (Welch) test does not and adjusts the degrees of freedom; it is the safer default when variances may differ. Using a two-sample test on paired data wastes the pairing and usually loses power; using a paired test on independent groups is simply wrong.
Spreadsheet tools suit small, simple analyses and teaching, but they have serious limits for research. The two-factor ANOVA tool handles only balanced data without missing values and does not handle random effects, split plots, incomplete blocks or covariates; there is no general linear model. Output is static and does not update if the data change, and the steps used are not recorded, so the analysis cannot be checked or repeated. Studies of numerical accuracy published over the years have found errors in some statistical functions of spreadsheet programs in difficult cases, although accuracy has improved. Data integrity problems, such as automatic conversion of codes to dates and accidentally sorted columns, are common. Spreadsheets therefore remain valuable for data entry with validation rules, for quick exploration and for presenting tables, while research analyses should be done in software that records the analysis as code.
The regression tool of a spreadsheet produces three blocks of output. Regression statistics give multiple R (the correlation between observed and fitted values), R², adjusted R² (which penalises additional explanatory variables), the standard error of the regression (the square root of the residual mean square) and the number of observations. The ANOVA block splits the total sum of squares into regression and residual parts with an F test of whether the explanatory variables jointly explain variation. The coefficients block gives each estimated coefficient with its standard error, t statistic, p-value and confidence limits; a coefficient divided by its standard error gives t, and for a slope of 0.8 with standard error 0.2, t = 4. Optional residual output and plots help check linearity and constant variance. Correlation output gives a matrix of pairwise Pearson coefficients without p-values, which must be computed separately from t = r√(n − 2)/√(1 − r²). A high R² does not show that a model is correct or causal, and a significant slope fitted to a few points can be driven by one influential observation, so plots should always accompany the numbers.
In R, designed experiments are analysed with linear models specified by formulas. For a randomised complete block design, model <- aov(yield ~ block + variety, data = trial) or lm(yield ~ block + variety, data = trial) fits block and variety effects, provided block and variety are factors, not numbers; a numeric block code would be fitted as a single slope, a common and serious mistake. anova(model) gives the analysis-of-variance table: with five varieties in four blocks, the error has (5 − 1)(4 − 1) = 12 degrees of freedom. A factorial is written yield ~ block + N * P, which expands to both main effects and their interaction. The anova() function reports sequential (Type I) sums of squares, in the order terms appear; with balanced data the order does not matter, but with unbalanced or missing data it does, and Type II or Type III tests (from add-on packages) are used to test each effect adjusted for others, with Type III requiring sum-to-zero contrasts to be meaningful. Split-plot designs can be analysed with aov and an Error term, yield ~ A * B + Error(block/A), which places the main-plot factor A in the block-by-A stratum, or, more generally, with mixed models such as lmer(yield ~ A * B + (1 | block) + (1 | block:A)) from the lme4 package, with denominator degrees of freedom from the Kenward–Roger or Satterthwaite methods.
Estimated marginal means (least-squares means), computed with the emmeans package, are the model-based means of each treatment averaged over the other factors in the design, and differ from raw means when data are unbalanced. emmeans(model, pairwise ~ variety) gives the means with standard errors and pairwise differences, with multiplicity adjustments such as Tukey's method; contrasts can test specific comparisons, such as each new variety against a check, with Dunnett's adjustment, or linear and quadratic trends across fertiliser rates. Compact letter displays summarise groups of means not significantly different, though they invite over-interpretation. The agricolae package, developed for agricultural research, provides functions for randomising and laying out designs (complete blocks, Latin squares, lattices, alpha designs, split plots, augmented designs), multiple comparison procedures such as LSD, Tukey's HSD, Duncan's and Scheffé tests, non-parametric tests, and stability analyses for multi-environment trials.
Every fitted model should be checked before its tests are believed. Plotting the model object gives residuals against fitted values (looking for unequal variance or curvature), a normal quantile plot of residuals, and leverage and influence diagnostics. Residuals plotted against field position or plot order reveal spatial trends that blocking did not remove. Transformations (log for counts or yields with variance increasing with the mean, logit or a generalised linear model for proportions) or variance models may be needed. Reports should give the model formula, the software and package versions, the type of sums of squares, the multiple-comparison method, and the estimated means with their standard errors.
Variety trials are usually repeated across sites and seasons, and plots are often measured several times. Multi-environment trials are analysed with mixed models in which environment, blocks within environment and genotype-by-environment interaction are random or fixed according to the inference intended, for example lmer(yield ~ genotype + (1 | env) + (1 | env:block) + (1 | genotype:env)); heterogeneous error variances across sites and correlated genotype effects need more flexible mixed-model packages. Stability analyses, such as regression of genotype means on environment means (Finlay–Wilkinson or Eberhart–Russell) and AMMI or GGE biplots, are available in agricultural packages. Repeated measurements on the same plots over time are modelled with random plot effects or with correlated residual structures, available in packages for linear and non-linear mixed models; analysing each date separately and ignoring the correlation between dates either wastes information or, when dates are pooled as if independent, overstates precision.
In SAS, PROC GLM fits general linear models for analysis of variance and covariance. A randomised block analysis is written PROC GLM DATA = trial; CLASS block variety; MODEL yield = block variety; LSMEANS variety / PDIFF ADJUST = TUKEY; RUN;. The CLASS statement declares classification factors; MODEL gives the response and effects, with A*B for interactions and A|B as shorthand for main effects plus interaction; MEANS gives raw means and multiple comparisons; LSMEANS gives least-squares means adjusted for other effects, with PDIFF for pairwise tests; CONTRAST and ESTIMATE test user-defined comparisons. PROC GLM prints Type I (sequential) and Type III (each effect adjusted for all others) sums of squares; with balanced data they agree. Its RANDOM statement can identify random effects and produce expected mean squares, but its tests treat all effects as fixed unless the TEST option is used, so mixed models are better fitted with PROC MIXED. PROC REG fits regression models with options for diagnostics: variance inflation factors (VIF) for collinearity, studentised residuals, Cook's distance and leverage for influential points, and model-selection methods; it requires numeric explanatory variables, so categorical variables must be coded as dummies or handled in GLM.
PROC MIXED fits linear mixed models by restricted maximum likelihood (REML, the default) or maximum likelihood. Fixed effects go in the MODEL statement and random effects in a RANDOM statement; for a split-plot in blocks, MODEL yield = A B A*B; RANDOM block block*A; specifies block and main-plot error as random. The REPEATED statement models correlated residuals, such as repeated measurements on the same plot over time, with covariance structures specified by TYPE = (for example CS for compound symmetry, AR(1), UN for unstructured). The DDFM = KR option requests Kenward–Roger degrees of freedom, recommended for small or unbalanced designs. Output includes covariance parameter estimates (variance components), fit statistics for comparing covariance structures, Type III tests of fixed effects and LSMEANS. PROC GLIMMIX extends this to generalised linear mixed models for counts, proportions and other non-normal responses, such as germination counts in trials replicated over sites.
Survey data from stratified, clustered and weighted designs require design-based procedures. PROC SURVEYMEANS estimates means, totals, proportions and their standard errors, with STRATA, CLUSTER and WEIGHT statements describing the design and options for finite population corrections; DOMAIN gives estimates for subpopulations, such as farms below a size threshold, correctly, using the whole design rather than subsetting the data. Companion procedures handle frequencies (SURVEYFREQ), regression (SURVEYREG) and logistic regression (SURVEYLOGISTIC). Variance estimation uses Taylor linearisation by default, with replication methods such as the jackknife, balanced repeated replication and the bootstrap available. Applying ordinary procedures such as PROC MEANS to weighted, clustered survey data gives correct point estimates only if weights are used, and standard errors that are usually far too small.
Menu-driven statistical packages, of which SPSS is the best known and which also include several free open-source graphical front ends to R, let users run analyses by choosing procedures and variables in dialog boxes. They are popular in the social sciences, extension research and teaching because they lower the barrier to entry: a household survey on technology adoption can be tabulated, cross-classified and analysed with chi-square tests, t-tests, ANOVA and regression without writing code. They typically provide a data editor with variable and value labels and defined missing-value codes, descriptive statistics, cross-tabulations, general linear models (univariate, multivariate and repeated measures), mixed models, regression including logistic regression, non-parametric tests, factor and cluster analysis, reliability analysis for questionnaires, and charts. Some include complex-samples modules for survey designs.
The convenience of menus has costs. Each analysis depends on many settings chosen in dialogs, such as the type of sums of squares, the contrasts, the handling of missing values (listwise or pairwise deletion), the post hoc tests and the options for residuals, which are easy to leave at defaults that do not suit the design and are not recorded unless the user saves them. Repeating an analysis months later, or on corrected data, requires repeating every click correctly. The remedy is to use the syntax that menu packages generate: pasting the commands behind each dialog into a syntax file, saving it with the data, and running analyses from it, which gives the same reproducibility as a script. Other limits include the restricted range of designs and models in menus (incomplete blocks, spatial models and complex variance structures often need syntax or other software), the temptation to run many analyses and report only significant ones, and output that is easy to copy without checking. Point-and-click tools are appropriate for learning, exploration and standard analyses, provided the syntax is saved; for complex designs and production work, scripted analysis is preferable.
Menu packages produce long output with many tables, and part of the skill is knowing which to read. For an analysis of variance, the key items are the tests of between-subjects effects (the ANOVA table, with the type of sums of squares stated), the estimated marginal means with standard errors, and the pairwise comparisons with the adjustment named; Levene's test of equal variances and residual plots check assumptions. For regression, the model summary, ANOVA table and coefficients table correspond to those of other software. Output headers state how many cases were used: if this number is much smaller than the number of rows in the data, missing values have caused cases to be dropped. Copying only the p-value without the effect size, its confidence interval and the number of cases used is poor reporting in any software.
Genstat was developed at Rothamsted Experimental Station in England, beginning in the late 1960s under John Nelder, specifically for the analysis of agricultural experiments, and it reflects that origin. Its analysis-of-variance system is built on the separation of the block structure, which describes the units and their nesting (plots within blocks, subplots within main plots), from the treatment structure, which describes the factors applied. A split-plot is specified by a block structure of blocks/wholeplots/subplots and a treatment structure such as variety*nitrogen, and the software automatically determines the strata and error terms, handles any generally balanced design and produces tables of means with appropriate standard errors of differences. It was also among the first statistical systems to implement restricted maximum likelihood (REML) for unbalanced mixed models, derived by Patterson and Thompson in 1971, and generalised linear models, whose theory Nelder and Wedderburn published in 1972. Genstat remains widely used in agricultural research institutes, particularly in parts of Europe, Africa, Asia and Australasia, often through menus that generate commands.
Plant and animal breeding relies on large, unbalanced data sets analysed with linear mixed models that include pedigree or genomic relationship matrices, spatial correlation among neighbouring plots and multiple environments. Specialist REML software was developed for this purpose, notably the ASReml program, written by Gilmour and colleagues and used to fit models with complex variance structures, such as separable first-order autoregressive spatial models for field trials and factor-analytic models for genotype-by-environment interaction across many sites. Similar capabilities are available in R packages for mixed models and in specialised genetic-evaluation software used by national breeding programmes. Other specialist tools generate efficient experimental designs, such as alpha and row–column designs for variety trials, analyse multi-environment trials and stability, map quantitative trait loci, or support crop modelling. Several international agricultural research centres have released free statistical tools tailored to the experiments of their mandate crops.
No single program is best for every task. The choice depends on the design and model required, the institution's existing workflows, licensing costs, the availability of support and training, and the need for reproducibility. A useful discipline is to check important analyses in a second program: if a split-plot analysis in one package and a REML fit in another give the same tests and standard errors, the specification is probably right; if not, the discrepancy usually reveals an error in the model or data. Reports should name the software and version so that others can reproduce the analysis.
Agricultural surveys, such as crop-cutting surveys, farm household surveys and livestock censuses with sample components, usually use stratified multistage cluster designs with unequal selection probabilities. Correct analysis requires telling the software three things: the strata, the primary sampling units (clusters, such as villages or enumeration areas) within strata, and the sampling weights, the reciprocals of the selection probabilities, often adjusted for non-response and calibrated to known totals. Optionally, finite population corrections are given when sampling fractions are large. In R, the survey package defines a design object with svydesign(ids = ~psu, strata = ~stratum, weights = ~wt, data = farms, nest = TRUE), and functions such as svymean, svytotal, svyratio, svyby, svyglm and svytable then produce estimates and standard errors that respect the design. SAS's survey procedures, the complex-samples modules of other packages and dedicated survey software work in the same way.
Weights correct for unequal probabilities of selection. The weighted mean is Σwᵢyᵢ/Σwᵢ: for three farms with weights 10, 20 and 30 and yields 5, 4 and 6 t/ha, it is (50 + 80 + 180)/60 ≈ 5.17, whereas the unweighted mean is 5.0. A total is estimated by Σwᵢyᵢ, here 310 t, since each sampled farm represents w farms. Ignoring weights biases estimates whenever selection probabilities are related to the variable measured, for example when large farms were sampled at a higher rate.
Design-based standard errors account for stratification (which usually reduces variance) and clustering (which usually increases it, because units in the same cluster are similar). Ignoring the clustering and treating the sample as simple random typically understates standard errors, sometimes severely; the ratio of the actual design variance to the simple-random-sampling variance is the design effect, and a design effect of 2.5 means the effective sample size is only 40% of the actual one. Software estimates variances by Taylor linearisation, which approximates non-linear estimators such as ratios by linear ones and computes the variance from the variation between PSUs within strata, or by replication methods, the jackknife, balanced repeated replication and the bootstrap, which recompute the estimate with replicate weights. Common errors include analysing a subpopulation by deleting other records, which destroys the design information and gives wrong standard errors (domain or subpopulation functions must be used instead), strata containing a single PSU, for which variance cannot be estimated without collapsing strata or special options, and confusing sampling weights with frequency or precision weights, which have different meanings in standard procedures.
Design weights are usually adjusted before analysis. Non-response adjustment increases the weights of respondents in groups, called weighting classes, to compensate for non-respondents with similar characteristics, on the assumption that within each class respondents resemble non-respondents. Calibration, including post-stratification and raking, further adjusts weights so that weighted sample totals match known population totals, such as the number of farms by district and size class from a census or register; this corrects for coverage errors and can reduce variance when the calibration variables are related to the survey variables. Extreme weights increase variance and are sometimes trimmed, at the cost of some bias. Survey software must be given the final adjusted weights, and, ideally, information about the calibration or replicate weights that reflect it, so that standard errors account for the adjustment. Documentation of how weights were constructed is part of the survey's metadata and should be released with public-use files.
Good analysis begins with good data. A data management plan, written before data collection, defines what will be recorded, the variable names, units and codes, the validation rules, the file formats and storage, the backup routine and who may access the data. Each experimental unit, plot, animal, household or sample, needs a unique, permanent identifier that links field sheets, laboratory results and treatment lists. Electronic capture on tablets or phones with built-in validation (allowed ranges, required fields, skip logic, drop-down codes) prevents many errors at source; where paper is used, double data entry by two people, with discrepancies resolved against the original sheet, catches typing errors. Date and time should be recorded in an unambiguous format such as ISO 8601 (YYYY-MM-DD).
Cleaning identifies and resolves errors, but it must be documented and reversible. Checks include range checks (a plant height of 3,000 cm), consistency checks between variables (harvest date before sowing date, yield recorded for a plot marked as lost), checks for duplicates and missing identifiers, checks of categorical codes against the allowed list, comparisons with previous measurements of the same unit, and graphical screening for outliers by treatment and by field position. Each correction is made by script, with a comment giving the reason and source (such as the field book), and the raw data are never overwritten. Values that are genuinely unusual but correct are kept; values that are wrong and cannot be corrected are set to missing with a recorded reason. The decision rules for excluding observations should, where possible, be specified before results are known, to avoid biased exclusions.
Metadata, data about data, make a data set understandable and reusable by others and by the original team later. A data dictionary or codebook lists every variable with its name, description, type, units, allowed values or codes, missing-value codes and derivation. Study-level metadata record the purpose, design, location, dates, methods, instruments, people responsible and licence. Standards exist for many data types, such as the Data Documentation Initiative (DDI) for surveys, Dublin Core for general resources and domain ontologies for crop traits and agronomic variables, which help data from different studies be combined. Data are stored in open, non-proprietary formats such as plain-text CSV with UTF-8 encoding, with a README file describing the files, and deposited in repositories that assign persistent identifiers, following the FAIR principles (findable, accessible, interoperable, reusable) while protecting personal and sensitive information.
Agricultural data often include personal information about farmers, households and workers: names, locations, incomes and sometimes health. Data protection laws in many countries require a lawful basis for processing such data, informed consent where appropriate, data minimisation (collecting only what is needed), secure storage, limited retention and protection of individuals' rights. Practical measures include separating identifying information from analysis data and linking them only through a protected key, encrypting files and devices, restricting access by role, recording who accessed or changed data, and anonymising or aggregating data before sharing. Removing names is not sufficient anonymisation when precise coordinates, rare combinations of characteristics or small cell counts allow individuals to be re-identified, so geographic coordinates may be displaced and small cells suppressed in public releases. Research ethics committees and institutional data officers should be consulted when plans involve personal data.
Literate programming, proposed by Donald Knuth in 1984, combines program code and explanatory text in a single document written for human readers. In statistics the idea has become the dynamic or reproducible report: a document that interleaves narrative text with code chunks whose results, tables, figures and numbers in the text, are generated when the document is rendered. If the data change or an error is corrected, re-rendering updates every result, eliminating the copy-and-paste errors that arise when numbers are transferred by hand from software output into a report. R Markdown documents combine Markdown text with R code chunks and inline code such as the mean yield written as an inline expression, and are rendered to HTML, PDF or word-processor formats. Quarto is a newer, multi-language system that supports R, Python and other languages with the same approach and extends it to books, websites and presentations. Jupyter notebooks, widely used with Python and also supporting R, store code cells, outputs and text cells in one file and are popular for interactive exploration and teaching.
Dynamic documents are only reproducible if they run from start to finish in a clean session. Notebooks in particular allow cells to be run out of order, so that the saved output can depend on hidden state, such as a variable defined in a cell later deleted; the remedy is to restart the kernel and run all cells before saving or sharing. Documents should read the raw data and perform all processing, or call scripts that do, rather than depend on objects saved in the user's workspace; set random seeds; load packages explicitly at the start; and record the session information (software and package versions) at the end. Long computations can be cached, with care that caches are invalidated when inputs change. Parameterised reports render the same template for different sites, seasons or crops, which is efficient for routine reporting of multi-location trials. Separating heavy computation into scripts and keeping the report for presentation makes large projects easier to maintain.
Version control records the history of changes to files, so that any earlier version can be recovered, changes can be compared and attributed, and several people can work on the same project. Git is the dominant distributed version-control system: every copy of a repository contains the full history. The basic workflow is to edit files in the working directory, add selected changes to the staging area with git add, and record them as a commit with git commit, giving a message that explains why the change was made. Each commit is a snapshot identified by a unique hash. git status shows what has changed, git diff shows the changes line by line, and git log lists the history. Branches are independent lines of development: git branch and git switch (or checkout) create and move between them, so that an experimental reanalysis can proceed without disturbing the working version, and git merge combines branches. When two branches change the same lines differently, Git reports a merge conflict, which the user resolves by editing the file and committing the result.
A remote repository, hosted on a server or an online hosting service, lets a team share work: git clone copies a repository, git pull fetches and merges others' changes, and git push sends local commits to the remote. Collaborative workflows use branches and review of proposed changes before they are merged into the main branch. Tags mark particular commits, such as the version of the code used for a submitted paper or an official report, so that the exact analysis can be recovered later. Good practice for statistical projects includes committing small, logical changes often with informative messages; keeping code, documentation and small data files under version control; excluding large raw data, generated outputs and confidential files with a .gitignore file (large data are better archived in repositories designed for data, with the code recording their location and checksum); never committing passwords or personal data, since history is hard to erase; and tagging the commit used for every reported result. Version control does not replace backups of data, but together with literate programming and fixed software environments it makes an analysis fully traceable.
A simple, consistent structure makes projects easy to understand and rerun. A common layout has a README describing the project, how to run it and the software required; a data folder with raw data (read-only, possibly stored outside the repository) and processed data generated by scripts; a code or R folder with numbered scripts or functions for import, cleaning, analysis and figures; an output folder for generated tables and figures, which are not edited by hand; a reports folder with the dynamic documents; and a file recording the software environment, such as a lock file of package versions. A single master script or workflow tool runs everything from raw data to final report, so that the whole analysis can be reproduced with one command. Under version control, every change to code and documents is recorded, and tags mark the versions used for reports. A colleague given the repository and the raw data should be able to reproduce every number in the report without asking the author.
Many agricultural research systems and international organisations provide web-based portals and online applications through which researchers can analyse data without installing software. Typical portals let a user upload a data file in a prescribed format, choose a design (completely randomised, randomised block, factorial, split-plot, Latin square, augmented or lattice designs), and obtain an analysis-of-variance table, treatment means, critical differences, multiple comparisons and sometimes stability, genetic-parameter or survey analyses. Some also generate randomised layouts for new experiments. One example is the statistical computing portal developed for a national agricultural research system in South Asia, and similar online tools and interactive applications, often built with R and web frameworks, have been released by universities and international agricultural research centres in other regions. Their advantages are wide access, especially for scientists in institutions without software licences or statistical support, standardised and validated procedures for common designs, and training value.
Portals are convenient, but users remain responsible for the analysis. A portal applies only the designs and models it was built for, so experiments with missing plots, unequal replication, covariates, repeated measures or spatial trends may be analysed incorrectly or not at all; the user must check that the chosen design matches what was actually done in the field. Output should be checked for plausibility, such as error degrees of freedom and means, and important analyses confirmed in a second tool. Because the computation is not under the user's control, reproducibility requires recording the portal, its version or date of use, the options selected and the uploaded file, and saving the full output. Data protection matters: unpublished or confidential data should be uploaded only to services whose data policies are acceptable to the institution. Finally, portals are best seen as a bridge to scripted analysis, not a substitute: a researcher who can reproduce a portal's analysis in code understands what the portal did.
Institutions that run portals or shared analysis services take on responsibilities beyond those of an individual analyst. Procedures offered online should be validated against established software on benchmark data sets, including unbalanced and awkward cases, and the validation should be documented and repeated when the service is updated. Each release should carry a version number shown in the output, so that users can cite it, and changes in methods or defaults should be announced. Help pages should state clearly which designs and assumptions each procedure supports and which it does not. Usage logs, with users' consent, show which analyses are in demand and where users make errors, guiding training. Finally, a service that lets users download the code or a script reproducing their analysis serves both reproducibility and education, because researchers can then see exactly what was computed.
A student uses this subject to analyse coursework and thesis data correctly and reproducibly: running t-tests and one-way ANOVA in a spreadsheet for admission examinations, specifying block, factorial and split-plot models in R or SAS, obtaining least-squares means and adjusted comparisons, analysing a stratified cluster survey with weights, cleaning field data by script with a codebook, writing the thesis results chapter as a dynamic document and keeping the project under version control. Examinations ask which t-test fits a design, how to write a model with its error terms, and how to read software output.
A statistician five years into practice analyses many trials and surveys each season with scripts that read raw data, validate it, fit the right models and generate reports automatically; translates analyses between R, SAS and other packages; advises scientists on whether a portal or menu analysis suits their design; maintains data dictionaries and repositories; and uses version control to track changes requested by collaborators. They routinely check key analyses in a second program and record software versions in every report.
A senior statistician with twenty-five years of experience sets the analysis standards of an institute or programme: which software is supported, how data are managed and archived, what reproducibility is required for publications and official reports, and how scientists are trained. They evaluate portals and specialist software before they are adopted, decide how to migrate legacy analyses when software changes, and ensure that the institute's data are documented and preserved for future use. They also make sure that analysts have the time and training to work reproducibly, rather than treating reproducibility as an afterthought.
A researcher with a PhD and long experience develops software as well as using it: packages that implement new designs and analyses, validated against established programs; reproducible pipelines for large multi-site trial networks; and teaching materials for statistical computing in agricultural research. Such researchers review the software and reproducibility of submitted papers, advise on national statistical computing infrastructure and portals, and examine postgraduate candidates on applied analysis. They contribute to open-source tools and share teaching materials so that good practice spreads.
This manual describes software by function and gives representative syntax; it is not a reference manual for any program, and options, defaults and interfaces change between versions, so current documentation must be consulted. It does not cover every specialist package, cloud analysis platforms, or the details of national statistical portals, which differ by country and change frequently. Commercial programs are named only because the syllabus names them; no endorsement is implied.
Original practice questions written to the syllabus and pattern of the exams named in each question's examTags. They are not past papers and do not reproduce any board's questions.
These notes are free to read here, with no account.
What the Laisha app adds:
Free for ten days, then a subscription. We would rather write that here than have you find it later.