michael-lehn / flens Goto Github PK

I think the word 'include' in the folder stub should not be path of the make-installed tree

I think the normal convention is to let the user specify the complete install path equivalent to
/usr/include
or
/usr/local/include
or
/usr/include/include/gtk-3.0/gtk (for say some package version gtk3 of some package gtk)

explanation:
start in directory : /full/path/
git clone "https://github.com/michael-lehn/FLENS.git"
mkdir build
mkdir include
cd build
cmake ../FLENS -DCMAKE_INSTALL_PREFIX=cd .. ; pwd/include/flens2015/flens
make install

files install to
/full/path/include/flens2015/flens/include/cxxblas
/full/path/include/flens2015/flens/include/cxxlapack
/full/path/include/flens2015/flens/include/external
/full/path/include/flens2015/flens/include/flens

notice the include stub repeated under flens2015/flens.
flens2015/flens has only a single subfolder 'include'
I believe that its the second 'include', and not the first that was specified on command line of cmake build that is not necessary, please check the convention.

the fix:
change line 5
set(INCLUDE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/include" CACHE PATH "Include files install path")
to
set(INCLUDE_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/flens" CACHE PATH "Include files install path")

the commands...
cmake ../FLENS -DCMAKE_INSTALL_PREFIX=cd .. ; pwd/include/flens2015
make install

... will install as
/full/path/include/flens2015/flens/cxxblas
/full/path/include/flens2015/flens/cxxlapack
/full/path/include/flens2015/flens/external
/full/path/include/flens2015/flens/flens

the gcc include arg needed will be -I /full/path/include/flens2015/flens
A pkg-config conf file can also be made, that will automatically create the compiler include option

the source code will have include < flens/flens.cxx >

I remember the old version does support sparse matrix.

Which function should i use.

Hi Michael,

I'm having a hard time trying to understand a weird behavior when using some custom Indexbase with my containers. To illustrate that, lets suppose I define two types of GeMatrix: a
GEMatrix6 with IndexBase 6, and a GEMatrix1 with IndexBase 1. Suppose I create
2 matrices of each type: GEMatrix6 A, and GEMatrix1 B. What is bothering me is
that if I do the following:

GEMatrix1 B = A;

the matrix B assumes the IndexBase of A (6), despite being of type GEMatrix1
(with IndexBase 1). The same goes if I do the following:

GEMatrix1 B;
B = A;

By contrast, if I do the following:

GEMatrix1 B(A.numRows(), A.numCols());
B = A;

then the matrix B assumes the IndexType of its type (1), as I expected in the
first place for all cases. Is this different behavior normal?

Currently, GEMM and GEMV (and related functions) call scal which is not totally correct. In the original BLAS implementation, first it is checked wether the scaling parameter is 0 or not.
If the scaling parameter is 0, the array is 0 initialized.

This leads to such problems as spurious nan's when computing the result into an uninitialized block of memory for xtensor-blas users.

Ref: xtensor-stack/xtensor-blas#75

Hi Michael,

I would like to report a issue with the method antiDiag() defined in the FullStorage class. If I
didn't misuse it, its not correctly implemented. For it to work, I had to make
adjustments in its code. Currently its function body is composed of the
following:

IndexType row_ = (d>0) ? 0 : -d;
IndexType col_ = (d>0) ? d : 0;

IndexType row = firstRow() + row_;
IndexType col = firstCol() + col_;

return ArrayView(std::min(numRows()-row_, numCols()-col_),
                 &(operator()(row,lastCol()-col+1)),
                 -leadingDimension()+1,
                 firstViewIndex,
                 allocator());

I replaced this content with the following, making it work as expected (//***
points out changed lines):

IndexType row_ = (d<0) ? 0 : d; //***
IndexType col_ = (d<0) ? -d : 0; //***

IndexType row = row_;   //***
IndexType col = firstCol() + col_;

return ArrayView(std::min(numRows()-row_, numCols()-col_),
                 &(operator()(lastRow()-row,col)),    //***
                 leadingDimension()-1,  //***
                 firstViewIndex,
                 allocator());

I hope you guys keep up this great work.

No, it is not a joke: On Windows there are forbidden folder and file names! Among others the name "aux" is on the list!

Although I personally do not care about Windows we will rename the folders "aux" in FLENS to "auxiliary"

is this just a temporary problem?

OOP09-CPP. Ensure that single-argument constructors are marked "explicit"

A single-argument constructor may be used as an implicit conversion function, unless it is marked "explicit" (see [ISO/IEC 14882-2003] Section 12.3.1, "Conversion by constructor"). Such implicit conversions may be unexpected, and lead to undesirable behavior.

When compiling the code in Visual Studio 2017 I got an error in file densevector.h. For some reason VS does not understand Engine::defaultIndexBase.

This can be fixed easily by adding a new constant to the class:
static const IndexType defaultIndexBase = Engine::defaultIndexBase;

The method declaration of resize can then refer to that constant.

Hi dear Michael,

We met a problem using the real variant of the ev method that only computes eigenvalues (flens/lapack/ge/ev.tcc line 1359). In fact, this function redirects only to the complex variant with temporary workspace.

We corrected it by separating the real and the complex version, this latter being unchanged except for the restrictions. We wrote the real variant as follows:

template <typename MA, typename VW>
typename RestrictTo<(IsRealGeMatrix<MA>::value
                  && IsRealDenseVector<VW>::value),
         typename RemoveRef<MA>::Type::IndexType>::Type
ev(MA       &&A,
   VW       &&w)
{
    typedef typename RemoveRef<VW>::Type VWT;
    VWT wi;

    return ev(false, false, A, w, wi, A, A);
}

Maybe, we misuse the method, if so, we would be glad to know the right way to follow.

Sincerely,

Thibaud.

Hi Michael,

The scalar operation "abs" defined in flens/scalaroperations/abs.tcc is not working with types other than integer and complex. Whats happening is that its "evalScalarClosure" method is calling the "abs" method defined outside the std namespace.

By doing that, it invokes either the "abs" method from cstdlib header (for integers), or the one from complex header (for complex), never the one provided in cmath header (suitable for float/double types).

I solved that by simply inserting "std::" in line

return std::abs(exp.left().value());

Cheers.

Hi Michael,

are the headers in cxxstd maybe supposed to be installed by cmake? The cxxstd/complex.h include in auxiliary/compatibletype.h cannot be found by the compiler.

Cheers
Raimar