Use BLAS and LAPACK from Eigen - lapack

I've implemented a piece of code with Eigen and I would like Eigen to use BLAS and LAPACK .
I've seen here, that is possible but I don't know how or where to put those values/directives in the code.
I have to expecify somewhere the value EIGEN_USE_BLAS but I have no idea where.
I've seen that Eigen's source includes the code of BLAS and LAPACK, but I completelly ignore if it uses it by default or what. I'm using Eigen 3.3.3.

You don't put those directives in the code, you compile your code with these macros. For example:
LAPACK_FLAGS=('-D EIGEN_USE_LAPACKE=1 -lm -lblas -llapack -llapacke')
g++ --std=c++11 eigenSVD.cpp -o eigenSVD.cpp ${LAPACK_FLAGS[#]}
Take a look at Eigen/SVD, if your code is compiled with EIGEN_USE_LAPACKE, you see Eigen-lapacke interface and lapacke header files will be included.
#if defined(EIGEN_USE_LAPACKE) && !defined(EIGEN_USE_LAPACKE_STRICT)
#ifdef EIGEN_USE_MKL
#include "mkl_lapacke.h"
#else
#include "src/misc/lapacke.h"
#endif
#include "src/SVD/JacobiSVD_LAPACKE.h"
#endif

Well, I have found the solution
Include in your .h file the following:
// includes to make Eigen use BLAS+LAPACK
#include <complex>
#define EIGEN_SUPERLU_SUPPORT
#define EIGEN_USE_BLAS
#define EIGEN_USE_LAPACKE
#define LAPACK_COMPLEX_CUSTOM
#define lapack_complex_float std::complex<float>
#define lapack_complex_double std::complex<double>
// includes to call Eigen
#include <Eigen/Sparse>
#include <Eigen/StdVector>
The complex includes are necessary regardless of the use of complex matrices because LAPACK demmands you to define what you call a complex type.

Related

OpenCL program showing errors. What can be a possible solution?

I am getting certain errors as shown in the image below. I think there is a problem with the setting up of environment. I am new to this and couldn't figure out how to correct it. Please help.
enter image description here
You try to #include <CL/cl.hpp>, which is not installed with Your OpenCL implementation, check if the #include <CL/cl2.hpp> is (see https://github.com/KhronosGroup/OpenCL-CLHPP).
If You otherwise don't make usage of the OpenCL C++ Wrapper API (see Appendix D in OpenCL 1.2), then You may want to instead include <CL/cl.h> or better yet (to be portable to Apple MacOS):
#if defined(__APPLE__) && defined(__MACH__)
#include <OpenCL/opencl.h>
#else
#include <CL/cl.h>
#endif

How to write a Postgres language handler using MSVC

Here is the code, straight out of the sample. 64 bit install, x64 build.
#include "postgres.h"
#include "executor/spi.h"
#include "commands/trigger.h"
#include "fmgr.h"
#include "access/heapam.h"
#include "utils/syscache.h"
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
PGDLLEXPORT Datum plsample_call_handler(PG_FUNCTION_ARGS); // <-- the answer!!
PG_FUNCTION_INFO_V1(plsample_call_handler);
Datum
plsample_call_handler(PG_FUNCTION_ARGS)
{
Datum retval;
retval = 42;
return retval;
}
It compiles and links OK. Here is the SQL:
CREATE FUNCTION plsample_call_handler() RETURNS language_handler
AS 'TryPostgresPl.dll'
LANGUAGE C;
CREATE LANGUAGE plsample
HANDLER plsample_call_handler;
And here is the error message.
ERROR: could not find function "plsample_call_handler" in file "C:/Program Files/PostgreSQL/9.5/lib/TryPostgresPl.dll"
SQL state: 42883
So near and yet so far. Really no idea where to look.
Edited to show the answer as per Nick Barnes. Note that a peek with depends.exe showed 2 exports previously, now 3.
The sample in the Postgres docs is squarely targeted at Linux environments; apparently there's a bit more involved in Windows. There is an excellent article by #CraigRinger which explains how to go about it in Visual Studio.
In this case, it looks like you just need to add the following function prototype:
PGDLLEXPORT Datum plsample_call_handler(PG_FUNCTION_ARGS);
For me (Postgres 13 x64, VS2019, MSVC 14.27), it was enough to just add PGDLLEXPORT in front of PG_FUNCTION_INFO_V1, i.e:
PGDLLEXPORT PG_FUNCTION_INFO_V1(my_func);
Looking closer, this expands to the equivalent of:
PGDLLEXPORT extern Datum my_func(PG_FUNCTION_ARGS);
... plus a bunch more stuff
You'll notice that's very similar to what's being done manually in the accepted answer, so this way seems to avoid some duplication. The only difference is the extern keyword; to be honest I don't know enough about C to know why putting PGDLLEXPORT before extern is still valid (rather than after it as I see in all the examples), but the compiler doesn't complain and the extension works.
YMMV especially if these macros change in the future.

OpenCV project on iPhone - opencv.hpp building issue

I've cloned https://github.com/niw/iphone_opencv_test and tried to replace
#import <opencv2/imgproc/imgproc_c.h>
#import <opencv2/objdetect/objdetect.hpp>
with
#import <opencv2/opencv.hpp>
in OpenCVTestViewController.m file. But XCode threw following error:
iphone_opencv_test/opencv_device/include/opencv2/opencv.hpp:55:10: fatal error: 'opencv2/calib3d/calib3d.hpp' file not found [2]
#include "opencv2/calib3d/calib3d.hpp"
So, I've tried to remove the line #include "opencv2/calib3d/calib3d.hpp" from the opencv.hpp file. The error below was thrown:
iphone_opencv_test/opencv_device/include/opencv2/ml/ml.hpp:2075:10: fatal error: 'map' file not found [2]
#include <map>
I've also tried to change .m to .mm, but it seemed futile. Where I'm wrong?
There's a conflict between OpenCV's MAX/MIN macros and Cocoa's MAX/MIN. It leads to strange errors like this one at compile time. To bypass this problem, you can either:
1. add at the top of the pre-defined header file
2. totally decouple opencv and obj-c code, so that no .m/.mm file includes . This can be done for example by using boost GIL in-between, or using custom vanilla C++ classes to pass image data from Cocoa frameworks to opencv C++ image processing classes.

How to use Grand Central Dispatch in iOS in a .c file

I have some C code in an iOS project that I would like to optimize using GCD. Currently I can only get my code to compile if change my C file to an Objective-C file and import the Foundation framework. What do I have to include in my C file to get access to GCD?
I've tried:
#include <dispatch/dispatch.h>
but that doesn't seem to work it always complains about code blocks having the ^ character
You'll need to tell the compiler to enable Blocks with the -fblocks flag. You'll also need to use a compiler that understands blocks (Clang, for one).
You might need to;
#include <Block.h>
But it's not something I've done myself so could be wrong here.

Good way to document #undef in doxygen

I currently have a couple of #define in c files that turn off some functionality to hardware for testing. However, I want to document them with doxygen when they are undefined as well.
For example:
This works fine:
/// \def SIMULATE_SOME_HW_INTERFACE
/// Define this when you want to simulate HW interface.
#define SIMULATE_SOME_HW_INTERFACE
When you change the #define to #undef, you get a warning in doxygen, and it doesn't show up in the doxygen generated output. I want to document this #define wether it's defined or undefined.
How can I force doxygen to document a #undef???
Define them in a header file that is only included by Doxygen (put in a separate directory tree from the main source).
Guard this header file by wrapping it with a define that you only define in the Doxygen setup, eg:
#ifdef ONLY_FOR_DOXYGEN
/// \def SIMULATE_SOME_HW_INTERFACE
/// Define this when you want to simulate HW interface.
#define SIMULATE_SOME_HW_INTERFACE
#endif
I have used this to also conditionally include lightweight class definitions for things like MFC base classes so they appear as bases for the class hierarchy without having to parse all of MFC.
I found a kludgy way by adding the #undef under the #define. This way it's defined for Doxygen, but immediately undefined for the compiler.
/// \def SIMULATE_SOME_HW_INTERFACE
/// Define this when you want to simulate HW interface.
/// Comment out #undef to simulate HW interface
#define SIMULATE_SOME_HW_INTERFACE
#undef SIMULATE_SOME_HW_INTERFACE
I was trying to figure out how to set SIMULATE_HW_INTERFACE in the Doxyconfig file using PREDEFINED option. Couldn't get it to work. So here's my best solution so far.
I solved my problem with documenting compilerflags like this in the main headerfile:
/**
* \defgroup flags Compilerflags
*/
/**
* \def MY_FLAG
* \ingroup flags
* Dokumentation....
*/
#ifndef MY_FLAG
#define MY_FLAG
#undef MY_FLAG
#else
#define MY_FLAG
#endif
This way everything works fine: doxygen and compiling and you can keep specifying your flags in commandline...