Installation of MathGL 2.3.5 In Debian

Motivation

Despite that MathGL is included in the official Debian repositories, It is not the latest version, and the installed, library includes a lot of wrappers and features I'm unlikely to use.

What is MathGL?

As the official website states, MathGL is,

• a library for making high-quality scientific graphics under Linux and Windows.
• a library for the fast data plotting and data processing of large data arrays.
• a library for working in window and console modes and for easy embedding into other programs.
• a library with large and growing set of graphics.

Here you can see a gallery with MathGL graphics

I've used this library several times from long time ago (like in this project of Hodgking-Huxley action potential) and I think is a very nice library to generate graphics from your final binaries. For example, I've used it when my code is up and running and I want it to generate graphic output directly (png,pdf,...)

Installation

First of all, download the latest source from here, and then proceed to get the required prerequisistes.

Prerequisites

The list of prerequisites depends a lot on what you'd like to do with MathGL. I wanted to be able to work with Qt5 widgets, pdf output,gsl support (GNU Scientifical library),OpenMP, MPI, HDF5, and wxWidget support. I've installed the required libraries as root by,

To see the complete list of supported features you can read the CMakeLists.txt and look for every line containing option(enable-XYZ) so you add -D enable-XYZ when you call cmake.

Building MathGL

Once you've installed the prerequisites, you can build MathGL at the root directory of the source or simply a build directory. I like more the build approach since keeps the source directory clean.

Any errors during the cmake phase can be related to the lack of any prerequisite so keep an eye on the errors, they often say what needs to get installed or fixed.

If everything goes fine, you finally install MathGL as root by,

make install

And that's it.

Resources

• http://mathgl.sourceforge.net
  
  
• http://mathgl.sourceforge.net/doc_en/Installation.html#Installation

Neovim: Next generation vim

Motivation

I was wandering the web looking for some vim plugins that feature golang syntax and autocompletion. I found out about the neovim project and got interested on it, cause I'm a vim user. Here's what I've found.

Neovim?

Official Neovim webpage states,

Neovim is an extension of Vim: feature-parity and backwards compatibility are high priorities. If you are already familiar with Vim, see :help nvim-from-vim to learn about the differences.

After using it for more than a week I gotta say it's worth to use it. The customization is way to easy, as for performance neovim loads faster than my vim (this could be due to the installed plugins or other setups, though). The installation of plugins is pretty easy with the aid of vim-plug which can be installed by a single curl request from the command line.

Installation and use of Plugins

Detailed instructions of installation are located on my repo https://github.com/Daniel-M/nvimConfigFiles where I store my neovim configuration files. The Readme describes all steps to get Neovim up and running in Debian.

References

• https://neovim.io
• https://github.com/neovim/neovim
• https://github.com/junegunn/vim-plug
• https://github.com/Daniel-M/nvimConfigFiles

C++ seems faster than C at summing big arrays!!

Forewords

I'm some sort of self-taught programer, so it is expected that my methods and algorithms aren't state of the art optimized to best design practices and improved performance. I made the code without thinking on but doing the tast and leaving aside the code optimization and all that stuff.

The result here is just what I have found. I think that sitting and optimizing code could turn tables, but, not anyone is capable of efficiently write code (a.k.a. optimizing it for best performance), specially if you are a scientist coding (and not a computer scientist).

Motivation

For several months I've been wondering whether C or C++ is more efficient at doing science related tasks. As far as I know, the most common tasks in science involve linear algebra, and one of the simplest tasks is the sum of vectors. Given that I'm preparing some study materials I've decided to test it out and here is what i've found so far.

C++ seems faster than C at summing big arrays of integers

I made codes that compares the performance between regular C arrays (also C++ valid arrays) and STL arrays (exclusive of C++) by taking two random vectors up to 200000 components as input from a file.

One program run consist of,

• Read a 1000 components of two random vectors from a given file.
• Sum component to component the couple of vectors read. Report the number of components and the milliseconds it took for the whole process to standard output.
• Increase the number of components by 1000, then repeat the read-sum-report procedure stated above.
• Repeat increasing size until the vectors reach 200000 components.

The codes are available here

Results

Well, using my unoptimized algorithm it seems that C++ is indeed a little bit faster than C.
The time-to-completion was measured 300 times on the same machine, the resulting run-times where averaged to compensate the effects of anyother processes running.
A fitting to linear functions seemed suitable for the resulting data. The blue marks on the graph represent C++ run-times whilst purple marks represent those of C.
The fitting was made using gnuplot with the fit function: f(x) for C and g(x) for C++ (details below)

Fitting for C with f(x)

f(x)=A*x+B

The relevant output of the fitting was


After 8 iterations the fit converged.
final sum of squares of residuals : 68.4475
relative change during last iteration : -1.00902e-13

degrees of freedom (FIT_NDF) : 197
rms of residuals (FIT_STDFIT) = sqrt(WSSR/ndf) : 0.589448
variance of residuals (reduced chisquare) = WSSR/ndf : 0.347449

Final set of parameters Asymptotic Standard Error
======================= ==========================
A = 0.000385433 +/- 7.274e-07 (0.1887%)
B = 1.36903 +/- 0.08389 (6.127%)


Fitting for C++ with g(x)


function used for fitting: g(x)
g(x)=C*x+D

After 8 iterations the fit converged. q
final sum of squares of residuals : 48.4348
relative change during last iteration : -1.78975e-14

degrees of freedom (FIT_NDF) : 197
rms of residuals (FIT_STDFIT) = sqrt(WSSR/ndf) : 0.495845
variance of residuals (reduced chisquare) = WSSR/ndf : 0.245862

Final set of parameters Asymptotic Standard Error
======================= ==========================
C = 0.000367315 +/- 6.119e-07 (0.1666%)
D = 1.16317 +/- 0.07056 (6.067%)


Conclusions

At the beginning, the execution times of both languages are undistinguishable but it seems that C++ has better performance than C as the size of the vectors increase. It could be a matter of design, more test with different algorithms should be performed.

The difference between the fitted curves is the linear function
D(x) = f(x) - g(x) = 0.000018118*x-0.20586
Clearly when N=10 000 000 the difference between runtimes would be of just 17.91214 ms so whats the point of using C++ over C if the performance difference would be so small? Well, because of Object Oriented Programming, that's why. Besides, the C++ std::array are expected to be optimized over the regular int array[] of C.