lincs (Learn and Infer Non Compensatory Sortings) is a collection of MCDA algorithms, usable as a command-line utility and through a Python (3.8+) API.
lincs supports Linux, macOS and Windows, with the exception that GPU-based algorithms are not available on macOS, because CUDA itself is not available there. On these 3 OSes, lincs only support x86_64 CPUs.
lincs is licensed under the GNU Lesser General Public License v3.0 as indicated by the two files COPYING and COPYING.LESSER.
lincs is available for install from the Python package index. Its documentation and its source code are on GitHub.
Questions? Remarks? Bugs? Want to contribute? Open an issue or a discussion! You should probably take a look at our roadmap first.
@todo(Project management, v1.1) Add a note asking academics to kindly cite our ROADEF 2024 paper.
lincs is developed by the MICS research team at CentraleSupélec.
Its main authors are (alphabetical order):
- Khaled Belahcène (domain expertise)
- Laurent Cabaret (performance optimization)
- Vincent Jacques (engineering)
- Vincent Mousseau (domain expertise)
- Wassila Ouerdane (domain expertise)
You should be able to use lincs without being a specialist of MCDA and/or NCS models. Just follow the "Get started" section below.
lincs is designed to be easy to extend with new algorithms or even replace parts of existing algorithms. See our contributor guide for more details.
Depending on your favorite approach, you can either start with our hands-on "Get started" guide or with our conceptual overview documentation. The former will show you how to use our tools, the latter will explain the concepts behind them: what's MCDA, what are NCS models, etc. If in doubt, start with the conceptual overview. We highly recommend you read the other one just after.
Once you've used lincs a bit, you can follow up with our user guide and reference documentation.
lincs uses semantic versioning.
lincs' public API (that "must be declared" according to SemVer) is constituted exclusively by its reference documentation, at a code level: we consider a change as backward compatible if the client code doesn't need to be modified to keep working, even if that change requires recompiling the client code in some cases.
Future backward compatible changes might change lincs' behavior, especially with regards to pseudo-random behavior.
Note that we plan to make lincs usable as a C++ library. When we do that, we'll add this interface to the public API. In the mean time, if you chose to use lincs that way, you must expect unanticipated changes to this interface.
Default values of optional arguments are not considered part of the public API. They might change in future releases if we find values that perform better for most use-cases.
We advice you write your code in an explicit way where it matters to you, and rely on implicit default values only where you want the potential future improvements.
The same specification applies to files read and produced by lincs. This leads to an issue with regard to backward compatibility: if we allow more flexibility in input files, new versions of lincs will be able to read both the old and the new format, in a backward-compatible way. But if lincs produces a file in the new format, existing client scripts might not be able to read it, making this change backward-incompatible.
To solve this issue, we impose an additional constraint to lincs' public API: lincs will produce files in a new format only when the client uses the new feature that motivated the new format.
That way, we know that the client already needs to modify their scripts, so they can adapt to the new format.
See our contributor guide.