Eigen Library Customized cwise operation - Implementation the "sign()" function in Eigen/C++

In programming language like MATLAB, many coefficient wise operations are provided as function calls: such as sign(M).

For the version of Eigen I currently using, there doesn't seem to have a correspondent build-in implementation cwise operation.

However, a customized cwise operation can be achieve using unaryExpr.

Here is a simple example for achieving similar functionality as the sign() in MATLAB.

float sign(float x)

{

  if (x > 0)

    return 1.0;

  else

    return -1.0;

}

Mat.unaryExpr(std::ptr_fun(sign))

Copy Constructor gonna F*** u over

a customized copy constructor that over-write the default one will not copy field you are not specified

Write CMAKE find module

1. in order to make your own FindXXX.cmake be recognized by cmake, you 

need to add the directory holding the FindXXX.cmake to the module path as bellow 

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") 

2. write the path searching script

3. set the correct variable name for your library path variable

(To be updated)

Use AddressSanitizer with CMake project

AddressSanitizer is a fast alternative of Valgrind for memory error check. It based on a totally different mechanism that substitute all the memory allocation and free functions in your code and keep track all memory operations.

Clang integrated AddressSanitizer since 3.1 version. We can use it directly by adding some compiler flags for Clang.

Something like this:
clang -fsanitize=address -O1 -fno-omit-frame-pointer -g tests.cpp

With CMake projection, however, we need to add the flag in your make file.

The simplest thing would be to add the following in your make file:
set(CMAKE_CXX_FLAGS "-fsanitize=address -O1 -fno-omit-frame-pointer -g")

Check nvidia card video memory usage on linux

nvidia-smi

GCC C++ Linker errors: Undefined reference to 'vtable for XXX', Undefined reference to 'ClassName::ClassName()'

(From Stack Overflow)
 Answer:

Assuming those methods are in one of the libs it looks like an ordering problem.
When linking libraries into an executable they are done in the order they are declared.
Also the linker will only take the methods/functions required to resolve currently oustanding dependencies. If a subsequent library then uses methods/functions that were not originally required by the objects you will have missing dependencies.
How it works:

• Take all the object files and combine them into an executable
• Resolve any dependecies among object files.
• Foreach library in order:
  • Check unresolved dependencies and see if the lib resolves them.
  • If so load required part into the executable.

Example:
Objects requires:

• Open
• Close
• BatchRead
• BatchWrite

Lib 1 provides:

• Open
• Close
• read
• write

Lib 2 provides

• BatchRead (but uses lib1:read)
• BatchWrite (but uses lib1:write)

If linked like this:

gcc -o plop plop.o -l1 -l2

Then the linker will fail to resolve the read and write symbols.
But if I linki the application like this:

gcc -o plop plop.o -l2 -l1

Then it will link correctly. As l2 resolves the BatchRead and BatchWrite dependencies but also adds two new ones (read and write). When we link with l1 next all four dependencies are resolved.

Recursively Delete .svn Directories

find . -type d -name .svn -exec rm -rf {} \;