aportelli / latanalyze Goto Github PK

In case you haven't already found it, the docs on caching in Travis CI are here: https://docs.travis-ci.com/user/caching/

The math interpreter is obviously very powerful. Performance is currently (and understandably) worse than native machine code. So my question: how hard would it be to add JIT compilation to speed up the interpreted code? I mean I don't expect this to be a trivial task, but are we talking weeks, months or years of time? I wouldn't expect a wide variety of instruction sets to be supported, but x86 and perhaps x86_64 might be a nice feature.

General advice I've read suggests that macros should be avoided where possible in C++ as it makes debugging harder. With that in mind, could we offer an alternative to FOR_STAT_ARRAY in LatAnalyze3?

One idea I had would be to simply offer a member function in the Sample class that accepts a lambda function that accepts an index, say, then runs that function under a for loop, as is currently coded in FOR_STAT_ARRAY.

Can this be done? By "prettier" I mean for example filled stacked histograms like in this paper: http://arxiv.org/pdf/1602.01767.pdf. I'm not so familiar with Gnuplot, so I don't know it's limitations.

After a reading around for a bit it looks like this serial/parallel problem for HDF5 may need to be addressed. Basically HDF5 appears to support both single node (serial) and parallel (mpi) implementations, and Linux distros based on Debian (like mine) all have both packages available. To avoid naming conflicts, the file libhdf5.so does not exist by default, and the libraries and headers are either in subdirectories or have a suffix indicating which package they belong to. Hence libhdf5_serial.so is identical to libhdf5.so, which is why libhdf5.so doesn't exist by default.

It may be worthwhile adding some condition into configure.ac that tries to find HDF5 with the explicit serial labelling if it can't find it with the generic file names/paths.

To recreate, simply create and save two plots one after the other, resetting the plot environment in between with the PlotEnv::reset member function. Even if the save paths are different, the temporary text files (with the .dat extension) produced from the first plot are then saved again in the second plot save path, potentially wasting disk space.

This obviously isn't a showstopping bug, but I thought it was worth mentioning.

I may be mistaken, but I think the formula for computing the variance in StatArray may be wrong. At StatArray.hpp:183, the sum of squared deviations from the mean is divided by N - 1, where N is the number of samples. Compare this to the formula given in Gattringer and Lang (page 97, equation 4.71), where the divisor is N. Is this an actual error, or are you trying to account for bias in some way?