aboutsummaryrefslogtreecommitdiff
path: root/paper.tex
diff options
context:
space:
mode:
authorBoud Roukema <boud@cosmo.torun.pl>2020-04-18 17:16:49 +0200
committerMohammad Akhlaghi <mohammad@akhlaghi.org>2020-04-18 17:09:17 +0100
commit063b74c653771735a971f98f69075ca7e8237342 (patch)
tree4d000f65ccab12b48f082a12e507e5fbf32093c1 /paper.tex
parent9ac77d020a25757a579c9f0d9b17ade583ec19cf (diff)
Minor language edits in paper.tex
A few more minor language edits. For parseable vs parseable, see https://en.wiktionary.org/wiki/parsable which recommends `parsable` for formal usage.
Diffstat (limited to 'paper.tex')
-rw-r--r--paper.tex14
1 files changed, 7 insertions, 7 deletions
diff --git a/paper.tex b/paper.tex
index 02d898b..299ecd7 100644
--- a/paper.tex
+++ b/paper.tex
@@ -235,7 +235,7 @@ To highlight the uniqueness of Maneage in this plethora of tools, a more elabora
Both are highly dependent on the time they are executed: precise versions are rarely stored, and the servers remove old binaries.
Docker containers are a good example of their short lifespan: Docker only runs on long-term support OSs, not older.
In GNU/Linux systems, this corresponds to Linux kernel 3.2.x (initially released in 2012) and above.
- As plain-text, besides being extremely low volumne ($\sim100$ kilobytes), the project is still human-readable and parseable by any machine, even when it can't be executed.
+ As plain-text, besides being extremely low volume ($\sim100$ kilobytes), the project is still human-readable and parsable by any machine, even when it can't be executed.
\item \label{principle:modularity}\textbf{Modularity:}
A project should be compartmentalized or partitioned into independent modules or components with well-defined inputs/outputs having no side-effects.
@@ -254,14 +254,14 @@ However, designing a modular project needs to be encouraged and facilitated, oth
2) avoid the programming language that is currently in vogue because it is going to fall out of fashion soon and significant resources are required to translate or rewrite it every few years (to stay in vogue).
The same job can be done with more stable/basic tools, and less effort in the long run.
- \emph{Comparison with existing:} Most of the existing tools use the popular language/framework of when they were created. For example, a larger fraction of them are written in Python as we come closer to the present time.
+ \emph{Comparison with existing:} Most of the existing tools use the language/framework that is most popular at the epoch at the time of the tools' created. For example, as we approach the present, successively larger fractions of tools are written in Python.
\item \label{principle:verify}\textbf{Verifiable inputs and outputs:}
The project should contain automatic verification checks on its inputs (software source code and data) and outputs.
When applied, expert knowledge will not be necessary to confirm the correct reproduction.
-\emph{Comparison with existing:} Such verification is usually possible in most systems, but fully maintained by the user.
-Automatic verification of inputs is most commonly implemented in some cases, but much more rarely the outputs.
+\emph{Comparison with existing:} Such verification is usually possible in most systems, but maintenance is the responsibility of the user alone.
+Automatic verification of inputs is commonly implemented, but the outputs are much more rarely verified.
\item \label{principle:history}\textbf{History and temporal provenance:}
No project is done in a single/first attempt.
@@ -270,9 +270,9 @@ It is natural that earlier phases of a project are redesigned/optimized only aft
This is often seen in scientific papers, with statements like ``\emph{we [first] tried method [or parameter] X, but Y is used here because it showed to have better precision [or less bias, or etc]}''.
A project's ``history'' is thus as scientifically relevant as the final, or published version.
-\emph{Comparison with existing:} The systems above that are implemented around version control usually support this principle.
-However, because they are rarely complete (as discussed in principle \ref{principle:complete}), this history is also not complete.
-IPOL, which uniquely stands out in other principles, fails here: only the final snapshot is published.
+\emph{Comparison with existing:} The systems above that are implemented with version control usually support this principle.
+However, because the systems as a whole are rarely complete (as discussed in principle \ref{principle:complete}), their histories are rarely complete.
+IPOL, which uniquely stands out by satisfying several of the other principles, fails here: only the final snapshot is published.
\item \label{principle:freesoftware}\textbf{Free and open source software:}
Technically, reproducibility (defined in \ref{definition:reproduction}) is possible with non-free or non-open-source software (a black box).