[joss-reviews#2974] Functionality
chkoar opened this issue · 7 comments
Related: openjournals/joss-reviews#2974
Functionality: Have the functional claims of the software been confirmed?
The authors in the paper state that:
With the moead-framework package, we aim at (1) bringing the modularity of the MOEADr package by using the flexibility of Python in order to allow the user to update the behavior of MOEA/D components in their research works, and (2) to propose new variants without being limited by the software.
The authors should provide detailed code examples of (1) and (2). Unless I am missing something.
Thank you, @chkoar , it sounds reasonable to expect at least a clearer explanation of how that is achieved with MOEA/D. @geoffreyp is this something you can address?
With the framework, you can directly extend the algorithms to change the interaction between each component by rewriting the run() method of the algorithm, or use the modularity of the framework to use your own components by using them as parameters of the algorithm's constructor. It is explained in the following paragraph, I think the pdf is not updated but this paragraph was already updated with @sjvrijn in #30 :
With the moead-framework package, we aim to provide the modularity of the MOEADr package by using the flexibility of Python. Indeed, we want to allow the user to update the behavior of MOEA/D components in their research works without being limited by the software. The package is focused on a modular architecture for easily adding, updating or testing the components of MOEA/D and for customizing how components interact with each other. Indeed, in contrast with other existing implementations, moead-framework does not limit the users with a limited number of components available as parameters (8 components are available in MOEADr). Users can easily restructure the 10 existing components of the moead-framework and include new ones to easily add new features without altering existing components. Components are not only customizable with parameters as with MOEADr, but in fact they can be added with the inheritance mechanism on the main run() method of each algorithm.
With the moead-framework package, we aim at (1) bringing the modularity of the MOEADr package by using the flexibility of Python in order to allow the user to update the behavior of MOEA/D components in their research works, and (2) to propose new variants without being limited by the software.
My point is that these lines are written in the paper but I cannot see code examples that demonstrate the above statement. I would like to see detailed code examples for both cases.
Can you please render the updated documentation?
In each example script please provide a module docstring so the reader will be able to understand the purpose of each example.
The PR #72 is updated.
To render the documentation, I have to merge the PR in Master.
The documentation can be generated locally if you want check changes. The documentation is generated with sphinx 2.4.4 (see the section 'Requirements for developers' of the README).
You can generate the documentation with the following commands :
cd docs/
make html
to propose new variants without being limited by the software
I would remove that sentence or I would replace it with something like this: to propose new variants without being limited by the package itself.