## Geometry

• comprehensive collection of trigonometric functions (complementary to Java’s Math class)
• point and line segment
• polygonal chain
• Ramer-Douglas-Peucker algorithm

## Functions

• polynomial
• polynomial evaluation using Horner scheme
• polynomial root finding using analytical formulae up to degree 4
• polynomial root finding using the Jenkins Traub method
• continued fraction
• special functions:
• Beta
• regularized Beta
• inverse of regularized Beta
• cumulative Normal
• inverse of cumulative Normal
• Digamma
• Erf
• inverse of Erf
• Gamma
• lower incomplete Gamma
• regularized Gamma P
• inverse of regularized Gamma P
• regularized Gamma Q
• incomplete upper Gamma
• Gaussian
• logBeta
• logGamma
• Lanczos method

## Calculus

• finite difference
• differentiation using Ridders’ method
• derivaties of functions for:
• Beta
• Beta Regularized
• Erf
• Gamma
• Gaussian
• multivariate differentiation:
• (bordered) Hessian
• Jacobian
• Riemann integration
• Riemann integration using substitution rules:
• Double-Exponential rule
• Exponential rule
• Power law singularity
• Map to the Standard interval
• integration using Romberg’s method
• integration using Newton-Cotes formula
• Simpson’s rule
• Trapezoidal rule
• Midpoint rule
• Legendre polynomials
• Chebyshev polynomials
• Laguerre polynomials
• Hermite polynomials

## BASIC

The BASIC package of NM Dev has the following list of features.

## NM Dev

NM Dev is a math library of numerical algorithms. It allows engineers to develop very high quality solutions for mathematical problems very rapidly. You will take less time to produce more elegant, object-oriented code that is better tuned, has fewer bugs and runs faster. NM Dev is an object-oriented, high performance, extensively tested, and professionally documented library of numerical methods. It is a large collection of numerical algorithms so coded such that they are solidly object-oriented, unified and testable. We have been writing numerical code for more than a decade since year 2010. Learning from our a decade of experience coding SuanShu (then popular math library now deprecated), we write NM Dev from scratch to make it even better in all ways.

NM Dev has for each mathematical concept a class, instead of a procedure like our competitors’ products. More importantly, these classes are designed so that they are very easy-to-use and easy-to-integrate. They can be assembled and connected in many ways to construct more complicated concepts, hence new classes. The built-in and user-defined, old and new, simple and complex classes all conform to the same design standard to ensure that they are compatible. NM Dev is to engineering solution as Lego is to toy model. NM Dev’s core technology is the design standard and this collection of classes. The goal is that the user, who has little programming experience or understanding in mathematics, can quickly put together these classes to create a solution for his complex problem. For him to assemble our classes to construct an application is as easy as a child assembles Lego pieces to construct a toy robot. Lego has simple pieces like bricks and gears and complex ones like mini-figures. NM Dev has simple classes like matrix and vector, complex ones like regression, and very sophisticated ones like PDE solvers. Using NM Dev, the user will find solving PDE not more difficult or too different from solving zero for equation.

# Tutorials

There are a number of ways to use NM Dev.

## Programming

NM Dev can be used as a programming library component in a software project. For details please read NM Dev tutorials.

## SuanShu.net

SuanShu can be used in the .NET environment such as in a C# project or Excel. For details, please read SuanShu.net

## Scripting

SuanShu can be used in a similar manner to Matlab/Octave/R/Scilab for research, data analysis and prototyping. For details please read SuanShu Scripting.

# Maven

• How do I exclude NM Dev’s dependencies in my own Java project?
• NM Dev depends on some third-party modules:
• akka-2.1.4
• joda-time-2.8.2
• kryo-2.22
• heaps-2.0 (from teneighty.org)

By default, Maven includes these transitive dependencies in the classpath. If you do not want them to be included in the classpath of your project, you may exclude them explicitly by adding an “exclusion” in the dependency section:

<dependencies>
<dependency>
<groupId>com.numericalmethod</groupId>
<artifactId>suanshu</artifactId>
<version>\${suanshu.version}</version>
<exclusions>
<exclusion>
<groupId>com.esotericsoftware.kryo</groupId> <!-- exclude kryo -->
<artifactId>kryo</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>

# Licensing

• Is there a way to have *one* license file shared by multiple machines?
• Yes, one license file can contain multiple MAC addresses so you can deploy/copy the same file to multiple machines.
• Is it possible to have a license that runs on cloud machines?

# Coding

• Why did you choose to have indexes for matrices starting from 1 and not zero as for most structures in java (and c, …)? This complicates the adaptation of code to use NM Dev matrix models and prone to a lot of “+-1” errors in the indexes (for instance when simply iterating over an array *and* a matrix at the same time…)
• Only the computer scientists count from 0. Everyone else on the planet earth, including the mathematicians, counts from 1. One reason for the computer scientists to count from 0 is indexing to an array element by adding an offset to a starting address. Back in the old C generation, suppose we do, double[] arr = new double[10]; , arr is also a reference to an address of a double or an array of doubles. The address of the 2nd element in the array is computed by adding 8 bytes to arr, i.e., arr + (2 – 1)* 8. In other words, the 2nd object is 1 unit (8 bytes) offset from the starting address. Therefore, an array index in C, C++, Java, C# is the number of offsets from a starting address. It is not the index of the object. NM Dev philosophy is to match symbolically the math equations as much as possible. Most math equations count from 1. All matrices and vectors count from 1. We think that this matching is important for code readability and verification against publications. When we compare our code to the papers, we need not mentally compute this +/-1. Otherwise, the code is very prone to errors, especially when there is a lot of indexing in a complex equation. To avoid doing the +/-1 in coding to some extend, I suggest that the users skip using [0], and count from 1. For example,
double[] v1 = new double[]{Double.NaN, 1., 2., 3., 4., 5.};
Vector v2 = new DenseVector(1., 2., 3., 4., 5.);
Vector v3 = new DenseVector(3);
for (int i = 1; i < = v1.length; ++i) {
v3.set(i, v1[i] + v2.get(i));
}