I can not do matrix multiplications with armadillo. I don't know if there are more features I can't use. So far, I've only been using vectors and dot product with no problem.
Basically:
#include <iostream>
#include <armadillo>
using namespace std;
using namespace arma;
int main(){
//this works
vec v = randu<vec>(10);
cout<<dot(v,v)<<endl;
int n =5;
//this doesn't work
mat M = randu<mat>(n,n); // program compiles but stops running when reaches here
cout<<M*M<<endl;
return 0;
}
I am using the newest version of codeblock and armadillo. OS is windows 7. I've included the lapack and blas libraries in the compiler linker settings and blas_win64_MT and lapack_win64_MT are both in PATH. And I've also included de armadillo folder in the search directory. In config.hpp (armadillo folder), #define ARMA_USE_LAPACK and #define ARMA_USE_BLAS are uncommented. #define ARMA_USE_WRAPPER is commented. Also, I have tried to add -lapack -lblas to the build->project options->compiler->other options and to build->project options->linker setting->other options, but I had no success. Same thing happened when I tried to add -larmadillo to the compiler with #define ARMA_USE_WRAPPER uncommented.
What am I missing?
Your program is of course perfectly fine as Armadillo is a well-designed and delivered library.
What may not be right is your installation, or local setup. Only you can figure that out.
On my box, and on the command-line -- where I only need to link with libarmadillo which itself has linkage to lapack and blas:
edd#max:/tmp$ g++ -o arma5by5 arma5by5.cpp -larmadillo
edd#max:/tmp$ ./arma5by5
4.06892
1.5043 1.3996 0.6353 0.8246 1.4694
1.6543 1.6822 0.4338 0.6739 1.5782
1.3145 1.2759 0.3825 0.4967 1.2959
1.4222 1.4584 1.0028 1.3742 1.3593
1.6126 1.7886 0.4599 0.8348 1.5648
edd#max:/tmp$
Related
I am using the build tools provided by Rtools.
gcc version 8.3.0 x86_64-w64-mingw32 (Built by Jeronen for the R-project)
GNU ld version 2.33.1
eigen version 3.4.0
I have been testing various functions of the eigen package, and when I calculated the singular values using the BDCSVD object, the linker just hangs with full cpu usage. The following line is causing the trouble:
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
This line of code compiles fine. Just the particular linker does not return. I have waited a few minutes for the linker, but it just won't return.
On the other hand, when I used the latest gcc from the Windows Linux subsystem. Everything worked fine. So is this a known issue? Can it be easily fixed (but still using the build system provided by Rtools in Windows)?
PS: I have encounted this issue several times before, but the cpp files were much more complex, so I wasn't sure back then what caused the hanging linker.
Update:
A code sample is provided below. I configured my Windows copy of eigen3 using the "Unix Makefiles" option, since I do not have Visual Studio and don't want to download it.
Here is the cpp file:
#include <iostream>
#include <Eigen/Dense>
using namespace std;
using namespace Eigen;
int main()
{
double data[9];
for (int i = 0; i < 9; i++)
{
data[i] = i;
}
Map<MatrixXd> m(data, 3, 3);
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
auto v = svd.singularValues();
cout << "condition #: " << v.maxCoeff() / v.minCoeff() << endl;
}
I was trying to calculate the condition number of a singular matrix here.
Compiled using command line:
g++ -I"my eigen lib" t.cpp -o t.exe
where g++ comes from Rtools, "my eigen lib" is the eigen include directory, t.cpp the cpp file, and t.exe the build target.
Surprisingly or not, when I changed the algo from BDCSVD to JacobSVD, the compilation would succeed, even though BDCSVD defaults to JacobSVD for small matrices.
cc1plus and as both returned normally. ld keeps running forever, it seems.
Edits:
It's been awhile, but I am still looking for an answer.
I am trying to use eigen for linear algebra but can't get it to include the eigen library. It keeps on giving me an error even though I am following all the instructions to include the eigen folder while compiling the program. I have tried this in both visual studio 2017 and the MinGW version of gcc. I am giving the relevant part of my code and what I am doing to include the Eigen library.
#include <iostream>
#include <fstream>
using namespace std;
#include <Eigen/Dense>
using Eigen::MatrixXd;
int main()
{
MatrixXd m(2,2);
m(0,0) = 3;
m(1,0) = 2.5;
m(0,1) = -1;
m(1,1) = m(1,0) + m(0,1);
std::cout << m << std::endl;
}
To run this in g++, I am using the command
g++ -I /C:\Users\aqils\Documents\C++\Eigen/ Matrixbasics.cpp -o Matrixbasics.exe
Here C:\Users\aqils\Documents\C++\Eigen
is the path for the unzipped Eigen package.
Matrixbasics.cpp is the name of the c++ file and it's located in the folder
C:\Users\aqils\Documents\C++
The error I get is
"Fatal error: Eigen/Dense: no such file or directory"
To run this in Visual Studio 2017, I have followed these steps to add a folder to a project:
1. Right click on the project name in the solution explorer and hit properties
2. Then look for c++ and find the option for adding a folder.
3. Select the Eigen package folder in the tree view, hit ok and then apply.
4. Run the program. It should now work.
I have spent several frustrating days trying to make this work and have read all related questions on stack overflow as well as several other websites. The answers don't go beyond the above instructions which I am already following. Will be really grateful if someone can help me fix the problem.
You can replace this line:
#include <Eigen/Dense>
by:
#include <eigen3/Eigen/Dense>
I'm trying to compile a very simple MEX file in Matlab using GCC/G++...
First I checked that this is already installed in matlab by:
!which gcc
output:
/usr/bin/gcc ...
After, I tried to do the following:
mex -v GCC='/usr/bin/gcc' hello.c
but it stills compiling with XCode Clang...
This is to use G++ with OPENMP library for parallel computing.
Is known that is NOT OFFICIALLY Supported by Mathworks, but POSSIBLE.
MATLAB only supports XCode 5.1+ or 6.0 on Mac.
See this list of supported compilers, from Mathworks:
Supported Compilers and Compatible Compilers - Release R2015a
EDIT!!!
Even Windows doesn't support a GCC compiler. However, if you can build your library in Windows there is a 3rd party library called Gnumex designed to provide MinGW or CygWin GCC compiler capabilities for Matlab MEX. Take a look.
An update on their website says that changed to Matlab have broken their utility. However, there seems to be a workaround available via this StackOverflow post.
Finally, I found a proper way to solve it...
First, the file mexopts.sh doesn't appear in the folder by default, is necessary to open a terminal and look for it and create it (then Matlab will redirect to it automatically when compiling with MEX):
find ~/ -name 'mexopts.sh'
and will appear:
/Users/FOO//.Trash/MATLAB_R2014a.app/bin/mexopts.sh
Then, copy it as:
cp /Users/FOO//.Trash/MATLAB_R2014a.app/bin/mexopts.sh ~/.matlab/R2014a
then go to the folder cd ~/.matlab/R2014a
and change permissions for your user as:
chmod u+rwx mexopts.sh
then, open it with your default text editor (Sublime text recommended) as:
open mexopts.sh
and edit the following:
Change where appears macosx10.7 to your current version, in my case macos10.10
then, modify the following lines as describen in (http://www.mathworks.com/matlabcentral/newsreader/view_thread/334250):
# CC='xcrun -sdk macosx10.7 clang' #OLD
CC='xcrun /usr/local/bin/gcc' #NEW
# CXX='xcrun -sdk macosx10.7 clang++' #OLD
CXX='xcrun /usr/local/bin/g++' #NEW
# CLIBS="$CLIBS -lstdc++" #OLD
CLIBS="$CLIBS -lstdc++ -I/usr/local/lib -lgomp" #directory <-I/usr/local/lib> #NEW
#CXXLIBS="$MLIBS -lstdc++" #OLD
CXXLIBS="$MLIBS -lstdc++ -I/usr/local/lib -lgomp" #NEW
IMPORTANT NOTE:
Make sure that your current G++/G++4.9 is able to compile with OpenMP, trying to include <omp.h> in a hello world file doing in the command line:
g++-4.9 -o test hello.cpp -fopenmp
or
g++ -o test hello.cpp -fopenmp
is also possible that a file is corrupted and is necessary to do Can not compile fortran because dyld: Library not loaded :
brew rm cloog
brew install cloog
(But check first)...
Is also possible that if you're not able to compile with OMP is necessary to do first a couple of things as described here (Compile OpenMP programs with gcc compiler on OS X Yosemite):
1. Got a new gcc complier from http://hpc.sourceforge.net/
2. Place a new executable folder by $ sudo tar -xvf gcc-4.9-bin.tar -C /
3. Switched to it by export PATH=/usr/local/bin:$PATH
Finally, try to compile your MEX file with:
mex hello.cpp COMPFLAGS="/openmp $COMPFLAGS"
That's it
... .
I was unable to get the mexopts.sh approach to work.
Instead I followed this first to make sure that I could get omp to work with xcode: clang-omp in Xcode under El Capitan
Then the mex compile st
mex CC='/usr/local/bin/clang-omp' -I/usr/local/include -I/usr/local/lib /usr/local/lib/libiomp5.dylib test.c
However, I get some weird results when comparing between Matlab and pure terminal based c. The common work, I put in the file "do_work.c":
double do_work(int maxit){
double tmp,x,x2;
int numThreads=0;
numThreads = omp_get_max_threads() ;
// numThreads = 4;
printf("Setting max num threads to %d.\n",numThreads);
omp_set_num_threads(numThreads);
// int Nthreads=omp_get_num_threads();
tmp = 0.0;
x2 = 0.0;
#pragma omp parallel for shared(tmp,x2) private(x)
for (int i=0;i<maxit;i++) {
x = 0.0;
for (int k=0; k<10000; k++) x += pow(.011,1.0/.5); // does some heavy computations
tmp += (double) i ;
if (i%1000==0){
printf("Hello, %d\n",i);
}
x2 += x;
}
printf("x2 = %f\n",x2);
return tmp;
}
I can compile this from command line using this wrapper file:
#include "stdio.h"
#include "math.h"
#include <libiomp/omp.h>
#include "do_work.c"
double do_work(int maxit);
int main(int argc, const char * argv[]) {
do_work(10000);
return 0;
}
I compile it by running
clang-omp -fopenmp test_c_wrapper.c
I can also interface to it from Matlab with this code:
#include "mex.h"
#include <libiomp/omp.h>
#include "math.h"
#include "stdio.h"
#include "do_work.c"
double do_work(int maxit);
void mexFunction(int nlhs, mxArray *plhs[],int nrhs,const mxArray *prhs[])
{
do_work(10000);
return;
}
To compile this from Matlab, save it as test.c and run the first mex statement that I mentioned higher up. However, the results are really strange. It looks as if Matlab is not even using omp. At the same time, Matlab actually runs faster than the terminal based one, even though Matlab appears to run in serial mode? Strange... Also, the omp_get_max_threads() is acting weird, it doesn't return the same number every time when called from Matlab even though it does from terminal.
I am a Mac OS X 10.8.3 user (Mountain Lion). I have download armadillo and installed it in OS X as per README.txt instructions. It compiles fine by typing:
g++ ... *stuff* ... -O2 -larmadillo
in the terminal. By including the same linker arguments in Eclipse CDT, I have been able to compile armadillo in Eclipse (Juno) in OS X. However, my problem is when it comes to compiling in Xcode 4 -- the program I need to have armadillo in! I have already tried adding the "-O2 -larmadillo" string to the other linker flags. I also tried adding /usr/local/lib and /usr/local/include/ in Header Search Paths and Library Search Paths. I have gotten Xcode 4 to thus recognize the command:
# include < armadillo >
or
# include "/usr/local/include/armadillo"
HOWEVER, when it comes to compile time Xcode 4 does NOT recognize a line like:
mat A;
So for the code:
# include < iostream >
# include < armadillo >
using namespace std;
int main() {
mat A;
return 0;
}
I get errors like:
Use of undeclared identifier 'mat'; did you mean 'max'?
Expected ';' after expression
Use of undeclared identifier 'A'
Reference to overloaded function could not be resolved; did you mean to call it?
Note that the code does not even get to the compile stage!
I would like to now : how do I properly link and compile a C++ code which uses the armadillo library in Xcode 4???
Thank you very much!
Daniel.
did you forget to add "using namespace arma"? ie.
# include <iostream>
# include <armadillo>
using namespace std;
using namespace arma; // make Armadillo classes and functions visible by default
I have a C++ library with a particular function that returns a boost::any, whose value type is a particular enum defined in a different included library. This normally works fine.
But when I link to my library dynamically from a Matlab mex file, typeid(the_enum_t) seems to be different for the things made in my library and those made in the caller, in that it doesn't compare ==. Since I'm actually using flann, whose version of boost::any performs a check based on type_info::==, this makes everything break. Static linking works fine, but that's kind of a pain here, and I'd really rather have it work either way.
I thought type_info::== was supposed to work consistently across library boundaries. Does this have to do with how Matlab dynamically loads libraries from mex?
Here's some code to reproduce this (also available in easy-to-download form, with a makefile, in this gist).
First, a stand-in for the library that defines the enum (flann):
namespace library {
enum the_enum_t { el_one, el_two, el_three };
}
Now a proxy for my library, stubby.hpp:
#include <boost/any.hpp>
#include "the_enum.hpp"
boost::any the_function();
And its implementation stubby.cpp:
#include "stubby.hpp"
boost::any the_function() {
return boost::any(library::el_two);
}
Finally, test code test.cpp, which is compiled with -DNO_MEX for a standalone and not for a mex file:
#include "stubby.hpp"
#include <boost/any.hpp>
#ifdef NO_MEX
#include <cstdio>
using std::printf;
int main() {
#else
#include "mex.h"
void mexFunction(int nlhs, mxArray **plhs, int nrhs, const mxArray **prsh) {
#endif
boost::any val_any = the_function();
printf("%s (equal: %d)\n",
val_any.type().name(),
val_any.type() == typeid(library::the_enum_t));
}
I get the expected output
N5flann17flann_algorithm_tE (equal: 1)
from each of
$ g++ -o test{,.cpp} -DNO_MEX libstubby.a && ./test
$ g++ -o test{_s,.cpp} -DNO_MEX libstubby.so && ./test_s
$ ln -sf test{,_s}.cpp && mex test_s.cpp libstubby.a && matlab -r test
But dynamically linking a mex file doesn't work:
$ mex test.cpp libstubby.so && matlab -r test
N5flann17flann_algorithm_tE (equal: 0)
I see this same behavior on
Matlab R2011b and R2011a, OSX 10.7, Apple gcc 4.2.1
Matlab R2011b, CentOS 5.7, gcc 4.1.2
Matlab R2010a, Ubuntu 11.04, gcc 4.4.5
The weird thing is that I could've sworn it worked a few months ago, but maybe I just did a bad job of testing.
Obviously I can get around this by static linking. But why is this happening? Does it have something to do with the way Matlab loads mex files and their libraries?
Boost has a workaround for this issue; see https://svn.boost.org/trac/boost/ticket/754
It's possible that boost is failing to enable the workaround. Try passing compiler flag -DBOOST_AUX_ANY_TYPE_ID_NAME per the patch on that ticket.