OMAL-GO is Java code that has to do with mathematics, linear algebra and optimisation. OMAL-GO really is 100% pure Java source code. There are no calls to native (C or Fortran) libraries. In fact there are no dependencies at all. Nothing besides a Java SDK is needed to compile or execute the code. Its feature set make it particularily suitable for use within the financial domain. Then again, it’s just maths…
Presumably there are three main reasons why users/developers become interested in OMAL-GO :
- Linear Algebra in Java – OMAL-GO is a “high performance” multi-threaded feature-complete linear algebra package.
- Optimisation (mathematical programming) including LP, QP and MIP solvers.
- Finance related code (certainly usable in other areas as well):
- Extensive set of tools to work with time series – CalendarDateSeries, CoordinationSet & PrimitiveTimeSeries.
- Random numbers and stochastic processes – even multi-dimensional such – and the ability to drive these to do things like Monte Carlo simulations.
- A collection of Modern Portfolio Theory related classes – FinancePortfolio and its subclasses the Markowitz and Black-Litterman model implementations.
- Ability to download data from Yahoo Finance and Google Finance.
- Code for the JVM: There are no calls to native (C or Fortran) libraries.
- No dependencies: NOTHING besides a Java SDK is needed to compile or execute the code.
- “Conventional” Java: Names of attributes and methods are chosen to comply with Java standards rather than legacy mathematics code (Fortran, C, Matlab…) conventions.
- Write code that scales: When choosing algorithms and data structures OMAL-GO often favours designs that perform well on larger more complex cases, even if it’s more than what’s currently required.
- Code is written as it’s needed. OMAL-GO will never contain everything anyone could ever use (in terms of Java and mathematics). Users are very much welcome to contribute additions that target their needs.
- Anything and everything may change in the future (breaking API compatibility). Part of the code is “in production” in commercial systems – but will be changed if improvements require it. Interfaces are less likely to change than implementations. Versions are frequently tagged in CVS.