\documentclass[manuscript,screen,nonacm]{acmart}

%%
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
  \providecommand\BibTeX{{%
    Bib\TeX}}}
    
%\setcopyright{acmcopyright}
%\copyrightyear{2022}
%\acmYear{2022}
%\acmDOI{XXXXXXX.XXXXXXX}    

    
\usepackage{adjustbox}
%\usepackage{rotating}
%\usepackage{algorithmicx}
%\usepackage[linesnumbered,ruled,vlined]{algorithm2e}
%\usepackage{amsfonts}
%\usepackage{amssymb}
%\usepackage{amsmath}
%\usepackage{amsthm}
%\usepackage{booktabs}
%\usepackage{cancel}
%\usepackage{cite}
%\usepackage{color}
%\usepackage{epsfig}
\usepackage[graphicx]{realboxes}
%\usepackage{mathrsfs}
\usepackage{mathtools}
%\usepackage{moresize}
\usepackage{multirow}
\usepackage{color, colortbl}
\usepackage{paralist}
\usepackage{listings}
\usepackage{xcolor}
\lstset{
  backgroundcolor=\color{lightgray},
  basicstyle=\ttfamily\small\linespread{0.95}\selectfont,
  frame=single,                         
  framerule=0pt,                       
  rulecolor=\color{lightgray},         
  framesep=0pt,                         
  xleftmargin=1em, xrightmargin=1em,   
  showstringspaces=false,
  breaklines=true,
  aboveskip=7pt,
  belowskip=0pt,
}
\usepackage{url}
%\usepackage{pifont}
\usepackage{pgfplots}
%\usepackage{pgf-pie}
%\usepackage{rotating}
\usepackage{subfigure}
%\usepackage{tabu}
\usepackage{threeparttable}
\usepackage{tikz}
\usetikzlibrary{positioning,shapes,arrows,shadows}
%\usepackage[dvipsnames,table]{xcolor}
\citestyle{acmauthoryear}
\pgfplotsset{compat=1.8}
\usepackage{pgfplotstable}
\renewcommand*{\familydefault}{\sfdefault}
%\usepackage[none]{hyphenat}

\definecolor{Gray}{gray}{0.97}
\renewcommand{\vec}{\mathbf}

\newcommand{\CM}{\ding{51}}
\newcommand{\XM}{\ding{53}}
\DeclareMathOperator*{\argmax}{\arg\!\max}
\DeclareMathOperator*{\argmin}{\arg\!\min}
\DeclareMathOperator{\sign}{sgn}

\def\hl{\setlength{\fboxsep}{1.0pt}\colorbox[rgb]{0.85,0.85,0.85}}

\newtheorem{example}{Example}
\newtheorem*{example*}{Example}
\newtheorem{definition}{Definition}
\newtheorem{theorem}{Theorem}
\newtheorem{lemma}{Lemma}
\newtheorem{proposition}{Proposition}


\usepackage{xpatch}

\makeatletter
\xpatchcmd{\ps@firstpagestyle}{Manuscript submitted to ACM}{}{\typeout{First patch succeeded}}{\typeout{first patch failed}}
\xpatchcmd{\ps@standardpagestyle}{Manuscript submitted to ACM}{}{\typeout{Second patch succeeded}}{\typeout{Second patch failed}}    \@ACM@manuscriptfalse% Also in titlepage
\makeatother

\settopmatter{printacmref=false} % Removes citation information below abstract
\renewcommand\footnotetextcopyrightpermission[1]{} % removes footnote with conference info
\setcopyright{none}
\pagestyle{plain} % remove running headers


%\renewcommand{\mathbf}{\vec}

