Author Archives: Abel Soares Siqueira

CUTEst.jl

By: Abel Soares Siqueira

Re-posted from: http://abelsiqueira.github.io/cutest.jl/

About an year ago,
Raniere
started working on a interface for
CUTEst.
He decided to create ugly,
a repository for CUTEst, but following the Unix procedure for
building packages (./configure, make, make install).
Also with ugly, he wanted to enable building a shared library
to be used with Julia.
This approach worked, but maintaining it is troublesome,
since it would require updating and testing of ugly for every
update of CUTEst.

What I decided to do was find a way to create a shared library
from a working CUTEst installation.
This focuses on another principle: passing the blame, er,
I mean, modularity.
My package would simply take a working CUTEst and make a
working shared library from it.
It also served of downloading and installing a new CUTEst
installation, since this would be required for testing.
The work can be found at
cutest-julia-installer.

The second thing Raniere worked was the interface itself,
which is a module/package for Julia that enables
building a problem from its name,
retrieving its parameters,
and using its mathematical functions
(objective function, gradient, Hessian, constraints,
Jacobian, and so on).
I continued this work, changing the way the problem is built
(to use my shared library),
and translating the core functions to Julia.
With these additions, the usual functions on CUTEst can be
called with little change in Julia.

The next step is to facilitate the use of CUTEst functions
by creating higher-level interfaces.
So, instead of manually verifying if problem is
constrained or not, and then calling
cfn(st, n, m, x, f, c) or ufn(st, n, x, f),
to get the objective function value,
one might simply call
f = obj_fun(prob, x).
This should probably be slower,
if the user, for instance, ends up calling two functions
instead of one, but if it increases development time,
then it has server its purpose.

A Study in Julia

By: Abel Soares Siqueira

Re-posted from: http://abelsiqueira.github.io/a-study-in-julia/

Today I begin a study in Julia.
This fantastic tool has syntax similar to that of Octave/Matlab,
but is much faster. Furthermore, the interface with functions
made in C and Fortran is much easier to accomplish, and since
most things in computational mathematics are on these languages,
this feature is wonderful.

My intented work is

  • make a simple julia and C interface, with auto-compiling
    and test on GitHub and Travis CI;
  • develop a nonlinear optimization tool completely in Julia,
    then improve the slow bits by using C and/or Fortran;
  • implement/improve the CUTEst interface
    [1],
    [2],
    possibly creating a SIF converter.
  • if things work out, submit to JuliaOpt.

My work starts with the Julia-C
Samples
.
If you need me, I might be on #julia on IRC/freenode.

The End of Fortran

By: Abel Soares Siqueira

Re-posted from: http://abelsiqueira.github.io/the-end-of-fortran/

One of my main interest is the end of Fortran as the only programming language
used by mathematicias
. If you’re not in the area of mathematical programming,
you probably find it strange for me to be talking about Fortran, so I explain.
Fortran is considered the fastest programming language in mathematics, and most
things made are in this language. Other often used languages such as
MatLab/Octave and Mathematica are high-level, which means they are slower and
are not considered for serious applications.

In reality, Fortran is one of the fastest programming language for linear
algebra with dense matrices
. Since most things in this area are matrices, and
most vectors are dense, this can’t be overlooked. In addition, fortran has a
relatively easy way to go, bypassing the painstankingly formatting and GOTO,
which were left behind by the newer versions.

The problem is that, since learning Fortran is almost imperative in the area,
there is little else used to code in the area. Hence, easy tasks without need of
fast execution become hard programming jobs. And furthermore, tasks that need
fast execution, but can’t (shouldn’t) be implement as matrices, become slow in
Fortran, and sometimes this is overlooked.

My proposition is use the best tool for the job, which is just common sense,
but applied to our area. Try Python. Try
Ruby. Try Julia. Try
to implementing a graph using a list of pointers. Try to implement a argument
parser. Try to implement reading, storing, and calculating the transpose of a
sparse matrix. Try to implement a tool to read all citations on your .tex, read
from a bibtex file such references and print then all in a nice format.

Now, rather than stay in that language, go for another. Try other languages.
When the job comes, you can choose the best tool for it. And you can combine.
Some languages, such as Julia, Fortran and C, are very easy to combine with
others. Implement your algorithm in Julia, then improve it later with Fortran.
And if you are really in need of speed, why not implement the hardest part in
machine language (ASSEMBLY)?
Implementing the fastest possible algorithm is very good for a specific
application, but in our line of work, we must take into account the method, not
only the implementation.