Merge branch 'develop' into DaskProcessArg

.github/workflows/ci.yml

@@ -0,0 +1,36 @@
+name: CI
+
+on:
+  workflow_dispatch:
+  push:
+    branches:
+      - main
+      - develop
+  pull_request:
+    branches:
+      - main
+      - develop
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        py: [ 3.9, 3.8, 3.7 ]
+    steps:
+    - uses: actions/checkout@v2
+    - name: Install Python ${{ matrix.py }}
+      uses: actions/setup-python@v2
+      with:
+        python-version: ${{ matrix.py }}
+    - name: Get full Python version
+      shell: bash
+      run: echo ::set-output name=version::$(python -c "import sys; print('-'.join(str(v) for v in sys.version_info))")
+    - name: Install dependencies
+      shell: bash
+      run: |
+        python -m pip install --upgrade pip
+        python -m pip install -e .[test]
+    - name: Run unittest
+      shell: bash
+      run: python -m unittest discover -q

.github/workflows/release.yml

@@ -0,0 +1,31 @@
+name: release
+
+on:
+  push:
+    tags:
+      - '*.*.*'
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v2
+    - name: Install Python 3.7
+      uses: actions/setup-python@v2
+      with:
+        python-version: 3.7
+    - name: Get full Python version
+      shell: bash
+      run: echo ::set-output name=version::$(python -c "import sys; print('-'.join(str(v) for v in sys.version_info))")
+    - name: Build project for distribution
+      shell: bash
+      run: |
+        python -m pip install -q build
+        python -m build
+    - name: Create Release
+      uses: ncipollo/release-action@v1
+      with:
+        artifacts: "dist/*"
+        token: ${{ secrets.GITHUB_TOKEN }}
+        draft: false
+        prerelease: steps.check-version.outputs.prerelease == 'true'

.gitignore

@@ -112,6 +112,7 @@ dask-worker-space
 # osx
 .DS_Store
 
-# R
-.RData
-.Rhistory
+# Github codespaces
+pythonenv3.8
+
+.vscode

Makefile

@@ -1,26 +1,20 @@
-# Minimal makefile for Sphinx documentation
-#
+install:
+	@python setup.py build install
 
-# You can set these variables from the command line.
-SPHINXOPTS    =
-SPHINXBUILD   = sphinx-build
-SPHINXPROJ    = jMetalPy
-SOURCEDIR     = docs/source
-BUILDDIR      = build
+install-dependencies:
+	@python -m pip install -e .[all]
 
-# Put it first so that "make" without argument is like "make help".
-help:
-	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+clean:
+	@rm -rf build dist .eggs *.egg-info
+	@find . -type d -name '.mypy_cache' -exec rm -rf {} +
+	@find . -type d -name '__pycache__' -exec rm -rf {} +
 
-.PHONY: help Makefile
+black: clean
+	@isort --profile black jmetal/ examples/
+	@black jmetal/ examples/
 
-# "make github" option to build gh-pages
-github:
-	@make html
-	@cp -a $(BUILDDIR)/html/. docs
-	@rm -r $(BUILDDIR)
+lint:
+	@mypy jmetal/ examples/ --show-error-codes
 
-# Catch-all target: route all unknown targets to Sphinx using the new
-# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
-%: Makefile
-	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+tests:
+	@python -m unittest discover -q

README.md

@@ -1,10 +1,10 @@
 ![jMetalPy](docs/source/jmetalpy.png)
 
