aboutsummaryrefslogtreecommitdiff
path: root/peer-review
diff options
context:
space:
mode:
Diffstat (limited to 'peer-review')
-rw-r--r--peer-review/1-answer.txt17
1 files changed, 10 insertions, 7 deletions
diff --git a/peer-review/1-answer.txt b/peer-review/1-answer.txt
index b837ce4..76c574e 100644
--- a/peer-review/1-answer.txt
+++ b/peer-review/1-answer.txt
@@ -686,7 +686,6 @@ ANSWER: Maneage is flexible enough to enable a wide range of
workflows to be implemented. This is done by leveraging the
highly modular and flexible nature of Makefiles run via 'Make'.
-
------------------------------
@@ -702,13 +701,17 @@ ANSWER: Floating point errors and optimizations have been mentioned in the
discussion (Section V). The issue with parallelization has also been
discussed in Section IV, in the part on verification ("Where exact
reproducibility is not possible (for example due to parallelization),
-values can be verified by any statistical means, specified by the project
-authors.").
+values can be verified by a statistical method specified by the project
+authors."). We have linked keywords in the latter sentence to a Software
+Heritage URI [swh] with the specific file in the Peper and Roukema
+Maneage'd paper that illustrates an example of how statistical
+verification of parallelised code can work in practice.
+
+We would be interested to hear if any other papers already exist that use
+automatic statistical verification of parallelised code as has been done
+in this Maneage'd paper.
-#####################
-Find a good way to link to (Peper and Roukema:
-https://doi.org/10.5281/zenodo.4062460)
-#####################
+[swh] https://archive.softwareheritage.org/swh:1:cnt:4217e24e4a474ba43a4d30abfb0a42b823ef4640
------------------------------