From 5294d5a1e613c78a76e759a898c21be5fe942997 Mon Sep 17 00:00:00 2001 From: Matteo Bongiovanni <40599507+MatBon01@users.noreply.github.com> Date: Thu, 26 Jan 2023 13:45:15 +0000 Subject: [PATCH] Draft the evaluation (#20) * Write section on correctness * Comment on the evaluation of the analysis --- report/evaluation/evaluationplan.tex | 16 +++++++++++++++- report/project/projectplan.tex | 2 +- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/report/evaluation/evaluationplan.tex b/report/evaluation/evaluationplan.tex index db74603..3cf449e 100644 --- a/report/evaluation/evaluationplan.tex +++ b/report/evaluation/evaluationplan.tex @@ -2,4 +2,18 @@ \chapter{Evaluation plan} % 1-2 pages \begin{comment} Project evaluation is very important, so it's important to think now about how you plan to measure success. For example, what functionality do you need to demonstrate? What experiments to you need to undertake and what outcome(s) would constitute success? What benchmarks should you use? How has your project extended the state of the art? How do you measure qualitative aspects, such as ease of use? These are the sort of questions that your project evaluation should address; this section should outline your plan. \end{comment} -\section{During implementation}\label{sec:evaluationduringimplementation} \ No newline at end of file +Evaluation of this project is important as the analyses need to be founded in order to have any sort of real benefit. + +We split the evaluation of the implementation into two halves, the evaluation of the correctness and the evaluation of the analysis. + +\section{Correctness}\label{sec:correctnessevaluation} +In order to evaluate the correctness it is vital to keep good coding practice throughout the project. It is not possible to analyse the performance of something incorrectly implemented, to justify the benefits of a different system entirely. + +In order to do this, unit tests should be written during production, to ensure no developer error or mistake occurs by accident. + +In order to further reduce mistakes, both bugs and theoretical misunderstandings if there are any the results of the two equijoin operations should be compared to ensure that the results are the same and thus they are being judged on the query interpreted in the same way. + +\section{Analysis} +Evaluating the analysis is more difficult. Of course, as per usual benchmarking standards, each test would be run multiple times, changing whether in succession or not (in order to let any potential cache optimisations and ideal memory conditions occur). However these repeat results are conducted, the deviation should be closely monitored to ensure they are consistent. + +It is difficult to suggest comparing deviations of other database systems to the one implemented, even of atomic operations, to ensure they follow a similar distribution of relative performance as databases are so mainstream that query optimisation is commonplace and may affect results in a way that cannot be predicted. \ No newline at end of file diff --git a/report/project/projectplan.tex b/report/project/projectplan.tex index 644f51d..b4b3321 100644 --- a/report/project/projectplan.tex +++ b/report/project/projectplan.tex @@ -19,7 +19,7 @@ \subsection{Implementation} \subsection{Evaluation and analysis} The analysis should begin as soon as the implementation has been completed. At the very least, benchmarking seems to be quite heuristic and experience helps a lot, thus some time should be used to make sure that the results are as accurate as possible. At this stage, if experience has suggested that changing the implementation would not be too much effort, I might also consider changing the data source the tests were based on in order to deal with more interesting or accurate results if any issues seem to emerge. This process should hopefully take a couple weeks. -Evaluation, however, should be done as an ongoing process during the project. A plan to evaluate will be presented in \fref{sec:evaluationduringimplementation}. +Evaluation, however, should be done as an ongoing process during the project. A plan to evaluate will be presented in \fref{sec:correctnessevaluation}. \section{Theoretical analysis of the remaining relational algebra}\label{sec:theoreticalanalysis} After the implementation of the findings of the paper, I hope to have gained a much deeper understanding of the practicalities of database querying. This along with the mathematical intuition I hope to have gained during the stage described \fref{sec:researchstage} would inspire thought to which other operations currently do not adhere to a monadic structure or efficient implementations. Of course this would be greatly aided by research in the large field of database queries, potentially choosing to describe already known optimisations using this new model and adjunctions instead. This section of the project could last until new work is no longer being found.