-[![Build Status](https://img.shields.io/travis/jMetal/jMetalPy/master.svg?style=flat-square)](https://travis-ci.org/jMetal/jMetalPy)
-[![Documentation](https://img.shields.io/badge/docs-online-success?style=flat-square)](https://jmetal.github.io/jMetalPy/index.html)
-[![PyPI License](https://img.shields.io/pypi/l/jMetalPy.svg?style=flat-square)]()
-[![PyPI version](https://img.shields.io/pypi/v/jMetalPy.svg?style=flat-square)]()
-[![PyPI Python version](https://img.shields.io/pypi/pyversions/jMetalPy.svg?style=flat-square)]()
+[![CI](https://github.com/jMetal/jMetalPy/actions/workflows/ci.yml/badge.svg)](https://github.com/jMetal/jMetalPy/actions/workflows/ci.yml)
+[![PyPI Python version](https://img.shields.io/pypi/pyversions/jMetalPy.svg)]()
+[![DOI](https://img.shields.io/badge/DOI-10.1016%2Fj.swevo.2019.100598-blue)](https://doi.org/10.1016/j.swevo.2019.100598)
+[![PyPI License](https://img.shields.io/pypi/l/jMetalPy.svg)]()
+[![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
 
 A paper introducing jMetalPy is available at: https://doi.org/10.1016/j.swevo.2019.100598
 
@@ -43,7 +43,7 @@ pip install "jmetalpy[core]"
 Other supported commands are listed next:
 
 ```console
-pip install "jmetalpy[docs]"  # Install requirements for building docs
+pip install "jmetalpy[dev]"  # Install requirements for development
 pip install "jmetalpy[distributed]"  # Install requirements for parallel/distributed computing
 pip install "jmetalpy[complete]"  # Install all requirements
 ```
@@ -78,10 +78,10 @@ algorithm.run()
 We can then proceed to explore the results:
 
 ```python
-from jmetal.util.solution import get_non_dominated_solutions, print_function_values_to_file, \ 
+from jmetal.util.solution import get_non_dominated_solutions, print_function_values_to_file,
     print_variables_to_file
 
-front = get_non_dominated_solutions(algorithm.get_result())
+front = get_non_dominated_solutions(algorithm.result())
 
 # save to files
 print_function_values_to_file(front, 'FUN.NSGAII.ZDT1')
@@ -100,11 +100,15 @@ plot_front.plot(front, label='NSGAII-ZDT1', filename='NSGAII-ZDT1', format='png'
 <img src=docs/source/_static/NSGAII-ZDT1.png width=450 alt="Pareto front approximation">
 
 ## Features
-The current release of jMetalPy (v1.5.5) contains the following components:
+<<<<<<< HEAD
+The current release of jMetalPy (v1.5.7) contains the following components:
+=======
+The current release of jMetalPy (v1.5.4) contains the following components:
+>>>>>>> 8c0a6cf (Feature/mixed solution (#73))
 
 * Algorithms: local search, genetic algorithm, evolution strategy, simulated annealing, random search, NSGA-II, NSGA-III, SMPSO, OMOPSO, MOEA/D, MOEA/D-DRA, MOEA/D-IEpsilon, GDE3, SPEA2, HYPE, IBEA. Preference articulation-based algorithms (G-NSGA-II, G-GDE3, G-SPEA2, SMPSO/RP); Dynamic versions of NSGA-II, SMPSO, and GDE3.
 * Parallel computing based on Apache Spark and Dask.
-* Benchmark problems: ZDT1-6, DTLZ1-2, FDA, LZ09, LIR-CMOP, unconstrained (Kursawe, Fonseca, Schaffer, Viennet2), constrained (Srinivas, Tanaka).
+* Benchmark problems: ZDT1-6, DTLZ1-2, FDA, LZ09, LIR-CMOP, RWA, unconstrained (Kursawe, Fonseca, Schaffer, Viennet2), constrained (Srinivas, Tanaka).
 * Encodings: real, binary, permutations.
 * Operators: selection (binary tournament, ranking and crowding distance, random, nary random, best solution), crossover (single-point, SBX), mutation (bit-blip, polynomial, uniform, random).
 * Quality indicators: hypervolume, additive epsilon, GD, IGD.
@@ -118,9 +122,14 @@ The current release of jMetalPy (v1.5.5) contains the following components:
 
 ## Changelog
 
+* [v1.6.1] Add RWA benchmark, refactor classes BinarySolution and BinaryProblem.
+* [v1.6.0] Refactor class Problem, the single-objective genetic algorithm can solve constrained problems, performance improvements in NSGA-II, generation of Latex tables summarizing the results of the Wilcoxon rank sum test, added a notebook folder with examples.
+* [v1.5.7] Use of linters for catching errors and formatters to fix style, minor bug fixes.
+* [v1.5.6] Removed warnings when using Python 3.8.
 * [v1.5.5] Minor bug fixes.
 * [v1.5.4] Refactored quality indicators to accept numpy array as input parameter.
 * [v1.5.4] Added [CompositeSolution](https://github.com/jMetal/jMetalPy/blob/master/jmetal/core/solution.py#L111) class to support mixed combinatorial problems. [#69](https://github.com/jMetal/jMetalPy/issues/69)
 
 ## License
+
 This project is licensed under the terms of the MIT - see the [LICENSE](LICENSE) file for details.

docs/_sources/contributing.rst.txt

@@ -11,10 +11,10 @@ We have a set of branches on the remote Git server.
 Some branches are temporary, and others are constant throughout the life of the repository.
 
 * Branches always present in the repository:
-    * *master*: You have the latest released to production, receive merges from the develop branch, or merge from a *hotfix* branch (emergency).
-        * Do I have to put a TAG when doing a merge from develop to master? yes
-        * Do I have to put a TAG when doing a merge from a hotfix branch to master? yes
-        * After merge from a hotfix to master, do I have to merge from master to develop? yes
+    * *main*: You have the latest released to production, receive merges from the develop branch, or merge from a *hotfix* branch (emergency).
+        * Do I have to put a TAG when doing a merge from develop to main? yes
+        * Do I have to put a TAG when doing a merge from a hotfix branch to main? yes
+        * After merge from a hotfix to main, do I have to merge from main to develop? yes
     * *develop*: It is considered the "Next Release", receives merges from branches of each developer, either corrections (*fix*) or new features (*feature*).
 
 * Temporary branches:
@@ -27,8 +27,8 @@ Some branches are temporary, and others are constant throughout the life of the
         * When I finish the correction in my fix branch, which branch to merge into?: You always merge feature branch into develop branch
 
     * *hotfix/\<task\-id\>\-\<description\>*: When we are correcting an emergency incidence in production, we create a local branch with the prefix "hotfix/", then only if there is a task id, we indicate it and we add a hyphen. The following we indicate a description according to the functionality that we are correcting. The words are separated by hyphens.
-        * Where does this branch emerge?: This branch always emerge from the master branch
-        * When I finish the correction in my hotfix branch, which branch to merge into?: This branch always emerge from the master and develop branch
+        * Where does this branch emerge?: This branch always emerge from the main branch
+        * When I finish the correction in my hotfix branch, which branch to merge into?: This branch always emerge from the main and develop branch
 
 * Steps to follow when you are creating or going to work on a branch of any kind (feature / fix / hotfix):
     1. After you create your branch (feature / fix / hotfix) locally, upload it to the remote Git server. The integration system will verify your code from the outset.
@@ -200,4 +200,4 @@ And the produced output doc will be:
 
 .. image:: contributing/method_way_sphinx.png
 
-As you may notice, if you don't use any docstring, the method documentation will be empty.
+As you may notice, if you don't use any docstring, the method documentation will be empty.

docs/contributing.rst

@@ -11,10 +11,10 @@ We have a set of branches on the remote Git server.
 Some branches are temporary, and others are constant throughout the life of the repository.
 
 * Branches always present in the repository:
-    * *master*: You have the latest released to production, receive merges from the develop branch, or merge from a *hotfix* branch (emergency).
-        * Do I have to put a TAG when doing a merge from develop to master? yes
-        * Do I have to put a TAG when doing a merge from a hotfix branch to master? yes
-        * After merge from a hotfix to master, do I have to merge from master to develop? yes
+    * *main*: You have the latest released to production, receive merges from the develop branch, or merge from a *hotfix* branch (emergency).
+        * Do I have to put a TAG when doing a merge from develop to main? yes
+        * Do I have to put a TAG when doing a merge from a hotfix branch to main? yes
+        * After merge from a hotfix to main, do I have to merge from main to develop? yes
     * *develop*: It is considered the "Next Release", receives merges from branches of each developer, either corrections (*fix*) or new features (*feature*).
 
 * Temporary branches:
@@ -27,8 +27,8 @@ Some branches are temporary, and others are constant throughout the life of the
         * When I finish the correction in my fix branch, which branch to merge into?: You always merge feature branch into develop branch
 
     * *hotfix/\<task\-id\>\-\<description\>*: When we are correcting an emergency incidence in production, we create a local branch with the prefix "hotfix/", then only if there is a task id, we indicate it and we add a hyphen. The following we indicate a description according to the functionality that we are correcting. The words are separated by hyphens.
-        * Where does this branch emerge?: This branch always emerge from the master branch
-        * When I finish the correction in my hotfix branch, which branch to merge into?: This branch always emerge from the master and develop branch
+        * Where does this branch emerge?: This branch always emerge from the main branch
+        * When I finish the correction in my hotfix branch, which branch to merge into?: This branch always emerge from the main and develop branch
 
 * Steps to follow when you are creating or going to work on a branch of any kind (feature / fix / hotfix):
     1. After you create your branch (feature / fix / hotfix) locally, upload it to the remote Git server. The integration system will verify your code from the outset.
@@ -200,4 +200,4 @@ And the produced output doc will be:
 
 .. image:: contributing/method_way_sphinx.png
 
-As you may notice, if you don't use any docstring, the method documentation will be empty.
+As you may notice, if you don't use any docstring, the method documentation will be empty.

docs/source/conf.py

@@ -2,6 +2,7 @@
 
 import os
 import sys
+
 sys.path.insert(0, os.path.abspath('../../'))
 
 # -- Project information -----------------------------------------------------