\usepackage{xr}
\makeatletter
\newcommand*{\addFileDependency}[1]{
  \typeout{(#1)}
  \@addtofilelist{#1}
  \IfFileExists{#1}{}{\typeout{No file #1.}}
}
\makeatother
\newcommand*{\myexternaldocument}[1]{
    \externaldocument{#1}
    \addFileDependency{#1.tex}
    \addFileDependency{#1.aux}
}
\myexternaldocument{main}

\title[User Manual for EDOLAB]{User Manual for EDOLAB: Running, Configuring, and Extending the Platform}

\author{Mai~Peng}
\email{pengmai1998@gmail.com}
\authornote{For assistance with EDOLAB's code or any related inquiries, please feel free to reach out to Danial Yazdani at danial.yazdani@gmail.com or Mai Peng at pengmai1998@gmail.com.}
\affiliation{%
  \institution{School of Automation, China University of Geosciences, Wuhan, Hubei Key Laboratory of Advanced Control and Intelligent Automation for Complex Systems, and Engineering Research Center of Intelligent Technology for Geo-Exploration, Ministry of Education}
  \country{China (email: pengmai1998@gmail.com)}
 \postcode{430074}
}


\author{Delaram~Yazdani}
\email{delaram.yazdani@yahoo.com}
\affiliation{%
  \institution{Liverpool Logistics, Offshore and Marine (LOOM) Research Institute, Faculty of Health, Innovation, Technology and Science, Liverpool John Moores University}
  \city{Liverpool}
  \country{United Kingdom (email: delaram.yazdani@yahoo .com)}
 \postcode{L3 3AF}
}


\author{Danial~Yazdani}
\authornotemark[1]
\email{danial.yazdani@gmail.com}
\affiliation{%
  \institution{School of Computing Technologies, RMIT University}
  \city{Melbourne}
  \country{Australia (email: danial.yazdani@gmail .com)}
  \postcode{3000}
}

\author{Zeneng~She}
\email{20s151103@stu.hit.edu.cn}
%\authornote{The first six authors contributed equally to this work.}
\affiliation{%
  \institution{School of Computer Science and Technology, Harbin Institute of Technology}
  \city{Shenzhen}
  \country{China (email: 20s151103 @stu.hit.edu.cn)}
 \postcode{518055}
}


\author{Wenjian~Luo}
\email{ luowenjian@hit.edu.cn}
%\authornote{The first six authors contributed equally to this work.}
\affiliation{%
  \institution{Guangdong Provincial Key Laboratory of Novel Security Intelligence Technologies, Institute of Cyberspace Security, School of Computer Science and Technology, Harbin Institute of Technology}
  \city{Shenzhen}
  \country{China (email: luowenjian@hit.edu.cn)}
 \postcode{518055}
}

\author{Changhe~Li}
\email{changhe.lw@gmail.com}
\affiliation{
  \institution{School of Artificial Intelligence, Anhui University of Science \& Technology, State Key Laboratory of Digital Intelligent Technology for Unmanned Coal Mining, Anhui University of Science \& Technology}
  \city{Hefei}
  \country{China (email: changhe.lw@gmail.com)}
 \postcode{230026}
}

\author{Juergen~Branke}
\email{Juergen.Branke@wbs.ac.uk}
\affiliation{%
  \institution{Warwick Business School, University of Warwick}
  \city{Coventry}
  \country{United Kingdom (email: Juergen.Branke @wbs.ac.uk)}
  \postcode{CV4 7AL}
}

\author{Trung~Thanh~Nguyen}
\email{T.T.Nguyen@ljmu.ac.uk}
\affiliation{%
  \institution{The Liverpool Logistics, Offshore and Marine (LOOM) Research Institute, Faculty of Health, Innovation, Technology and Science, Liverpool John Moores University}
  \city{Liverpool}
  \country{United Kingdom (email: T.T.Nguyen@ljmu.ac.uk)}
  \postcode{L2 2ER}
}

\author{Amir~H.~Gandomi}
\email{Gandomi@uts.edu.au}
\affiliation{%
  \institution{Faculty of Engineering \& Information Technology, University of Technology Sydney}
  \city{Ultimo}
  \country{Australia}
  \postcode{2007}
}
\affiliation{%
  \institution{University Research and Innovation Center (EKIK), Obuda University}
  \city{Budapest}
  \country{Hungary (email: Gandomi@uts.edu.au)}
  \postcode{1034}
}

\author{Shengxiang Yang}
\email{syang@dmu.ac.uk}
\affiliation{%
  \institution{Digital Future Institute, School of Computer Science and Informatics, De Montfort University}
  \city{Leicester}
  \country{United Kingdom (email: syang@dmu.ac.uk)}
  \postcode{LE1 9BH}
}

\author{Yaochu~Jin}
\email{jinyaochu@westlake.edu.cn}
%\authornotemark[5]
\affiliation{%
  \institution{Department of Artificial Intelligence, School of Engineering, Westlake University}
  \city{Hangzhou}
  \country{China (email: jinyaochu@westlake.edu.cn)}
  \postcode{301130}
}

\author{Xin~Yao}
\email{xinyao@ln.edu.hk}
\authornotemark[2]
%\authornote{Corresponding author}
\affiliation{%
  \institution{School of Data Science, Lingnan University}
  \city{Hong Kong SAR}
   \country{China (email: xinyao@ln.edu.hk)}
}
%
%

\settopmatter{printacmref=false}
\setcopyright{none}
\renewcommand\footnotetextcopyrightpermission[1]{}
\pagestyle{plain}
\renewcommand{\shortauthors}{Peng et al.}



\begin{document}
 \newpage
 

\renewcommand*{\thesection}{M-\Roman{section}}
\renewcommand*{\thetable}{M-\Roman{table}}
\renewcommand*{\thefigure}{M-\arabic{figure}}
%\renewcommand*{\thesubfigure}{M-(\alph{subfigure})}
\renewcommand*{\theequation}{M-\arabic{equation}} 
 



\authorsaddresses{}
\maketitle

 \clearpage

% \tableofcontents




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\textit{\textbf{Abstract---}}
This user manual provides a comprehensive guide for running, configuring, and extending EDOLAB, an open-source MATLAB platform for evolutionary dynamic optimization algorithms (EDOAs). The platform includes two key applications: the \textit{Education} application, which visualizes algorithm behavior over time, and the \textit{Experimentation} application, which is designed for conducting experiments and comparing algorithms. EDOLAB supports both graphical (GUI) and Code (script-based/non-GUI) modes, offering flexibility to users with different preferences, goals, and levels of expertise. Additionally, instructions are provided for running EDOLAB in GNU Octave, a free and open-source alternative to MATLAB. To begin, clone the EDOLAB repository from GitHub: [\url{https://github.com/EvoMindLab/EDOLAB}].
Below is the list of sections covered in this manual:

\tableofcontents
\addtocontents{toc}{\protect\thispagestyle{empty}}


\section{Architecture}
\label{sec:Architecture}

% EDOLAB is a function-based software implemented in MATLAB. 
% The \emph{MATLAB App Designer} was used to develop the GUI for EDOLAB. 
% The software can be operated either with or without the GUI.

EDOLAB is a function-based software implemented in MATLAB. 
It supports two modes of operation: \emph{GUI Mode} and \emph{Code Mode}. 
The GUI Mode is programmatically developed using MATLAB's object-oriented programming features and provides a user-friendly interface for configuring and managing experiments. 
In contrast, the Code Mode enables users to interact with EDOLAB through direct scripting, offering flexibility for advanced usage, such as manipulating the internal components and procedures of algorithms.

The root directory of EDOLAB includes the following:

\begin{itemize} 
    \item Two $\mathtt{.m}$ files: \begin{inparaenum} 
        \item $\mathtt{GUIMode.m}$ --- the entry point for launching EDOLAB's graphical interface, providing interactive features for configuring and executing experiments, and 
        \item $\mathtt{CodeMode.m}$ --- a script-based interface that allows users to run EDOLAB entirely through code.
    \end{inparaenum}

    \item Six folders: \begin{itemize} 
        \item \texttt{Algorithm} ---  
            This folder contains several sub-folders, each corresponding to an EDOA listed in Table~\ref{tab:algorithms}. 
            Each EDOA sub-folder typically includes the following $\mathtt{.m}$ files:
                \begin{enumerate}
                    \item $\mathtt{main\_EDOA.m}$ --- the main function that invokes and coordinates the EDOA's internal components,
                    \item $\mathtt{SubPopulationGenerator\_EDOA.m}$ --- a function responsible for generating sub-populations used by the optimization component,
                    \item \path{IterativeComponents_EDOA.m} --- a function that implements the EDOA components executed at each iteration or under specific conditions,
                    \item $\mathtt{ChangeReaction\_EDOA.m}$ --- a function that handles change reaction mechanisms following environmental changes, and
                    \item $\mathtt{getAlgConfigurableParameters\_EDOA.m}$ --- a configuration interface function that defines and manages user-modifiable parameters of the EDOA. This function is invoked by \path{getAlgConfigurable-Parameters.m} in the \texttt{Algorithm} folder to provide a unified parameter control interface.
                \end{enumerate}
    
        \item \texttt{Benchmark} ---
            This folder contains a sub-folder for each benchmark generator included in EDOLAB. Each benchmark sub-folder includes three $\mathtt{.m}$ files:
                \begin{enumerate}
                    \item $\mathtt{BenchmarkGenerator\_Benchmark.m}$ --- responsible for initializing the benchmark and generating the sequence of environments,
                    \item $\mathtt{fitness\_Benchmark.m}$ --- defines the baseline function of the benchmark used to compute fitness values, and
                    \item \path{getProConfigurableParameters_Benchmark.m} --- provides a configuration interface for customizing benchmark parameters.
                \end{enumerate}
        
            These functions are invoked by four core $\mathtt{.m}$ files located in the main $\mathtt{Benchmark}$ folder:
                \begin{enumerate}
                    \item $\mathtt{BenchmarkGenerator.m}$ --- serves as the entry point for initializing the selected benchmark and generating its environments,
                    \item $\mathtt{fitness.m}$ --- handles function evaluations by calling the related benchmark's fitness function, manages benchmark state, counters, and gathers performance-related data,
                    \item $\mathtt{EnvironmentVisualization.m}$ --- provides visualization of the environment's landscape in the Education application, and
                    \item $\mathtt{getProConfigurableParameters.m}$ --- offers a unified interface for retrieving and modifying benchmark parameters at runtime.
                \end{enumerate}
    
        \item \texttt{Indicators} ---
            This folder contains a JSON file that defines the available performance indicators in EDOLAB:
                \begin{enumerate}
                    \item \path{indicators.json} --- specifies all supported performance indicators, including their names, types, and visualization options, using a simple and extensible JSON structure.
                \end{enumerate}
        
            \item \texttt{Results} ---
            This folder contains three sub-folders where EDOLAB stores experiment outputs:
                \begin{enumerate}
                    \item \texttt{BatchRecords}: Stores results from multiple experiments executed using the GUI's batch mode. 
                    Each file (saved as a \texttt{.mat} file) contains several experiment outcomes, including individual results and their corresponding settings.
                    
                    \item \texttt{StatisticalAnalysis}: Contains the results of statistical analyses performed via the GUI. These are saved as Excel files and include the applied statistical test, experiment configurations, and computed statistical indicators.
                    
                    \item \texttt{TaskDetailResults}: Stores detailed outputs for each experiment run (from both GUI and Code Mode), saved as Excel files. These include per-run performance statistics, experimental settings, and output values.
                \end{enumerate}
    
        \item \texttt{Utility} ---
            This folder contains various utility functions that support EDOLAB's operations. It includes the $\mathtt{Output}$ sub-folder, which provides functions for generating output files and figures used in experiment reporting and visualization.
            
    \item \texttt{OctaveVersion} ---
    This folder provides a self-contained, Octave-compatible version of EDOLAB designed to operate in code mode only. 
    Users who wish to run EDOLAB in Octave should use the files in this folder directly by executing \texttt{OctaveCodeMode.m}. 
    This implementation is fully independent from the main MATLAB version and has been specifically adapted for the Octave environment.

        \end{itemize} 
\end{itemize}

Regardless of whether EDOLAB is executed via the graphical interface ($\mathtt{GUIMode.m}$) or the script-based interface ($\mathtt{CodeMode.m}$), the core process for running EDOAs remains fundamentally the same. 
Both modes invoke the same set of core functions to execute optimization tasks. 
Understanding this shared execution flow is important for users who wish to extend the platform by adding new algorithms, benchmarks, or performance indicators.
Figure~\ref{fig:Manual:SequenceDiagram} presents a high-level sequence diagram that illustrates how EDOLAB operates internally when executing an EDOA.



After generating the sequence of environments, the initial sub-population(s) or individuals are generated by the sub-population/individual generation function (for example, $\mathtt{SubPopulationGenerator\_AmQSO.m}$).


First, the user sets up an experiment using either the GUI or the script-based interface ($\mathtt{CodeMode.m}$) and initiates the run. 
In both modes, EDOLAB first invokes the function $\mathtt{getAlgConfigurableParameters.m}$ to retrieve the list of configurable parameters for the selected EDOA. 
In Code Mode, these parameters are specified directly within $\mathtt{getAlgConfigurableParameters.m}$ and loaded by $\mathtt{CodeMode.m}$ before being passed to the main algorithm function (e.g., $\mathtt{main\_AmQSO.m}$). 
In GUI Mode, the same function is called to identify available parameters, which are then presented via interactive user interface controls. 
Once the user configures the parameters and starts the task, the GUI reads these values and passes them to the main function for execution.

At the start of the main algorithm function, the benchmark generator function ($\mathtt{BenchmarkGenerator.m}$) is called. 
As with algorithm parameters, benchmark parameters are first defined in $\mathtt{getProConfigurableParameters\_Benchmark.m}$. 
In Code Mode, these parameters are manually edited in the script before being passed to $\mathtt{BenchmarkGenerator.m}$ for initialization. 
In GUI Mode, the parameters are automatically extracted from \path{getProConfigurableParameters-Benchmark.m} and displayed through interface controls for user customization. 
Once the experiment begins, the GUI reads the selected values and passes them to $\mathtt{BenchmarkGenerator.m}$ to initialize the benchmark and generate the sequence of environments.

In EDOLAB's experimentation application, identical random streams are used to initialize benchmark instances and environmental changes in $\mathtt{BenchmarkGenerator.m}$. 
As a result, with the same parameter settings, all algorithms are evaluated on the same sequence of problem instances, ensuring fair comparisons. 
Without controlling random streams, variations in the generated landscapes could introduce unintended differences in problem difficulty~\cite{yazdani2021DOPsurveyPartB}. 
To prevent this, EDOLAB enforces random seed and stream control mechanisms.

After generating the sequence of environments, the initial sub-populations or individuals are created using the corresponding sub-population generation function (e.g., $\mathtt{SubPopulationGenerator\_AmQSO.m}$). 
EDOLAB uses a separate shuffled random seed for initializing the algorithm. 



\begin{figure}[!t]
\centering
\includegraphics[width=0.999\linewidth]{Figures/SeqDiag.pdf}
\caption{A high-level sequence diagram of running an EDOA in EDOLAB.}
\label{fig:Manual:SequenceDiagram}
\end{figure}




At the end of each iteration, if the environment has changed, the change reaction components are called (for example, $\mathtt{ChangeReaction\_AmQSO.m}$). 
The main loop of the EDOA continues until the number of function evaluations ($FE$) reaches its predefined maximum value ($FE_\mathrm{max}$). 
This procedure is repeated for the specified number of runs ($\mathtt{RunNumber}$). 
Afterward, the results are processed, including the calculation of performance indicators. 
The results, along with any collected data, are then sent to output generator functions responsible for creating output plots, tables, and files. 
Finally, the output tables and figures are returned to the interface. In the GUI, users can collect results from multiple experiments and perform further statistical analysis to compare the performance of different algorithms.





Afterward, the main loop of the EDOA is executed. 
In each iteration, the iterative components of the EDOA---such as the optimizer (e.g., PSO or DE), diversity control, and population management~\cite{yazdani2020adaptive}---are executed by calling the corresponding function (e.g., $\mathtt{IterativeComponents\_AmQSO.m}$). 
In many EDOAs with adaptive sub-population numbers and/or population sizes, new individuals or sub-populations are generated when certain conditions are met~\cite{yazdani2021DOPsurveyPartA}. 
Additionally, some diversity and population management components may require the reinitialization of specific sub-populations or individuals. 
When such cases arise, the sub-population or individual generation function is invoked to perform the initialization, and the updated population is then returned to the main EDOA function.


As in many real-world scenarios where the algorithm is explicitly informed about changes—such as through sensors, the arrival of new jobs, or shifts in task priorities---EDOLAB adopts a controlled simulation setup in which the algorithm is notified of environmental changes via a dedicated flag.  
Once a change occurs, the flag is triggered, and the algorithm immediately invokes the change reaction components (e.g., $\mathtt{ChangeReaction\_AmQSO.m}$), regardless of whether it is in the middle of updating a sub-population or performing any other operation. 
This mechanism ensures consistent and fair comparisons by eliminating timing biases that could otherwise arise from delayed or inconsistent triggering of change reaction mechanisms.


The main loop continues until the number of function evaluations ($FE$) reaches the predefined maximum ($FE_\mathrm{max}$). 
This procedure is repeated for the specified number of runs ($\mathtt{RunNumber}$). 
Once all runs are completed, the results are processed, including the calculation of performance indicators. 
The collected data is then passed to the output generation functions responsible for creating plots, summary tables, statistical analysis, and export files. 


\section{Running}
\label{sec:running}

As noted earlier, EDOLAB supports two operational modes: GUI Mode and Code Mode.  
In this section, we describe how to use the platform through both modes, highlighting their respective features and usage scenarios.


\subsection{Running EDOLAB in GUI Mode}
\label{sec:sec:sec:GUI}


The GUI is implemented using MATLAB's object-oriented programming framework and can be launched by running $\mathtt{GUIMode.m}$ from EDOLAB's root directory.  
A minimum MATLAB version of \emph{R2020b} is required to use the GUI. 
For users with older versions, the Code Mode via $\mathtt{CodeMode.m}$ remains fully functional and provides access to all core features (see Section~\ref{sec:sec:CodeMode}).  
The GUI also supports parallel execution using either a \texttt{process pool} or a \texttt{thread pool}, which requires the MATLAB \texttt{Parallel Computing Toolbox} to be installed.
To enable thread pool support, MATLAB \emph{R2024a} or later is required; otherwise, only process pool execution is available.

EDOLAB's GUI includes two main applications---\emph{Experimentation} and \emph{Education}---which are described in the following subsections.


\subsubsection{Experimentation Application}
\label{sec:sec:exprementationModule}

The Experimentation application is designed for conducting and managing optimization experiments.  
Figure~\ref{fig:Manual:ExperimentationModule} shows its interface, which is organized into four main parts:
\begin{enumerate}
\item \emph{Task Settings} --- configure the parameters of experimental tasks,  
\item \emph{Pending Tasks} --- view and manage experiments queued for execution,  
\item \emph{Completed Tasks} --- access results of previously run experiments, and  
\item \emph{Statistical Analysis} --- perform significance tests and visualize performance comparisons.
\end{enumerate}

Each of these components is described in detail in the following paragraphs.


\begin{figure}[!t]
\centering
\includegraphics[width=0.95\linewidth]{Figures/ExperimentationModule.png}
\caption{The Experimentation Application in EDOLAB, providing a graphical interface for configuring and running experiments.}
\label{fig:Manual:ExperimentationModule}
\end{figure}

\paragraph{Task Settings}
This panel provides users with powerful customization capabilities for defining experimental tasks. 
Upon selecting an algorithm (EDOA) or a benchmark generator, the GUI automatically updates to display the relevant configurable parameters for the selected component.  
Once the configuration is complete, the user can click the ``Add Task'' button to queue the task in the pending task list.



\paragraph{Pending Tasks}
This panel displays the list of experimental tasks that have been configured but not yet executed. 
By left-clicking on a task, users can view its detailed configuration, including the selected algorithm, benchmark parameters, run number, and other relevant settings.  
Each task is assigned a unique 4-character ID that remains associated with it throughout its lifecycle, from configuration to execution and post-processing. 
From the task detail view, users can choose to either execute or delete the selected task. 
Once all desired tasks have been added, execution can be initiated by clicking the ``Run Selected Tasks'' button.

EDOLAB supports the concurrent execution of multiple tasks using either multithreading or multiprocessing. 
Within the Pending Tasks panel, users can configure parallelization settings, including:
\begin{itemize}
\item \emph{Use logical processors} --- Enabling this option may increase the number of available workers but could introduce performance trade-offs depending on system architecture.
\item \emph{Select parallel pool type} --- Users can choose between the default \emph{Processes pool}, which provides memory isolation, and the \emph{Threads pool}, which offers faster startup and shared memory.  
Note that the Threads pool is available only in MATLAB R2024a and later. 
Furthermore, the Free Peaks (FPs) benchmark is incompatible with the Threads pool due to its reliance on MEX-based C++ interfaces.
\item \emph{Number of parallel workers} --- This setting defines the maximum number of tasks that can run simultaneously, allowing users to balance performance and system resource usage.
\end{itemize}

During execution, the Pending Tasks table dynamically reflects the status and progress of each task. 
Upon completion, tasks are automatically moved to the \emph{Completed Tasks} panel. 
Users can cancel tasks at any point during execution. 
If no tasks are currently running, users can also choose to shut down the active thread or process pool.  
Shutting down a process pool can help free system memory, but restarting it later will incur additional overhead.





\begin{figure}[!t]
\centering
\includegraphics[width=0.8\linewidth]{Figures/OutpuFigExperimentation.pdf}
\caption{Current and Offline Error Plot from a Completed Experiment in EDOLAB. This figure shows the average convergence behavior of an algorithm, where results are averaged over all runs. The Current Error reflects the algorithm's ability to re-converge after each environmental change. The plot is accessible via the Completed Task Panel in GUI Mode and can also be generated in Code Mode.}
\label{fig:Manual:OutputFig}
\end{figure}

\paragraph{Completed Tasks} 
This panel displays all completed experimental tasks. 
Clicking on any task reveals detailed execution information, including the selected algorithm, benchmark settings, run number, and more. 
Within the task detail view, EDOLAB provides the following five operations for each completed task:

\begin{itemize}
    \item \emph{Plot Results}: Displays trend plots of average current error and offline error ($E_o$) over time across all runs for the selected task (see Figure~\ref{fig:Manual:OutputFig}).
    \item \emph{Save Results}: Saves the detailed results of the selected task to the \texttt{/Results/Task Detail Results} folder. Files are named using the format \texttt{EDOA\_Benchmark\_DateTime.xlsx}.
    \item \emph{Select to SA}: Adds the selected task to the Statistical Analysis (SA) panel for further evaluation. 
    This allows statistical comparison of multiple algorithms on benchmark instances with identical settings and run numbers.
    \item \emph{Move to Pending}: Moves the selected task back to the Pending Tasks panel for re-execution.
    \item \emph{Delete Task}: Permanently deletes the selected task.
\end{itemize}

The Completed Tasks panel also supports batch operations:

\begin{itemize}
    \item \emph{Export Selected Completed Tasks to \texttt{.mat}}: Exports selected tasks and their results to a \texttt{.mat} file for later use. 
    Note that completed tasks are not saved automatically when the GUI window is closed, so saving important tasks is recommended. 
    Exported files are saved in the \texttt{/Results/Batch Records} folder and follow the naming format:  \texttt{CompletedTasks\_DateTime.mat}.
    \item \emph{Import Completed Tasks from \texttt{.mat}}: Imports previously saved \texttt{.mat} files. 
    Tasks with duplicate IDs are skipped to avoid duplication.
    \item \emph{Add Selected Completed Tasks to SA}: Adds the selected tasks in batch to the Statistical Analysis panel.
    All tasks must have identical benchmark settings and run numbers to ensure valid comparisons.
    \item \emph{Delete Selected Completed Tasks}: Permanently deletes selected tasks from the Completed Tasks panel.
\end{itemize}

In addition, EDOLAB provides checkboxes for selecting specific performance indicators to display in the panel. 
This allows users to focus on relevant metrics, and the system supports user-defined indicators for customized analysis.

\begin{figure}[!t]
\centering
\begin{tabular}{cc}
    \subfigure[{\scriptsize Friedman Test Results.}]{\includegraphics[width=0.485\linewidth]{Figures/FriedmanResults.png}\label{fig:Manual:friedman}}
&
     \subfigure[{\scriptsize Wilcoxon Signed-rank Test Results.}]{\includegraphics[width=0.485\linewidth]{Figures/WilcoxonSignedRankResults.png}\label{fig:Manual:signedRank}}
\end{tabular}
\begin{tabular}{c}
 \subfigure[{\scriptsize Wilcoxon Rank-sum Test Results.}]{\includegraphics[width=0.5\linewidth]{Figures/WilcoxonRankSumResults.png}\label{fig:Manual:rankSum}}
\end{tabular}
\caption{Tabular Summary of Statistical Analysis Results in EDOLAB. This figure showcases the output tables generated in the Statistical Analysis Panel of GUI Mode. The tables summarize statistical comparisons across multiple algorithms.}
\label{fig:Manual:SAResults}
\end{figure}

\paragraph{Statistical Analysis} 
This panel allows users to perform in-depth comparisons of algorithm performance across multiple completed experimental tasks added to the Statistical Analysis (SA) list. 
Once tasks are selected, EDOLAB provides two main analytical tools: \emph{Statistical Tests} and \emph{Result Visualization}.

\begin{figure}[!t]
\centering
\begin{tabular}{cc}
    \subfigure[{\scriptsize Trend Plot of $E_o$.}]{\includegraphics[width=0.485\linewidth]{Figures/trendEo.eps}\label{fig:Manual:trendEo}}
&
     \subfigure[{\scriptsize Trend Plot of $E_{bbc}$}]{\includegraphics[width=0.485\linewidth]{Figures/trendEbbc.eps}\label{fig:Manual:trendEbbc}}
\end{tabular}
\caption{This figure visually compares the performance of algorithms using trend plots of $E_o$ over all fitness evaluations and $E_{bbc}$ over all environments. Each plot shows the average results across all runs for each algorithm. These visualizations are generated through the Statistical Analysis Panel in GUI Mode.}
\label{fig:Manual:trendPlots}
\end{figure}

\begin{itemize}
    \item \emph{Statistical Tests} --- The current version of EDOLAB supports three widely used non-parametric hypothesis testing methods for evaluating the significance of performance differences across selected indicators and algorithm configurations:
        \begin{itemize}
            \item \emph{Friedman test}: Detects differences in performance across multiple algorithms on the same set of tasks. 
            It ranks algorithms per task and tests whether the average ranks differ significantly. 
            If significant differences ($p < 0.05$) are detected, the \emph{Nemenyi test} performs pairwise comparisons to identify which algorithm pairs differ. 
            Algorithms sharing the same letter (e.g., ``a'', ``b'') in the ranking column are not significantly different at the 95\% confidence level.
            \item \emph{Wilcoxon signed-rank test}: This non-parametric test compares the performance of two algorithms under the same experimental conditions. 
            For each selected performance indicator, EDOLAB computes and displays the number of wins, ties, and losses of each algorithm against the other comparison algorithms.
            \item \emph{Wilcoxon rank-sum test} (Mann–Whitney U test): This test compares the performance of two independent algorithms across selected indicators. 
            EDOLAB summarizes the results in terms of wins, ties, and losses across all selected tasks.
        \end{itemize}
    Users can select one of the available methods for their analysis. 
    As shown in Figure~\ref{fig:Manual:SAResults}, EDOLAB generates a tabular summary for each statistical test, including the Friedman test, Wilcoxon signed-rank test, and Wilcoxon rank-sum test. 
    Each table includes algorithm rankings or win–tie–loss summaries, depending on the method used. 
    All result tables also include experiment metadata such as benchmark configuration, parameter settings, and the number of runs. 
    The results can be exported as Excel files, which are saved in the \texttt{/Results/Statistical Analysis} directory using the naming convention \path{SA_AnalysisMethod_DateTime.xlsx}.
    \item \emph{Result Visualization} --- This feature generates graphical representations of selected task outcomes to support intuitive performance analysis. It includes three visualization components:
        \begin{itemize}
            \item \emph{Trend Plots} --- These plots show the evolution of selected performance indicators over time (e.g., $E_o$ versus fitness evaluations or $E_{bbc}$ versus environment number; see Figure~\ref{fig:Manual:trendPlots}). 
            User-defined indicators are also supported, as described in Section~\ref{sec:sec:extensionIndicator}.
            \item \emph{Box Plots} --- Notched box plots visualize the distribution of final performance indicator values across tasks (see Figure~\ref{fig:Manual:boxPlots}). Like trend plots, box plots also support user-defined indicators.
            \item \emph{Current Error Plots} --- These plots display the current error of the best-so-far solution within the current environment, averaged across all runs (see Figure~\ref{fig:Manual:currentErrorPlot}). 
            Unlike other trend plots, they specifically highlight the real-time convergence behavior of algorithms within each environment.
            Current error plots offer valuable insight into an algorithm's convergence dynamics, including how quickly it responds to environmental changes and how effectively it converges during each environment.
        \end{itemize}
    Only tasks with identical benchmark configurations and number of runs can be included in the SA list. 
    To simplify task selection, the \texttt{Auto Matching} button searches the \emph{Completed Tasks} panel for experiments that match the configuration of the task(s) already in the SA list and adds them automatically. 
    A \texttt{Delete SA Tasks} button is also provided to remove selected tasks from the SA list, giving users full control over their comparative evaluations.
\end{itemize}


The overall workflow of the \emph{experimentation application} proceeds as follows: 
users begin by configuring one or more experimental tasks in the \emph{Task Settings} panel, where they can customize algorithm and benchmark parameters. 
These tasks are then queued in the \emph{Pending Tasks} panel and executed---either sequentially or in parallel—based on the configured parallelization settings. 
Upon completion, results are automatically transferred to the \emph{Completed Tasks} panel, where users can inspect detailed outputs, generate individual plots, and export results. 
Selected tasks with matching benchmark settings and run numbers can be added to the \emph{Statistical Analysis} panel for further performance evaluation through statistical tests, rankings, and result visualizations.

\begin{figure}[!t]
\centering
\begin{tabular}{cc}
    \subfigure[{\scriptsize Box Plot of $E_o$.}]{\includegraphics[width=0.485\linewidth]{Figures/boxEo.eps}\label{fig:Manual:boxEo}}
&
     \subfigure[{\scriptsize Box Plot of $E_{bbc}$}]{\includegraphics[width=0.485\linewidth]{Figures/boxEbbc.eps}\label{fig:Manual:boxEbbc}}
\end{tabular}
\caption{Box plot comparison of algorithm performance using $E_o$ and $E_{bbc}$ metrics. These visualizations are generated through the Statistical Analysis Panel in GUI Mode and illustrate performance variations across multiple runs for a set of comparison algorithms.}
\label{fig:Manual:boxPlots}
\end{figure}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{Figures/currentError.eps}
\caption{Current Error Plot generated using the Statistical Analysis panel in the GUI Mode of EDOLAB. 
This figure illustrates the convergence behavior of multiple algorithms on a dynamic optimization problem.
The \emph{current error} represents the error of the best-so-far solution within the current environment and is plotted over fitness evaluations, averaged across all runs.
The sharp spikes visible in the plot correspond to moments when environmental changes occur, causing a sudden increase in error values.
Between two spikes, the environment remains stationary, and the plot reveals how rapidly and effectively each algorithm re-converges.
Due to the dense and fluctuating nature of these plots, it is advisable to visualize only a small portion of the environments for clarity.
In this example, we display 10 environments with a change frequency of 5000 fitness evaluations.}
\label{fig:Manual:currentErrorPlot}
\end{figure}

\subsubsection{Education Application}
\label{sec:sec:sec:EducationApp}

The education application allows users to visually observe the current environment, environmental changes, and the behavior of individuals over time. 
Figure~\ref{fig:Manual:EducationModul} shows the interface of EDOLAB's education application. 
On the left side of the interface, users can configure experimental parameters in a manner similar to the experimentation application. 
However, this application only supports two-dimensional problem instances, as its primary purpose is to visualize the search space and the dynamics of optimization.

Once the experiment is configured and the $\mathtt{RUN}$ button is pressed, EDOLAB archives the environmental settings and the positions of individuals over time. 
The time required for a run depends on the selected algorithm, benchmark configuration, and available hardware resources. 
Upon completion, the archived data is rendered in the interface to enable visual exploration.


\begin{figure}[!t]
\centering
\includegraphics[width=0.9\linewidth]{Figures/EducationModule.png}
\caption{The Education Application in GUI Mode. Users can select an algorithm and a benchmark, configure their parameters, and visualize the environment's contour plot, its changes over time, the behavior of individuals, and the current error. This application provides intuitive insights into algorithmic behavior and environmental dynamics. In the GUI Mode, it operates like a video player with control buttons to navigate through time steps. The Education Application is also accessible via Code Mode, though without the video control interface.}
\label{fig:Manual:EducationModul}
\end{figure}

Using this data, the education application generates a video that shows how the environment and individuals evolve over time. 
The interface includes video player-style controls that allow users to navigate through generations by entering a specific value or using a progress bar, and to adjust the playback speed.
As illustrated in Figure~\ref{fig:Manual:EducationModul}, the core visualization is a two-dimensional contour plot of the environment. 
Promising regions are shown with contour levels; the centers of visible promising regions (i.e., those not occluded by larger regions) are marked with blue circles, the global optimum is indicated by a red pentagram, and individuals are displayed as green filled circles. 
Individual positions are updated each iteration, and the landscape visualization is refreshed after every environmental change.
Additionally, a real-time plot of current error and a counter showing the environment number are presented to offer additional insights.

By examining the movement of individuals, the evolving landscape, the environment number, and current error values, users can analyze an algorithm's exploratory and exploitative behavior, as well as its responsiveness to changes. 
This visualization helps in assessing the effectiveness of specific algorithmic components such as mutual exclusion in promising regions~\cite{blackwell2006multiswarm}, sub-population generation strategies~\cite{blackwell2008particle}, diversity mechanisms, and change reaction behaviors.

Unlike the experimentation application, which uses identical random seeds to generate consistent problem instances across different algorithms for fair comparison, the education application assigns a new random seed for each run. 
This means that each execution produces a different sequence of environments, allowing users to observe how the algorithm responds to diverse dynamic scenarios. 


\subsection{Running EDOLAB in Code Mode}
\label{sec:sec:CodeMode}

While EDOLAB offers a comprehensive and user-friendly graphical interface, it also supports a \emph{Code Mode} that allows users to interact with the platform directly through scripting. 
This mode is intended for users who wish to:
\begin{inparaenum}
\item modify or debug the internal implementation of algorithms and benchmark components,
\item experiment with custom logic or structural changes, or
\item operate EDOLAB on systems that do not support the GUI (e.g., MATLAB versions older than R2020b).
\end{inparaenum}
In contrast to the GUI, which supports features such as batch task configuration, parallel execution, automatic statistical analysis, and rich visualizations, the Code Mode provides greater flexibility for inspecting, modifying, and testing individual components of the platform.

To enhance readability, understanding, and ease of navigation within EDOLAB's source code, we have:
\begin{itemize}
\item divided the code into \emph{sections} using the \texttt{\%\%} command, with each section having a descriptive header. 
These sections group related lines of code, such as those implementing components (e.g., exclusion~\cite{blackwell2006multiswarm}), initializing EDOA parameters, or preparing output values;
\item assigned meaningful and descriptive names to all structures, parameters, and functions in EDOLAB;
\item added informative comments throughout the code to assist users in understanding and customizing the platform.
\end{itemize}

To run EDOLAB in Code Mode, users begin by editing the \texttt{CodeMode.m} script in the root directory. 
This script allows users to specify the desired EDOA and benchmark generator by setting the \texttt{AlgorithmName} and \texttt{BenchmarkName} variables (e.g., \texttt{AlgorithmName = `mQSO'}, \texttt{BenchmarkName = `GMPB'}).

Parameter settings for each algorithm and benchmark can be modified through their corresponding configuration interfaces:
\begin{itemize}
\item \texttt{getAlgConfigurableParameters\_EDOA.m} --- contains default and configurable parameters of the selected algorithm;
\item \texttt{getProConfigurableParameters\_Benchmark.m} --- defines the adjustable parameters of the selected benchmark.
\end{itemize}
Users can update the \texttt{value} field of each parameter structure to change its default value before the experiment begins.

EDOLAB's Code Mode supports both the \emph{Experimentation} and \emph{Education} applications. 
To activate the Education Application (e.g., contour visualization of 2D environments), set \texttt{VisualizationOverOptimization = 1}. 
To run experiments using the Experimentation Application, set \texttt{VisualizationOverOptimization = 0}.

In Experimentation Mode, users can enable output generation features by modifying the following flags:
\begin{itemize}
\item \texttt{OutputFigure = 1} --- generates a figure showing the offline and current error over time;
\item \texttt{GeneratingExcelFile = 1} --- exports an Excel file with experiment statistics to the \texttt{/Results} folder.
\end{itemize}

Once configurations are complete, executing \texttt{CodeMode.m} will launch the experiment. 
Progress updates, including current run and environment numbers, will be displayed in the MATLAB Command Window, and summary results will be printed upon completion.

Note that although Code Mode is supported in EDOLAB, the GUI Mode is the recommended interface for most users. 
It provides complete access to all parameters, advanced experimental workflows, parallel execution, statistical testing, and advanced visualizations, all within a streamlined user experience.


\section{Extension}
\label{sec:sec:extension}

EDOLAB is an open-source platform designed with extensibility in mind. 
This section provides guidance on how users can add new benchmark generators, performance indicators, and EDOAs to the system.

\subsection{Adding a Benchmark Generator}

To add a new benchmark, suppose called \texttt{ABC}, users should begin by creating a subfolder named \texttt{ABC} within the \texttt{Benchmark} directory. 
Within this folder, three functions must be implemented: 
\path{getProConfigurableParameters-ABC.m}, \texttt{BenchmarkGenerator\_ABC.m}, and \texttt{fitness\_ABC.m}.

\texttt{getProConfigurableParameters\_ABC.m} defines the set of user-configurable parameters for the benchmark. 
These parameters should be structured using a standardized format that specifies default values, allowable ranges, data types, and descriptions. 
The supported data types are:
\begin{itemize}
    \item \texttt{numeric} --- continuous real numbers,
    \item \texttt{integer} --- discrete integers,
    \item \texttt{option} --- categorical choices from a predefined list.
\end{itemize}
An example definition of a parameter is shown below:

\begin{lstlisting}[backgroundcolor=\color{gray!10}]
ConfigurableParameters.ExampleParameter = struct( ...
    'value', 5, ...
    'type', 'integer', ...
    'range', [1, 100], ...
    'description', 'Example of an integer-type parameter.');
\end{lstlisting}

\texttt{BenchmarkGenerator\_ABC.m} uses the defined parameters to generate all environmental states of the benchmark. It should output a structure named \texttt{Problem}, which includes the environmental dynamics and required control settings. This function should \emph{not} redefine configurable parameters; instead, it should rely entirely on the input from \texttt{getProConfigurableParameters\_ABC.m}.

The final required function, \texttt{fitness\_ABC.m}, implements the benchmark's baseline fitness function. Both \path{Benchmark-Generator_ABC.m} and \texttt{fitness\_ABC.m} must conform to the input/output conventions used by existing benchmarks in EDOLAB.

Once these three functions are added, no further modifications are necessary. The new benchmark will automatically appear in the GUI's benchmark list and will also be accessible via \texttt{CodeMode.m}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\subsection{Adding a Performance Indicator}
\label{sec:sec:extensionIndicator}

In dynamic optimization problems (DOPs), performance indicators are typically computed over time---at the end of each environment~\cite{trojanowski1999searching}, after every function evaluation~\cite{branke2003designing}, or upon deploying solutions within each environment~\cite{yazdani2018thesis}.

In EDOLAB, users can add new performance indicators through a simple and extensible JSON interface. 
Only minimal edits are required: users define the indicator in a JSON file and update the \texttt{fitness.m} script accordingly; all other integration steps are handled automatically by EDOLAB.

To add a new performance indicator, follow these steps:

\begin{itemize}
  \item \textbf{Edit the JSON file} \\
  Open \path{Indicators/indicators.json} and add a new entry for your indicator. 
  The \texttt{type} field must be specified as one of the following: \texttt{``FE based"}, \texttt{``Environment based"}, or \texttt{``None"}.
  Example:
  \begin{lstlisting}[backgroundcolor=\color{gray!10}]
"MyNewIndicator": {
  "type": "FE based"          % or "Environment based" / "None"
}
  \end{lstlisting}
  
  \item \textbf{Implement the indicator in \texttt{fitness.m}} \\
    Update the \texttt{fitness.m} function to compute and store the new indicator at the appropriate location. 
    Note that for \texttt{FE based} and \texttt{Environment based} indicators, you must populate the \texttt{trend} field; for \texttt{None} type indicators, you must populate the \texttt{final} field.

  \begin{itemize}
    \item \texttt{FE based} indicators (updated at every fitness evaluation):
    \begin{lstlisting}[backgroundcolor=\color{gray!10}]
Problem.Indicators.MyNewIndicator.trend(Problem.FE) = <your calculation>;
    \end{lstlisting}
    
    \item \texttt{Environment based} indicators (updated at the end of each environment):
    \begin{lstlisting}[backgroundcolor=\color{gray!10}]
Problem.Indicators.MyNewIndicator.trend(Problem.Environmentcounter) = <your calculation>;
    \end{lstlisting}
    \item \texttt{None} type indicators (updated only at the final fitness evaluation, storing a single final value):
    \begin{lstlisting}[backgroundcolor=\color{gray!10}]
Problem.Indicators.MyNewIndicator.final = <your calculation>;
    \end{lstlisting}
  \end{itemize}
\end{itemize}

After updating the JSON file and modifying \texttt{fitness.m}, EDOLAB will automatically recognize and integrate the new performance indicator into both the statistical analysis panel and the visualization components of the GUI.
The new indicator will also be fully available when running experiments using \texttt{CodeMode.m}.

\subsection{Adding an EDOA}
\label{sec:sec:AddingEDOA}

Adding a new EDOA to EDOLAB requires minimal modifications to ensure compatibility with the platform.  
Follow these steps to add a new EDOA:

\begin{itemize}
    \item Create a sub-folder inside the $\mathtt{Algorithm}$ folder, named after the new EDOA.  
    Add all relevant functions for the EDOA into this sub-folder. 
    The required five files are listed in Section~\ref{sec:Architecture}.
    
    \item Ensure that the new EDOA can be invoked by $\mathtt{CodeMode.m}$.  
    The inputs and outputs of the EDOA's main function must be consistent with those expected by $\mathtt{CodeMode.m}$.

    \item Define the EDOA's configurable parameters in $\mathtt{getAlgConfigurableParameters\_EDOA.m}$ using the standardized format, including fields for \texttt{value}, \texttt{type}, \texttt{range}, and \texttt{description}.  
    These parameters will be available for both GUI-based and code-based configurations.
    
    \item In the main function, use $\mathtt{BenchmarkGenerator.m}$ to generate the problem instance.
    
    \item To enable support for the education application, include the code for collecting visualization data during optimization.  
    This code can be found in the $\mathtt{\%\% Visualization\ for\ education\ module}$ section of the existing EDOAs.

    \item Use $\mathtt{fitness.m}$ for solution evaluation.
    
    \item Inject the user-defined parameters, specified in $\mathtt{getAlgConfigurableParameters\_EDOA.m}$ and configured via the GUI or code mode, into the optimizer before initialization.  
    Within the optimizer, define any additional internal parameters or data structures necessary for runtime statistics, performance indicators, and other outputs.
    
    \item At the end of the EDOA's main function, prepare the output structure following the template used in existing EDOAs to ensure compatibility with EDOLAB's reporting and analysis modules.
    
    \item Name the main function of the new EDOA as $\mathtt{main\_EDOA.m}$ to enable automatic integration with EDOLAB.
\end{itemize}

For example, if the new EDOA is named XYZ, the sub-folder should be named $\mathtt{XYZ}$, and the main function should be named $\mathtt{main\_XYZ.m}$.  
Once completed, the new EDOA will automatically appear in the list of available algorithms in GUI panels.  
Additionally, it can be run programmatically by setting $\mathtt{AlgorithmName\;=\;'XYZ'}$ in $\mathtt{CodeMode.m}$.



\section{Using EDOLAB in Octave}
\label{sec:Octave}

EDOLAB was originally developed in MATLAB, but a standalone version has been created to support execution in Octave, an open-source alternative that offers high compatibility with MATLAB. 
This allows researchers to access EDOLAB’s key functionalities without a MATLAB license.

\subsection{Structure of the Octave Version}

The \texttt{OctaveVersion} folder provides a self-contained implementation of EDOLAB that is specifically adapted for compatibility with Octave. 
It operates exclusively in code mode and does not include a GUI interface. To run EDOLAB in Octave, users should execute the \texttt{OctaveCodeMode.m} script located in this folder.

The folder mirrors the structure of the main MATLAB version and includes:
\begin{itemize}
    \item \texttt{Algorithm} --- Contains sub-folders for each supported EDOA.
    
    \item \texttt{Benchmark} --- Includes Octave-adapted benchmark definitions and generators.
    
    \item \texttt{Indicators} --- Defines available performance indicators.
    
    \item \texttt{Utility} --- Provides general-purpose helper functions and output routines. 
    
    \item \texttt{Results} --- Stores experiment outputs.
\end{itemize}
The Octave version is fully independent from the MATLAB version.

\subsection{Compatibility Notes and Required Adjustments}

Several adjustments were made to ensure compatibility with Octave, considering its differences from MATLAB:

\begin{itemize}
    \item \emph{Required Packages} --- The \texttt{statistics} and \texttt{io} packages must be installed and loaded before running experiments.

    \item \emph{Excel Output} --- 
    \begin{itemize}
        \item Functions relying on \texttt{xlswrite} have been simplified to avoid ActiveX dependencies and work with Octave's I/O system.
    \end{itemize}

    \item \emph{Plotting Limitations} --- 
    \begin{itemize}
        \item Advanced plotting functions (e.g., \texttt{append}, \texttt{parfor}) have been removed or replaced where necessary.
    \end{itemize}

    \item \emph{String Handling} --- 
    \begin{itemize}
        \item Octave does not support double-quote strings (\texttt{""}); cell arrays of character vectors are used instead.
    \end{itemize}

    \item \emph{Free Peaks Benchmark} --- 
    \begin{itemize}
        \item Since Octave cannot use MATLAB's \texttt{.mexw64} files, we have manually compiled the KDTree C++ source using:
        \begin{lstlisting}[backgroundcolor=\color{gray!10}]
mkoctfile -v --mex ConstructKDTree.cpp
        \end{lstlisting}
    \end{itemize}
\end{itemize}



\bibliography{bib}
\bibliographystyle{ACM-Reference-Format}
\end{document}
