Initial code commit

.gitignore

@@ -0,0 +1,128 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+pip-wheel-metadata/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+.python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/

.vscode/settings.json

@@ -0,0 +1,8 @@
+{
+    "python.linting.enabled": true,
+    "python.linting.flake8Enabled": true,
+    "python.linting.flake8Args": [
+        "--max-line-length=99",
+        "--ignore=E123,E402,E741,F401,W503"
+    ]
+}

README.rst

@@ -0,0 +1,74 @@
+Fortitudo Technologies Open Source
+==================================
+
+This package allows you to freely explore open-source implementations of some
+of our fundamental technologies under the `GNU General Public License, Version 3 
+<https://www.gnu.org/licenses/gpl-3.0.html>`_.
+
+Fortitudo Technologies is a fintech company offering novel software solutions as
+well as quantitative and digitalization consultancy to the investment management
+industry. For more information, please visit our `website <https://fortitudo.tech>`_.
+
+Installation Instructions
+-------------------------
+
+Installation can be done via pip::
+
+   pip install fortitudo.tech
+
+For best performance, we recommend that you install the package into a `conda environment
+<https://conda.io/projects/conda/en/latest/user-guide/concepts/environments.html>`_
+and let conda handle the installation of dependencies before installing the
+package using pip. You can do this by following these steps::
+
+   conda env create -n fortitudo.tech python=3.9 scipy -y
+   conda activate fortitudo.tech
+   conda install -c conda-forge cvxopt=1.2.6 -y
+   pip install fortitudo.tech
+
+Contributing
+------------
+
+You are very welcome to contribute to this package by forking the `github
+repository <https://github.com/fortitudo-tech/fortitudo.tech>`_ and creating
+pull requests. Pull requests should always be sent to the dev branch. We
+especially appreciate contributions in relation to packaging, e.g., making
+the package available on conda-forge or improving pip dependencies.
+
+Using the conda environment specified in the requirements.yml file and located
+in the root directory is the easiest way to start contributing to the code.
+
+The style guide mostly follows `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_,
+but it uses some important modifications that can be found in .vscode/settings.json.
+If you use Visual Studio Code, you can use these settings to make sure that
+your code follows the basic rules of the style guide. The most important
+modifications/additions are:
+
+1) We allow line length to be 99 characters for both code and docstrings,
+2) We allow the use of capital I as a variable,
+3) We use type hints introduced in `PEP 484 <https://www.python.org/dev/peps/pep-0484/>`_.
+
+We generally follow naming conventions with descriptive variable and function
+names, but we often use short variable names for the very mathematical parts of
+the code to replicate the variables used in the references. We believe this makes
+it easier to link the code to the theory.
+
+We encourage you to keep individual contributions small in addition to avoid
+imposing object-oriented design patterns. We are unlikely to accept contributions
+that use inheritance without exceptionally good reasons and encourage you to
+use composition instead.
+
+Code of Conduct
+---------------
+
+We welcome feedback and bug reports, but we have very limited resources for
+support and feature requests.
+
+If you experience bugs with some of the upstream packages, please report these
+directly to the maintainers of these packages.
+
+Disclaimer
+----------
+
+This package is completely separate from our proprietary solutions and therefore
+not representative of the functionality offered therein.

docs/Makefile

@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?=
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = source
+BUILDDIR      = build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# 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)

docs/build/html/.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 7bdeae4cac832376e55733568f05577e
+tags: 645f666f9bcd5a90fca523b33c5a78b7

docs/build/html/_sources/contributing.rst.txt

@@ -0,0 +1,31 @@
+Contributing
+------------
+
+You are very welcome to contribute to this package by forking the `github
+repository <https://github.com/fortitudo-tech/fortitudo.tech>`_ and creating
+pull requests. Pull requests should always be sent to the dev branch. We
+especially appreciate contributions in relation to packaging, e.g., making
+the package available on conda-forge or improving pip dependencies.
+
+Using the conda environment specified in the requirements.yml file and located
+in the root directory is the easiest way to start contributing to the code.
+
+The style guide mostly follows `PEP 8 <https://www.python.org/dev/peps/pep-0008/>`_,
+but it uses some important modifications that can be found in .vscode/settings.json.
+If you use Visual Studio Code, you can use these settings to make sure that
+your code follows the basic rules of the style guide. The most important
+modifications/additions are:
+
+1) We allow line length to be 99 characters for both code and docstrings,
+2) We allow the use of capital I as a variable,
+3) We use type hints introduced in `PEP 484 <https://www.python.org/dev/peps/pep-0484/>`_.
+
+We generally follow naming conventions with descriptive variable and function
+names, but we often use short variable names for the very mathematical parts of
+the code to replicate the variables used in the references. We believe this makes
+it easier to link the code to the theory.
+
+We encourage you to keep individual contributions small in addition to avoid
+imposing object-oriented design patterns. We are unlikely to accept contributions
+that use inheritance without exceptionally good reasons and encourage you to
+use composition instead.

docs/build/html/_sources/documentation.rst.txt

@@ -0,0 +1,22 @@
+Documentation
+-------------
+
+The left sidebar contains links to the documentation of the main modules of
+this package as well as an example of how to combine views/stress-testing with
+CVaR optimization.
+
+The example code uses pandas, which is an optional package that can be installed
+simultaneously with this package::
+
+    pip install fortitudo.tech[pandas]
+
+The data used in the example is the simulation from :cite:t:`SeqEntropyPooling`.
+You can verify that the prior means and volatilities are the same by `downloading
+the article using this link <https://ssrn.com/abstract_id=3936392>`_.
+
+.. toctree::
+    :hidden:
+
+    entropy_pooling
+    optimization
+    examples

docs/build/html/_sources/entropy_pooling.rst.txt

@@ -0,0 +1,16 @@
+Entropy Pooling
+---------------
+
+The Entropy Pooling method solves the problem
+
+.. math:: q=\text{argmin}\left\{ x'\left(\ln x-\ln p\right)\right\},
+
+subject to the constraints
+
+.. math:: Ax=b, \\Gx\leq h.
+
+The method was first introduced by :cite:t:`EntropyPooling`, while the
+code is implemented using notation from :cite:t:`SeqEntropyPooling`.
+
+.. automodule:: fortitudo.tech.entropy_pooling
+   :members: