Coder Social home page Coder Social logo

mlpack / mlpack Goto Github PK

View Code? Open in Web Editor NEW
4.8K 182.0 1.6K 263.05 MB

mlpack: a fast, header-only C++ machine learning library

Home Page: https://www.mlpack.org/

License: Other

C++ 96.30% CMake 1.76% Shell 0.33% Python 0.97% JavaScript 0.03% CSS 0.02% Julia 0.13% Go 0.35% R 0.11% C 0.01%
machine-learning-library c-plus-plus deep-learning nearest-neighbor-search regression machine-learning hacktoberfest scientific-computing

mlpack's Introduction

mlpack: a fast, header-only machine learning library
a fast, header-only machine learning library

Azure DevOps builds (job) License NumFOCUS

Download: current stable version (4.3.0)

mlpack is an intuitive, fast, and flexible header-only C++ machine learning library with bindings to other languages. It is meant to be a machine learning analog to LAPACK, and aims to implement a wide array of machine learning methods and functions as a "swiss army knife" for machine learning researchers.

mlpack's lightweight C++ implementation makes it ideal for deployment, and it can also be used for interactive prototyping via C++ notebooks (these can be seen in action on mlpack's homepage).

In addition to its powerful C++ interface, mlpack also provides command-line programs, Python bindings, Julia bindings, Go bindings and R bindings.

Quick links:

mlpack uses an open governance model and is fiscally sponsored by NumFOCUS. Consider making a tax-deductible donation to help the project pay for developer time, professional services, travel, workshops, and a variety of other needs.


0. Contents

  1. Citation details
  2. Dependencies
  3. Installing and using mlpack in C++
  4. Building mlpack bindings to other languages
    1. Command-line programs
    2. Python bindings
    3. R bindings
    4. Julia bindings
    5. Go bindings
  5. Building mlpack's test suite
  6. Further resources

1. Citation details

If you use mlpack in your research or software, please cite mlpack using the citation below (given in BibTeX format):

@article{mlpack2023,
    title     = {mlpack 4: a fast, header-only C++ machine learning library},
    author    = {Ryan R. Curtin and Marcus Edel and Omar Shrit and 
                 Shubham Agrawal and Suryoday Basak and James J. Balamuta and 
                 Ryan Birmingham and Kartik Dutt and Dirk Eddelbuettel and 
                 Rishabh Garg and Shikhar Jaiswal and Aakash Kaushik and 
                 Sangyeon Kim and Anjishnu Mukherjee and Nanubala Gnana Sai and 
                 Nippun Sharma and Yashwant Singh Parihar and Roshan Swain and 
                 Conrad Sanderson},
    journal   = {Journal of Open Source Software},
    volume    = {8},
    number    = {82},
    pages     = {5026},
    year      = {2023},
    doi       = {10.21105/joss.05026},
    url       = {https://doi.org/10.21105/joss.05026}
}

Citations are beneficial for the growth and improvement of mlpack.

2. Dependencies

mlpack requires the following additional dependencies:

If the STB library headers are available, image loading support will be available.

If you are compiling Armadillo by hand, ensure that LAPACK and BLAS are enabled.

3. Installing and using mlpack in C++

See also the C++ quickstart.

Since mlpack is a header-only library, installing just the headers for use in a C++ application is trivial.

From the root of the sources, configure and install in the standard CMake way:

mkdir build && cd build/
cmake ..
sudo make install

If the cmake .. command fails due to unavailable dependencies, consider either using the -DDOWNLOAD_DEPENDENCIES=ON option as detailed in the following subsection, or ensure that mlpack's dependencies are installed, e.g. using the system package manager. For example, on Debian and Ubuntu, all relevant dependencies can be installed with sudo apt-get install libarmadillo-dev libensmallen-dev libcereal-dev libstb-dev g++ cmake.

Alternatively, since CMake v3.14.0 the cmake command can create the build folder itself, and so the above commands can be rewritten as follows:

cmake -S . -B build
sudo cmake --build build --target install

During configuration, CMake adjusts the file mlpack/config.hpp using the details of the local system. This file can be modified by hand as necessary before or after installation.

3.1. Additional build options

You can add a few arguments to the cmake command to control the behavior of the configuration and build process. Simply add these to the cmake command. Some options are given below:

  • -DDOWNLOAD_DEPENDENCIES=ON will automatically download mlpack's dependencies (ensmallen, Armadillo, and cereal). Installing Armadillo this way is not recommended and it is better to use your system package manager when possible (see below).
  • -DCMAKE_INSTALL_PREFIX=/install/root/ will set the root of the install directory to /install/root when make install is run.
  • -DDEBUG=ON will enable debugging symbols in any compiled bindings or tests.

There are also options to enable building bindings to each language that mlpack supports; those are detailed in the following sections.

Once headers are installed with make install, using mlpack in an application consists only of including it. So, your program should include mlpack:

#include <mlpack.hpp>

and when you link, be sure to link against Armadillo. If your example program is my_program.cpp, your compiler is GCC, and you would like to compile with OpenMP support (recommended) and optimizations, compile like this:

g++ -O3 -std=c++14 -o my_program my_program.cpp -larmadillo -fopenmp

Note that if you want to serialize (save or load) neural networks, you should add #define MLPACK_ENABLE_ANN_SERIALIZATION before including <mlpack.hpp>. If you don't define MLPACK_ENABLE_ANN_SERIALIZATION and your code serializes a neural network, a compilation error will occur.

See the C++ quickstart and the examples repository for some examples of mlpack applications in C++, with corresponding Makefiles.

3.1.a. Linking with autodownloaded Armadillo

When the autodownloader is used to download Armadillo (-DDOWNLOAD_DEPENDENCIES=ON), the Armadillo runtime library is not built and Armadillo must be used in header-only mode. The autodownloader also does not download dependencies of Armadillo such as OpenBLAS. For this reason, it is recommended to instead install Armadillo using your system package manager, which will also install the dependencies of Armadillo. For example, on Ubuntu and Debian systems, Armadillo can be installed with

sudo apt-get install libarmadillo-dev

and other package managers such as dnf and brew and pacman also have Armadillo packages available.

If the autodownloader is used to provide Armadillo, mlpack programs cannot be linked with -larmadillo. Instead, you must link directly with the dependencies of Armadillo. For example, on a system that has OpenBLAS available, compilation can be done like this:

g++ -O3 -std=c++14 -o my_program my_program.cpp -lopenblas -fopenmp

See the Armadillo documentation for more information on linking Armadillo programs.

3.2. Reducing compile time

mlpack is a template-heavy library, and if care is not used, compilation time of a project can be increased greatly. Fortunately, there are a number of ways to reduce compilation time:

  • Include individual headers, like <mlpack/methods/decision_tree.hpp>, if you are only using one component, instead of <mlpack.hpp>. This reduces the amount of work the compiler has to do.

  • Only use the MLPACK_ENABLE_ANN_SERIALIZATION definition if you are serializing neural networks in your code. When this define is enabled, compilation time will increase significantly, as the compiler must generate code for every possible type of layer. (The large amount of extra compilation overhead is why this is not enabled by default.)

  • If you are using mlpack in multiple .cpp files, consider using extern templates so that the compiler only instantiates each template once; add an explicit template instantiation for each mlpack template type you want to use in a .cpp file, and then use extern definitions elsewhere to let the compiler know it exists in a different file.

Other strategies exist too, such as precompiled headers, compiler options, ccache, and others.

4. Building mlpack bindings to other languages

mlpack is not just a header-only library: it also comes with bindings to a number of other languages, this allows flexible use of mlpack's efficient implementations from languages that aren't C++.

In general, you should not need to build these by hand---they should be provided by either your system package manager or your language's package manager.

Building the bindings for a particular language is done by calling cmake with different options; each example below shows how to configure an individual set of bindings, but it is of course possible to combine the options and build bindings for many languages at once.

4.i. Command-line programs

See also the command-line quickstart.

The command-line programs have no extra dependencies. The set of programs that will be compiled is detailed and documented on the command-line program documentation page.

From the root of the mlpack sources, run the following commands to build and install the command-line bindings:

mkdir build && cd build/
cmake -DBUILD_CLI_PROGRAMS=ON ../
make
sudo make install

You can use make -j<N>, where N is the number of cores on your machine, to build in parallel; e.g., make -j4 will use 4 cores to build.

4.ii. Python bindings

See also the Python quickstart.

mlpack's Python bindings are available on PyPI and conda-forge, and can be installed with either pip install mlpack or conda install -c conda-forge mlpack. These sources are recommended, as building the Python bindings by hand can be complex.

With that in mind, if you would still like to manually build the mlpack Python bindings, first make sure that the following Python packages are installed:

  • setuptools
  • wheel
  • cython >= 0.24
  • numpy
  • pandas >= 0.15.0

Now, from the root of the mlpack sources, run the following commands to build and install the Python bindings:

mkdir build && cd build/
cmake -DBUILD_PYTHON_BINDINGS=ON ../
make
sudo make install

You can use make -j<N>, where N is the number of cores on your machine, to build in parallel; e.g., make -j4 will use 4 cores to build. You can also specify a custom Python interpreter with the CMake option -DPYTHON_EXECUTABLE=/path/to/python.

4.iii. R bindings

See also the R quickstart.

mlpack's R bindings are available as the R package mlpack on CRAN. You can install the package by running install.packages('mlpack'), and this is the recommended way of getting mlpack in R.

If you still wish to build the R bindings by hand, first make sure the following dependencies are installed:

  • R >= 4.0
  • Rcpp >= 0.12.12
  • RcppArmadillo >= 0.9.800.0
  • RcppEnsmallen >= 0.2.10.0
  • roxygen2
  • testthat
  • pkgbuild

These can be installed with install.packages() inside of your R environment. Once the dependencies are available, you can configure mlpack and build the R bindings by running the following commands from the root of the mlpack sources:

mkdir build && cd build/
cmake -DBUILD_R_BINDINGS=ON ../
make
sudo make install

You may need to specify the location of the R program in the cmake command with the option -DR_EXECUTABLE=/path/to/R.

Once the build is complete, a tarball can be found under the build directory in src/mlpack/bindings/R/, and then that can be installed into your R environment with a command like install.packages(mlpack_3.4.3.tar.gz, repos=NULL, type='source').

4.iv. Julia bindings

See also the Julia quickstart.

mlpack's Julia bindings are available by installing the mlpack.jl package using Pkg.add("mlpack.jl"). The process of building, packaging, and distributing mlpack's Julia bindings is very nontrivial, so it is recommended to simply use the version available in Pkg, but if you want to build the bindings by hand anyway, you can configure and build them by running the following commands from the root of the mlpack sources:

mkdir build && cd build/
cmake -DBUILD_JULIA_BINDINGS=ON ../
make

If CMake cannot find your Julia installation, you can add -DJULIA_EXECUTABLE=/path/to/julia to the CMake configuration step.

Note that the make install step is not done above, since the Julia binding build system was not meant to be installed directly. Instead, to use handbuilt bindings (for instance, to test them), one option is to start Julia with JULIA_PROJECT set as an environment variable:

cd build/src/mlpack/bindings/julia/mlpack/
JULIA_PROJECT=$PWD julia

and then using mlpack should work.

4.v. Go bindings

See also the Go quickstart.

To build mlpack's Go bindings, ensure that Go >= 1.11.0 is installed, and that the Gonum package is available. You can use go get to install mlpack for Go:

go get -u -d mlpack.org/v1/mlpack
cd ${GOPATH}/src/mlpack.org/v1/mlpack
make install

The process of building the Go bindings by hand is a little tedious, so following the steps above is recommended. However, if you wish to build the Go bindings by hand anyway, you can do this by running the following commands from the root of the mlpack sources:

mkdir build && cd build/
cmake -DBUILD_GO_BINDINGS=ON ../
make
sudo make install

5. Building mlpack's test suite

mlpack contains an extensive test suite that exercises every part of the codebase. It is easy to build and run the tests with CMake and CTest, as below:

mkdir build && cd build/
cmake -DBUILD_TESTS=ON ../
make
ctest .

If you want to test the bindings, too, you will have to adapt the CMake configuration command to turn on the language bindings that you want to test---see the previous sections for details.

6. Further Resources

More documentation is available for both users and developers.

User documentation:

Tutorials:

Developer documentation:

To learn about the development goals of mlpack in the short- and medium-term future, see the vision document.

If you have problems, find a bug, or need help, you can try visiting the mlpack help page, or mlpack on Github. Alternately, mlpack help can be found on Matrix at #mlpack; see also the community page.

mlpack's People

Contributors

abhinav-anand-addepar avatar akropp avatar bill-march avatar birm avatar drselee avatar gboyer avatar gmravi2003 avatar heisenbuug avatar jeffin143 avatar kartikdutt18 avatar kimsangyeon-dgu avatar lozhnikov avatar manish7294 avatar marcospividori avatar micyril avatar mrityunjay-tripathi avatar nippunsharma avatar nishantkr18 avatar rcurtin avatar rishabhgarg108 avatar rithram avatar robertohueso avatar shrit avatar shubham1206agra avatar stereomatchingkiss avatar tekhnofiend avatar vasiloglou avatar wenhaoh2 avatar yashwants19 avatar zoq avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mlpack's Issues

Add svn:ignore properties to any build artifacts

Reported by rcurtin on 2 Mar 40080066 08:26 UTC
(see ticket summary)

A tedious task, but someone should do it eventually.

Preferably just in fastlib/, but if it gets done for the other trees too, that would also be cool.

sparse matrix support for SDP-LR [continued]

This is a continuation of http://trac.research.cc.gatech.edu/fastlab/ticket/378

Upon studying the code, here are a few options.

a) We give LRSDPFunction the following members

arma::mat dense_c;
arma::sp_mat sparse_c;

std::vector<arma::mat> dense_ais;
std::vector<arma::sp_mat> sparse_ais;

std::vector<arma::mat> ai_modes;

Where the SDP in question is min Dot( dense_c + sparse_c, X ) subj to all the dense, sparse, and mode constraints

b) We just assume the user always wants sparse matrices.

arma::sp_mat c;
std::vector<arma::sp_mat> ais;
std::vector<arma::mat> ai_modes;

here, we keep the modes around as non-sparse

c) we make the sparsity a template parameter

template <typename ObjMatrix, typename ConstraintMatrix>
class LRSDPFunction {
// ...

ObjMatrix c;
std::vector<ConstraintMatrix> ais;
std::vector<arma::mat> ai_modes;

};

Any preference? b), c) are both easier to use than a), but a) is more general in allowing you to have both sparse and dense constraints in the same problem instance

Finish Trac setup

Reported by rcurtin on 23 Jun 40066507 16:53 UTC

  1. Put out a hit on the bastard that came into my room and interrupted my thought process. '''(done)'''
  2. Ensure CSS has no readability problems. '''(done)'''
  3. Set up milestones and roadmap. '''(done)'''
  4. Set up a few components and versions. '''(done)'''
  5. Announce existence of FASTLAB Trac '''(done)'''

LI preprocessor macro conflict with Trilinos

Reported by rcurtin on 19 Feb 40287389 01:46 UTC
I found this particularly useful snippet in sparse_matrix.h:

// you need this because trillinos redifines it. It's ok
// if you don't have it, but you will get an annoying warning
#ifdef F77_FUNC
#undef F77_FUNC
#endif
// trilinos uses this identifier, which is not so surprising.
// this is why you should think twice about macros.
#ifdef LI
#undef LI
#endif

Aside from actually almost shouting a vulgarity (and I wonder why people look at me funny), we need to do any of the following:

  • find a new name for LI (easiest)
  • move away from printf(); potentially to cout (C++ standard)

This applies for the L32 and L64 macros too, which are used to add an 'l' or an 'll' to a printf format string (i.e. %llu or %"L64"u); these are defined in fastlib/base/basic_types.h.

cout may be the best way to go with this, because I think it will automatically print with the correct precision and length, but I need to check into that. Overhauling all printfs with a cout though will be particularly time-consuming and difficult, but worth it to fix this macro mess.

For my particular problem (in mlpack/kernel_pca) I have just made a cheap hack for now.

Reorganize namespaces

Reported by rcurtin on 31 Jul 40110399 06:40 UTC
The current use of namespaces is a little shaky and doesn't make all that much sense to people new to the code. Let's aim for something more like...

fastlib {
  fastlib::col
  fastlib::data (or fastlib::file?  merge these two)
  fastlib::fx
  fastlib::linalg
  fastlib::math
  fastlib::mlpack
  fastlib::par
  fastlib::thor
  fastlib::tree
}

I may have missed some components there but the general idea is that the namespace names should be descriptive enough to explain what that component is while not being a nuisance to type, and we should try to restrict the number of namespaces we use (hence the merge of ::file and ::data, since they seem to be related).

Everything should fall under the '''fastlib''' namespace.

base/otrav.h house of horrors

Reported by rcurtin on 17 Dec 40289662 18:13 UTC
I looked in otrav.h to discover possibly the scariest thing I've seen in years. I think I may mail a letter to Sonny Perdue to get this kind of stuff legally outlawed.

Currently the object traversal system is written entirely in #define macros. I was trying to figure out why and this wonderful list of svn commits was presented to me:
http://trac.research.cc.gatech.edu/fastlab/log/fastlib/base/otrav.h?rev=912
(14 of Garry's 22 commit messages read "hi")

The system clearly fills a niche, allowing an easy way to do object traversal of your classes. But there has to be a better way. Doing it with #define macros is a crime against humanity.

This will require a lot of thought. Maybe a job for the Curiously Recurring Template Pattern (http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)?

base/otrav.h house of horrors

Reported by rcurtin on 17 Dec 40289662 18:13 UTC
I looked in otrav.h to discover possibly the scariest thing I've seen in years. I think I may mail a letter to Sonny Perdue to get this kind of stuff legally outlawed.

Currently the object traversal system is written entirely in #define macros. I was trying to figure out why and this wonderful list of svn commits was presented to me:
http://trac.research.cc.gatech.edu/fastlab/log/fastlib/base/otrav.h?rev=912
(14 of Garry's 22 commit messages read "hi")

The system clearly fills a niche, allowing an easy way to do object traversal of your classes. But there has to be a better way. Doing it with #define macros is a crime against humanity.

This will require a lot of thought. Maybe a job for the Curiously Recurring Template Pattern (http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)?

Make GenMatrix's PrintDebug work with templates

Reported by march on 10 Oct 40155575 11:33 UTC
PrintDebug() for a GenMatrix only prints floating points correctly. It would be nice if it could handle other basic types (e.g. ints and bools).

Some old contrib/ code uses incorrect fx function signatures

Reported by rcurtin on 18 Jan 40286349 19:33 UTC
Each has a different particular error during compilation, but I suspect that the fx API was updated and these bits of code never were. These should be very simple fixes. Here is the list I've come up with:

contrib/nvasil/all_centroid_knn/
contrib/nvasil/non_convex_mvu/
contrib/pram/lle/
contrib/pram/opt/
contrib/pram/sparsepca/

Huh, I thought my list was longer than that.

Remove dead branches and cruft from svn

Reported by rcurtin on 12 Jan 40066690 22:40 UTC
I notice 'fastlib', 'fastlib2', 'fastlib3', 'fastlib-cmake' in the svn tree but only 'fastlib2' has been touched recently. 'fastlib-cmake' was never reintegrated into the project. The status of that needs to be fixed.

We should also move to the standard 'trunk/ branches/ tags/' format of svn repositories, because that is standard. If anything the dead fastlib branches should be moved into branches/ with a more accurate description of why they were branched (if there was an actual reason, if there is not, it should be removed entirely). 'fastlib-cmake' should be moved into 'branches/', but it has its own svn tree beneath it (???) which should be removed. Alternately, a 'trunk/ branches/ tags/' tree could be created beneath the 'fastlib/' directory, which is what has been done for 'mathProg' (which by the way is being correctly used, as far as svn standards go).

There is also a good amount of cruft beneath the papers/ directory -- for example, compilation artifacts that are not necessary, such as any .aux files. I don't know if removing that is even worth the effort.

Inside of the 'fastlib/' directory, the 'bin/', 'bin_keep/', 'lib/', and 'include/' directories are unnecessary. They should be generated and populated at build-time, not stored in the svn repository. On top of that those directories (and any other build artifacts) should be added to the svn:ignore property, so 'svn status' doesn't display all that after building.

mlpack/series_expansion segfaults with no arguments

Reported by rcurtin on 5 Jan 40286439 14:40 UTC
It should give a help/usage dialog instead, and it should also give the help dialog when passed the '-h' option.

I am willing to bet that several other executables are like this also.

Remove fl-build system (all the build.py files)

Reported by rcurtin on 27 Feb 40289063 16:26 UTC
Like the email I sent to the lab said, I will be removing the fl-build system on May 10. This ticket serves as a reminder to me as well as a place to document any caveats I need to remember.

Remove fl-build system (all the build.py files)

Reported by rcurtin on 27 Feb 40289063 16:26 UTC
Like the email I sent to the lab said, I will be removing the fl-build system on May 10. This ticket serves as a reminder to me as well as a place to document any caveats I need to remember.

Thor Compilation error Mk. II

Reported by march on 13 Sep 40311537 02:13 UTC
Now, I'm getting errors about posix_fadvise not being defined. This is still on my Mac.

Error message:

lawn-128-61-122-116:build march$ make
[ 1%] Building CXX object fastlib/CMakeFiles/fastlib.dir/thor/blockdev.cc.o
/Users/march/Desktop/fastlib/trunk/fastlib/thor/blockdev.cc: In member function void RandomAccessFile::Init(const char_, BlockDevice::mode_t):
/Users/march/Desktop/fastlib/trunk/fastlib/thor/blockdev.cc:63: error: POSIX_FADV_RANDOM was not declared in this scope
/Users/march/Desktop/fastlib/trunk/fastlib/thor/blockdev.cc:63: error: posix_fadvise was not declared in this scope
make[* fastlib/CMakeFiles/fastlib.dir/thor/blockdev.cc.o Error 1
make[
* fastlib/CMakeFiles/fastlib.dir/all Error 2
make: *_* [all] Error 2

Set up testing and benchmarking framework

Reported by rcurtin on 27 Jul 40301847 09:46 UTC
This is a master ticket for a very big, time-consuming task.

The end goal of this is to have a set of tests that are run by the automatic build server once the current svn build is run. These tests will be unit tests as well as tests of the MLPACK methods. Timing information should be collected so that speed improvements (or the lack of them) can be seen.

However it should also be trivial for a user to run these tests. That is, if they type make test, the tests should all be run. This will require including the necessary datasets in the build, and making sure that the information for each test to be run is there.

As it currently stands, a lot of the MLPACK methods build a test executable which is supposed to be run with some set of parameters, but a lot of them don't include the right datasets in the right places or document how to use them. Anyways the intricacies of these tests need to be documented, and CMake targets to actually run the tests should be included (this should not be hard although it may be difficult to make that cross-platform and it may be that that is not feasible in the end).

Boost has a unit testing framework which warrants some investigation here (or so I hear).

Migrated-From: http://trac.research.cc.gatech.edu/fastlab/ticket/19

Reorganize namespaces

Reported by rcurtin on 31 Jul 40110399 06:40 UTC
The current use of namespaces is a little shaky and doesn't make all that much sense to people new to the code. Let's aim for something more like...

fastlib {
  fastlib::col
  fastlib::data (or fastlib::file?  merge these two)
  fastlib::fx
  fastlib::linalg
  fastlib::math
  fastlib::mlpack
  fastlib::par
  fastlib::thor
  fastlib::tree
}

I may have missed some components there but the general idea is that the namespace names should be descriptive enough to explain what that component is while not being a nuisance to type, and we should try to restrict the number of namespaces we use (hence the merge of ::file and ::data, since they seem to be related).

Everything should fall under the '''fastlib''' namespace.

Setup trac-doxygen plugin

Reported by rcurtin on 2 Oct 40073490 23:33 UTC

  • Download and install doxygen plugin
  • Setup svn hooks to generate doxygen documentation after each commit

Setup trac-doxygen plugin

Reported by rcurtin on 2 Oct 40073490 23:33 UTC

  • Download and install doxygen plugin
  • Setup svn hooks to generate doxygen documentation after each commit

Thor Compilation error

Reported by march on 12 May 40305755 01:46 UTC
On my mac (OS 10.5):

After configuring with these options:

lawn-128-61-121-6:trunk march$ cd build/
lawn-128-61-121-6:build march$ cmake -D CMAKE_INSTALL_PREFIX=/Users/march/fastlib/trunk/build -D WITH_SPARSE=OFF ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- The Fortran compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working Fortran compiler: /usr/local/bin/gfortran
-- Check for working Fortran compiler: /usr/local/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/local/bin/gfortran supports Fortran 90
-- Checking whether /usr/local/bin/gfortran supports Fortran 90 -- yes
-- A library with BLAS API found.
-- A library with LAPACK API found.
-- Found Pthreads: /usr/lib/libpthread.dylib
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/march/fastlib/trunk/build

I get this compilation error in THOR:

lawn-128-61-121-6:build march$ make
Scanning dependencies of target fastlib
[ 1%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/cc.cc.o
[ 2%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/ccmem.cc.o
[ 2%] Building C object fastlib/CMakeFiles/fastlib.dir/base/common.c.o
[ 3%] Building C object fastlib/CMakeFiles/fastlib.dir/base/debug.c.o
[ 4%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/otrav.cc.o
[ 4%] Building CXX object fastlib/CMakeFiles/fastlib.dir/col/col.cc.o
[ 5%] Building CXX object fastlib/CMakeFiles/fastlib.dir/data/dataset.cc.o
[ 6%] Building CXX object fastlib/CMakeFiles/fastlib.dir/file/textfile.cc.o
[ 7%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/datanode.c.o
[ 7%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/fx.c.o
[ 8%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/stopwatch.c.o
[ 9%] Building CXX object fastlib/CMakeFiles/fastlib.dir/la/uselapack.cc.o
[ 9%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/discrete.cc.o
[ 10%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/geometry.cc.o
[ 11%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/statistics.cc.o
[ 12%] Building CXX object fastlib/CMakeFiles/fastlib.dir/mmanager/memory_manager.cc.o
[ 12%] Building CXX object fastlib/CMakeFiles/fastlib.dir/par/thread.cc.o
[ 13%] Building CXX object fastlib/CMakeFiles/fastlib.dir/thor/distribcache.cc.o
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:346: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:347: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:363: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:371: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:379: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::OT__TraverseObject_(TVisitor_):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:352: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:353: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::Add(const IoStats&):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:389: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:389: error: const class IoStats has no member named n_reads_
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:390: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:390: error: const class IoStats has no member named n_writes_
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::RecordRead(uint64):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:398: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::RecordWrite(uint64):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:404: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::Reset():
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:411: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:411: error: n_writes_ was not declared in this scope
make[* fastlib/CMakeFiles/fastlib.dir/thor/distribcache.cc.o Error 1
make[
* fastlib/CMakeFiles/fastlib.dir/all Error 2
make: *_* [all] Error 2

Finish Trac setup

Reported by rcurtin on 23 Jun 40066507 16:53 UTC

  1. Put out a hit on the bastard that came into my room and interrupted my thought process. '''(done)'''
  2. Ensure CSS has no readability problems. '''(done)'''
  3. Set up milestones and roadmap. '''(done)'''
  4. Set up a few components and versions. '''(done)'''
  5. Announce existence of FASTLAB Trac '''(done)'''

Set up testing and benchmarking framework

Reported by rcurtin on 27 Jul 40301847 09:46 UTC
This is a master ticket for a very big, time-consuming task.

The end goal of this is to have a set of tests that are run by the automatic build server once the current svn build is run. These tests will be unit tests as well as tests of the MLPACK methods. Timing information should be collected so that speed improvements (or the lack of them) can be seen.

However it should also be trivial for a user to run these tests. That is, if they type make test, the tests should all be run. This will require including the necessary datasets in the build, and making sure that the information for each test to be run is there.

As it currently stands, a lot of the MLPACK methods build a test executable which is supposed to be run with some set of parameters, but a lot of them don't include the right datasets in the right places or document how to use them. Anyways the intricacies of these tests need to be documented, and CMake targets to actually run the tests should be included (this should not be hard although it may be difficult to make that cross-platform and it may be that that is not feasible in the end).

Boost has a unit testing framework which warrants some investigation here (or so I hear).

Migrated-From: http://trac.research.cc.gatech.edu/fastlab//ticket/19

Stop using likely() and unlikely() preprocessor macros where possible

Reported by rcurtin on 9 Oct 40301866 07:06 UTC
No. Profiling information is smarter than us. Hell, even the page that documents __builtin_expect(), which is what likely() really depends on, says

You may use __builtin_expect to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.

Admittedly it must be noted that when replacing the uses of these macros, some care most be used to see the situations where profiling won't actually catch the necessary optimization.

Setup trac-doxygen plugin

Reported by rcurtin on 2 Oct 40073490 23:33 UTC

  • Download and install doxygen plugin
  • Setup svn hooks to generate doxygen documentation after each commit

Minimize preprocessor macro usage

Reported by rcurtin on 3 Feb 40289652 20:26 UTC
Macros can make life particularly difficult. In the fastlib code alone I count 249 #defines (does '''not''' include header protection like #define THOR_TREE_H).

http://www-cs-students.stanford.edu/~blynn/c/ch07.html

http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.5
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.4
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.5
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.6

Anyways, this ticket is meant as a master ticket to manage all the other individual tickets relating to the removal and replacement of macros with safer, modern solutions (add relevant tickets to 'Blocked By' field).

LI preprocessor macro conflict with Trilinos

Reported by rcurtin on 19 Feb 40287389 01:46 UTC
I found this particularly useful snippet in sparse_matrix.h:

// you need this because trillinos redifines it. It's ok
// if you don't have it, but you will get an annoying warning
#ifdef F77_FUNC
#undef F77_FUNC
#endif
// trilinos uses this identifier, which is not so surprising.
// this is why you should think twice about macros.
#ifdef LI
#undef LI
#endif

Aside from actually almost shouting a vulgarity (and I wonder why people look at me funny), we need to do any of the following:

  • find a new name for LI (easiest)
  • move away from printf(); potentially to cout (C++ standard)

This applies for the L32 and L64 macros too, which are used to add an 'l' or an 'll' to a printf format string (i.e. %llu or %"L64"u); these are defined in fastlib/base/basic_types.h.

cout may be the best way to go with this, because I think it will automatically print with the correct precision and length, but I need to check into that. Overhauling all printfs with a cout though will be particularly time-consuming and difficult, but worth it to fix this macro mess.

For my particular problem (in mlpack/kernel_pca) I have just made a cheap hack for now.

Remove dead branches and cruft from svn

Reported by rcurtin on 12 Jan 40066690 22:40 UTC
I notice 'fastlib', 'fastlib2', 'fastlib3', 'fastlib-cmake' in the svn tree but only 'fastlib2' has been touched recently. 'fastlib-cmake' was never reintegrated into the project. The status of that needs to be fixed.

We should also move to the standard 'trunk/ branches/ tags/' format of svn repositories, because that is standard. If anything the dead fastlib branches should be moved into branches/ with a more accurate description of why they were branched (if there was an actual reason, if there is not, it should be removed entirely). 'fastlib-cmake' should be moved into 'branches/', but it has its own svn tree beneath it (???) which should be removed. Alternately, a 'trunk/ branches/ tags/' tree could be created beneath the 'fastlib/' directory, which is what has been done for 'mathProg' (which by the way is being correctly used, as far as svn standards go).

There is also a good amount of cruft beneath the papers/ directory -- for example, compilation artifacts that are not necessary, such as any .aux files. I don't know if removing that is even worth the effort.

Inside of the 'fastlib/' directory, the 'bin/', 'bin_keep/', 'lib/', and 'include/' directories are unnecessary. They should be generated and populated at build-time, not stored in the svn repository. On top of that those directories (and any other build artifacts) should be added to the svn:ignore property, so 'svn status' doesn't display all that after building.

Add svn:ignore properties to any build artifacts

Reported by rcurtin on 2 Mar 40080066 08:26 UTC
(see ticket summary)

A tedious task, but someone should do it eventually.

Preferably just in fastlib/, but if it gets done for the other trees too, that would also be cool.

Some old contrib/ code uses incorrect fx function signatures

Reported by rcurtin on 18 Jan 40286349 19:33 UTC
Each has a different particular error during compilation, but I suspect that the fx API was updated and these bits of code never were. These should be very simple fixes. Here is the list I've come up with:

contrib/nvasil/all_centroid_knn/
contrib/nvasil/non_convex_mvu/
contrib/pram/lle/
contrib/pram/opt/
contrib/pram/sparsepca/

Huh, I thought my list was longer than that.

Integrate cmake build system into fastlib trunk

Reported by rcurtin on 25 Jan 40079323 07:33 UTC
fl-build needs to go. Unwieldy, large dependency that nobody's maintaining.

cmake is actually not a build system but a Makefile generator (slightly more complex than that). It can be tuned to output Visual Studio projects or standard GNU Makefiles or all sorts of other random stuff like that. It was chosen for its portability, since autotools tends to be geared much more towards Linux than anything else (autotools is also like shooting yourself in the face with a knife).

Leif did work on this in what is currently the /fastlib-cmake/ svn directory, but it was never re-integrated into the main build system. It needs to be

  • polished
  • checked on several different system configurations
  • reintegrated into the trunk
  • introduced to the general FASTLAB public

Make GenMatrix's PrintDebug work with templates

Reported by march on 10 Oct 40155575 11:33 UTC
PrintDebug() for a GenMatrix only prints floating points correctly. It would be nice if it could handle other basic types (e.g. ints and bools).

Minimize preprocessor macro usage

Reported by rcurtin on 3 Feb 40289652 20:26 UTC
Macros can make life particularly difficult. In the fastlib code alone I count 249 #defines (does '''not''' include header protection like #define THOR_TREE_H).

http://www-cs-students.stanford.edu/~blynn/c/ch07.html

http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.5
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.4
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.5
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.6

Anyways, this ticket is meant as a master ticket to manage all the other individual tickets relating to the removal and replacement of macros with safer, modern solutions (add relevant tickets to 'Blocked By' field).

links to tutorials on Github page

Will changing tutorials.txt to markdown break anything ? I see section annotations there, not sure if they are referenced somewhere.

Finish Trac setup

Reported by rcurtin on 23 Jun 40066507 16:53 UTC

  1. Put out a hit on the bastard that came into my room and interrupted my thought process. '''(done)'''
  2. Ensure CSS has no readability problems. '''(done)'''
  3. Set up milestones and roadmap. '''(done)'''
  4. Set up a few components and versions. '''(done)'''
  5. Announce existence of FASTLAB Trac '''(done)'''

Replace GenMatrix and similar code with Armadillo matrix library

Reported by rcurtin on 13 May 40311109 08:00 UTC
In late 2009, some people at NICTA (in Australia) apparently decided to start writing a C++ linear algebra library. It integrates with LAPACK and ATLAS, and is called Armadillo.

I did some very cursory speed benchmarks to see if this sort of thing would be applicable to us (sources for fl_matrix.cpp and arma_matrix.cpp are attached), using the simple time command and eyeballing the averages.

'''Test 0''': initialize one matrix, fill it with a value, and copy it all to another matrix

|| matrix size || fl_matrix || arma_matrix ||
|| 10x10 || 0.004s || 0.004s ||
|| 100x100 || 0.004s || 0.004s ||
|| 1000x1000 || 0.048s || 0.034s ||
|| 50x50000 || 0.104s || 0.072s ||
|| 100x100000 || 0.292s || 0.172s ||
|| 40x1000000 || 0.960s || 0.648s ||

'''Test 1''': initialize three matrices, multiply the first two, outputting into the third (which has already been initialized)

|| matrix size || fl_matrix || arma_matrix ||
|| 100x100 || 0.008s || 0.008s ||
|| 1000x1000 || 0.720s || 0.704s ||
|| 5000x5000 || 1m13.529s || 1m13.245s ||

'''Test 2''': initialize two matrices, and multiply them into an uninitialized third

|| matrix size || fl_matrix || arma_matrix ||
|| 100x100 || 0.008s || 0.008s ||
|| 1000x1000 || 0.692s || 0.688s ||
|| 5000x5000 || 1m13.449s || 1m13.245s ||

Then I looked at memory usage with valgrind, holding the matrix size constant (1000x1000):

|| test || fl_matrix || arma_matrix ||
|| copy (0) || 32,002,641 bytes || 24,003,209 bytes ||
|| multiply (1) || 32,475,825 bytes || 32,476,393 bytes ||
|| multiply (2) || 40,475,825 bytes || 40,476,395 bytes ||

So we can see that this library performs at least as well as or better than our Matrix classes. We should switch to it, because it is actual, modern C++; we don't have to maintain it; and as the project grows in popularity (which it looks to be doing) it is likely to get faster without us having to actually do any work toward that end.

One minor problem is that the documentation on their website is not really all that amazing or really helpful; however, the source looks to have better technical documentation if you download it. I will be branching fastlib to fastlib-armadillo to try and fight with getting this all working. I expect this to be a time-consuming and difficult venture, partially due to the current immaturity of Armadillo, but I do think it will pay off in the long term in terms of maintenance.

Thor Compilation error

Reported by march on 12 May 40305755 01:46 UTC
On my mac (OS 10.5):

After configuring with these options:

lawn-128-61-121-6:trunk march$ cd build/
lawn-128-61-121-6:build march$ cmake -D CMAKE_INSTALL_PREFIX=/Users/march/fastlib/trunk/build -D WITH_SPARSE=OFF ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- The Fortran compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working Fortran compiler: /usr/local/bin/gfortran
-- Check for working Fortran compiler: /usr/local/bin/gfortran -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/local/bin/gfortran supports Fortran 90
-- Checking whether /usr/local/bin/gfortran supports Fortran 90 -- yes
-- A library with BLAS API found.
-- A library with LAPACK API found.
-- Found Pthreads: /usr/lib/libpthread.dylib
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/march/fastlib/trunk/build

I get this compilation error in THOR:

lawn-128-61-121-6:build march$ make
Scanning dependencies of target fastlib
[ 1%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/cc.cc.o
[ 2%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/ccmem.cc.o
[ 2%] Building C object fastlib/CMakeFiles/fastlib.dir/base/common.c.o
[ 3%] Building C object fastlib/CMakeFiles/fastlib.dir/base/debug.c.o
[ 4%] Building CXX object fastlib/CMakeFiles/fastlib.dir/base/otrav.cc.o
[ 4%] Building CXX object fastlib/CMakeFiles/fastlib.dir/col/col.cc.o
[ 5%] Building CXX object fastlib/CMakeFiles/fastlib.dir/data/dataset.cc.o
[ 6%] Building CXX object fastlib/CMakeFiles/fastlib.dir/file/textfile.cc.o
[ 7%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/datanode.c.o
[ 7%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/fx.c.o
[ 8%] Building C object fastlib/CMakeFiles/fastlib.dir/fx/stopwatch.c.o
[ 9%] Building CXX object fastlib/CMakeFiles/fastlib.dir/la/uselapack.cc.o
[ 9%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/discrete.cc.o
[ 10%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/geometry.cc.o
[ 11%] Building CXX object fastlib/CMakeFiles/fastlib.dir/math/statistics.cc.o
[ 12%] Building CXX object fastlib/CMakeFiles/fastlib.dir/mmanager/memory_manager.cc.o
[ 12%] Building CXX object fastlib/CMakeFiles/fastlib.dir/par/thread.cc.o
[ 13%] Building CXX object fastlib/CMakeFiles/fastlib.dir/thor/distribcache.cc.o
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:346: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:347: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:363: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:371: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:379: error: uint does not name a type
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::OT__TraverseObject_(TVisitor_):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:352: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:353: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::Add(const IoStats&):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:389: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:389: error: const class IoStats has no member named n_reads_
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:390: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:390: error: const class IoStats has no member named n_writes_
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::RecordRead(uint64):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:398: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::RecordWrite(uint64):
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:404: error: n_writes_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h: In member function void IoStats::Reset():
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:411: error: n_reads_ was not declared in this scope
/Users/march/fastlib/trunk/fastlib/thor/blockdev.h:411: error: n_writes_ was not declared in this scope
make[* fastlib/CMakeFiles/fastlib.dir/thor/distribcache.cc.o Error 1
make[
* fastlib/CMakeFiles/fastlib.dir/all Error 2
make: *_* [all] Error 2

Clean up unnecessary compiler.h preprocessor madness

Reported by rcurtin on 24 Nov 40302814 14:13 UTC
Most of the stuff in base/compiler.h is of the form:

#ifdef NO_COMPILER_DEFS
#define SOME_ATTRIBUTE __attribute__((something))
#else
#define SOME_ATTRIBUTE
#endif

Watch this:

#ifndef __GNUC__
#define __attribute__(x) 
#endif

And bam, the problem is solved. This should be done to remove most of the random #define statements, make code a little less confusing, and prune down compiler.h to an absolute minimum.

mlpack/series_expansion segfaults with no arguments

Reported by rcurtin on 5 Jan 40286439 14:40 UTC
It should give a help/usage dialog instead, and it should also give the help dialog when passed the '-h' option.

I am willing to bet that several other executables are like this also.

Add svn:ignore properties to any build artifacts

Reported by rcurtin on 2 Mar 40080066 08:26 UTC
(see ticket summary)

A tedious task, but someone should do it eventually.

Preferably just in fastlib/, but if it gets done for the other trees too, that would also be cool.

Remove dead branches and cruft from svn

Reported by rcurtin on 12 Jan 40066690 22:40 UTC
I notice 'fastlib', 'fastlib2', 'fastlib3', 'fastlib-cmake' in the svn tree but only 'fastlib2' has been touched recently. 'fastlib-cmake' was never reintegrated into the project. The status of that needs to be fixed.

We should also move to the standard 'trunk/ branches/ tags/' format of svn repositories, because that is standard. If anything the dead fastlib branches should be moved into branches/ with a more accurate description of why they were branched (if there was an actual reason, if there is not, it should be removed entirely). 'fastlib-cmake' should be moved into 'branches/', but it has its own svn tree beneath it (???) which should be removed. Alternately, a 'trunk/ branches/ tags/' tree could be created beneath the 'fastlib/' directory, which is what has been done for 'mathProg' (which by the way is being correctly used, as far as svn standards go).

There is also a good amount of cruft beneath the papers/ directory -- for example, compilation artifacts that are not necessary, such as any .aux files. I don't know if removing that is even worth the effort.

Inside of the 'fastlib/' directory, the 'bin/', 'bin_keep/', 'lib/', and 'include/' directories are unnecessary. They should be generated and populated at build-time, not stored in the svn repository. On top of that those directories (and any other build artifacts) should be added to the svn:ignore property, so 'svn status' doesn't display all that after building.

Clean up unnecessary compiler.h preprocessor madness

Reported by rcurtin on 24 Nov 40302814 14:13 UTC
Most of the stuff in base/compiler.h is of the form:

#ifdef NO_COMPILER_DEFS
#define SOME_ATTRIBUTE __attribute__((something))
#else
#define SOME_ATTRIBUTE
#endif

Watch this:

#ifndef __GNUC__
#define __attribute__(x) 
#endif

And bam, the problem is solved. This should be done to remove most of the random #define statements, make code a little less confusing, and prune down compiler.h to an absolute minimum.

Integrate cmake build system into fastlib trunk

Reported by rcurtin on 25 Jan 40079323 07:33 UTC
fl-build needs to go. Unwieldy, large dependency that nobody's maintaining.

cmake is actually not a build system but a Makefile generator (slightly more complex than that). It can be tuned to output Visual Studio projects or standard GNU Makefiles or all sorts of other random stuff like that. It was chosen for its portability, since autotools tends to be geared much more towards Linux than anything else (autotools is also like shooting yourself in the face with a knife).

Leif did work on this in what is currently the /fastlib-cmake/ svn directory, but it was never re-integrated into the main build system. It needs to be

  • polished
  • checked on several different system configurations
  • reintegrated into the trunk
  • introduced to the general FASTLAB public

Integrate cmake build system into fastlib trunk

Reported by rcurtin on 25 Jan 40079323 07:33 UTC
fl-build needs to go. Unwieldy, large dependency that nobody's maintaining.

cmake is actually not a build system but a Makefile generator (slightly more complex than that). It can be tuned to output Visual Studio projects or standard GNU Makefiles or all sorts of other random stuff like that. It was chosen for its portability, since autotools tends to be geared much more towards Linux than anything else (autotools is also like shooting yourself in the face with a knife).

Leif did work on this in what is currently the /fastlib-cmake/ svn directory, but it was never re-integrated into the main build system. It needs to be

  • polished
  • checked on several different system configurations
  • reintegrated into the trunk
  • introduced to the general FASTLAB public

Stop using likely() and unlikely() preprocessor macros where possible

Reported by rcurtin on 9 Oct 40301866 07:06 UTC
No. Profiling information is smarter than us. Hell, even the page that documents __builtin_expect(), which is what likely() really depends on, says

You may use __builtin_expect to provide the compiler with branch prediction information. In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.

Admittedly it must be noted that when replacing the uses of these macros, some care most be used to see the situations where profiling won't actually catch the necessary optimization.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.