xerus issueshttps://git.hemio.de/xerus/xerus/-/issues2019-06-13T12:51:20+02:00https://git.hemio.de/xerus/xerus/-/issues/256REQUIREs in `uq_ra_adf_iv` are too restrictive2019-06-13T12:51:20+02:00Manuel MarschallREQUIREs in `uq_ra_adf_iv` are too restrictiveThe function `xerus::uq::uq_ra_adf_iv` in `src/xerus/applications/uqADF.cpp` requires
```
_x.order() <= _measurements.parameterVectors[i].size()
```
This is too restrictive in the UQ setting.
It requires the order of the tensor to be l...The function `xerus::uq::uq_ra_adf_iv` in `src/xerus/applications/uqADF.cpp` requires
```
_x.order() <= _measurements.parameterVectors[i].size()
```
This is too restrictive in the UQ setting.
It requires the order of the tensor to be less than the order of the rank-one measurement.
This does not take into account the fact that the first mode is reserved for the physical domain.
I propose to change the `REQUIRE` condition to
```
_x.order() <= _measurements.parameterVectors[i].size()+1
```Version 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/230Memory Leak in Python Interface2019-06-13T01:30:25+02:00Philipp TrunschkeMemory Leak in Python InterfaceThere is a memory leak in the python interface to `xerus`.
Minimal working example:
```
import xerus as xe
i, = xe.indices(1)
d = xe.Tensor.random([100]*3)
while True:
d_tmp = xe.Tensor()
d_tmp(i&0) << d(i&0)
```There is a memory leak in the python interface to `xerus`.
Minimal working example:
```
import xerus as xe
i, = xe.indices(1)
d = xe.Tensor.random([100]*3)
while True:
d_tmp = xe.Tensor()
d_tmp(i&0) << d(i&0)
```Version 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/253make recompiles xerus even without changes2019-06-12T22:00:18+02:00RoteKeksemake recompiles xerus even without changesVersion 4.0https://git.hemio.de/xerus/xerus/-/issues/248uq_ra_adf may diverge with non-uniform weights2019-04-05T12:54:54+02:00Philipp Trunschkeuq_ra_adf may diverge with non-uniform weightsVersion 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/84Building and using the static library with LTO and clang++ fails2019-04-03T18:52:42+02:00Sebastian WolfBuilding and using the static library with LTO and clang++ failsThe gcc wrapper used to create LTO enabled static libraries don't seem to work with clang++.The gcc wrapper used to create LTO enabled static libraries don't seem to work with clang++.https://git.hemio.de/xerus/xerus/-/issues/202failing tests in gitlab pipeline2019-04-03T18:51:52+02:00Fuchsi*failing tests in gitlab pipelinesome of them are very strange. e.g. the following one should never fail
```
| Product_1000x1000 starting: ✗ +00:01:39,286 fullTensor_product.cxx: 409 : warning : memcmp(res.get_dense_data(), C.get_dense_data(), sizeof(value_t)*1000*...some of them are very strange. e.g. the following one should never fail
```
| Product_1000x1000 starting: ✗ +00:01:39,286 fullTensor_product.cxx: 409 : warning : memcmp(res.get_dense_data(), C.get_dense_data(), sizeof(value_t)*1000*1000)==0 failed
✓ ✓
| Product_1000x1000: FAILED! (535.353 ms, seed = baadf00d)
```
(see https://git.hemio.de/xerus/xerus/-/jobs/2291 )https://git.hemio.de/xerus/xerus/-/issues/201calling ALS(A, x, x) results in strange behaviour2019-03-24T04:13:23+01:00Fuchsi*calling ALS(A, x, x) results in strange behaviourshould either print an error or better yet: create a local copy of x as rhs.should either print an error or better yet: create a local copy of x as rhs.Version 4.0Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/240invalid read of size 8 in TRASD unittest2019-03-23T15:19:36+01:00Fuchsi*invalid read of size 8 in TRASD unittest```
| Fixed_Rank_Recovery starting: ==9814== Invalid read of size 8
==9814== at 0x4EC23A: tt_dofs(std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) (c...```
| Fixed_Rank_Recovery starting: ==9814== Invalid read of size 8
==9814== at 0x4EC23A: tt_dofs(std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) (common.hxx:38)
==9814== by 0x4F14AD: random_low_tt_ranks (common.hxx:83)
==9814== by 0x4F14AD: {lambda()#1}::operator()() const [clone .isra.151] (asd.cxx:39)
==9814== by 0x68571F: operator() (std_function.h:687)
==9814== by 0x68571F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==9814== by 0x481A4B: main (test.cpp:231)
==9814== Address 0xcabaae8 is 0 bytes after a block of size 8 alloc'd
==9814== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==9814== by 0x4F13B6: allocate (new_allocator.h:111)
==9814== by 0x4F13B6: allocate (alloc_traits.h:436)
==9814== by 0x4F13B6: _M_allocate (stl_vector.h:296)
==9814== by 0x4F13B6: _M_create_storage (stl_vector.h:311)
==9814== by 0x4F13B6: _Vector_base (stl_vector.h:260)
==9814== by 0x4F13B6: vector (stl_vector.h:460)
==9814== by 0x4F13B6: random_low_tt_ranks (common.hxx:80)
==9814== by 0x4F13B6: {lambda()#1}::operator()() const [clone .isra.151] (asd.cxx:39)
==9814== by 0x68571F: operator() (std_function.h:687)
==9814== by 0x68571F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==9814== by 0x481A4B: main (test.cpp:231)
```Version 4.0Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/225HT::round uses wrong index to access desired rank2019-03-20T11:29:56+01:00Fuchsi*HT::round uses wrong index to access desired rankfrom valgrind:
```
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::H...from valgrind:
```
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F038C: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:393)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016== Address 0xaafe060 is 0 bytes after a block of size 16 alloc'd
==19016== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==19016== by 0x6988AF: allocate (new_allocator.h:111)
==19016== by 0x6988AF: allocate (alloc_traits.h:436)
==19016== by 0x6988AF: _M_allocate (stl_vector.h:296)
==19016== by 0x6988AF: _M_create_storage (stl_vector.h:311)
==19016== by 0x6988AF: _Vector_base (stl_vector.h:260)
==19016== by 0x6988AF: vector (stl_vector.h:429)
==19016== by 0x6988AF: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F038C: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:393)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016==
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F053E: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:395)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016== Address 0xa4d6770 is 0 bytes after a block of size 16 alloc'd
==19016== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==19016== by 0x6988AF: allocate (new_allocator.h:111)
==19016== by 0x6988AF: allocate (alloc_traits.h:436)
==19016== by 0x6988AF: _M_allocate (stl_vector.h:296)
==19016== by 0x6988AF: _M_create_storage (stl_vector.h:311)
==19016== by 0x6988AF: _Vector_base (stl_vector.h:260)
==19016== by 0x6988AF: vector (stl_vector.h:429)
==19016== by 0x6988AF: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F053E: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:395)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
```
(HT::round should also be changed to divide provided _eps by the square-root of rounding operations performed to have error guarantees)Version 4.0RoteKekseRoteKeksehttps://git.hemio.de/xerus/xerus/-/issues/211Creation of big TT Train crashes2018-10-09T09:16:28+02:00RoteKekseCreation of big TT Train crashesHey ho,
the following code crushes.
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(784, 4), std::vector<size_t>(783,2));
}
```
It crushes in the QR decomposition i...Hey ho,
the following code crushes.
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(784, 4), std::vector<size_t>(783,2));
}
```
It crushes in the QR decomposition in ```blasLapackWrapper.cpp line 361``` (on development branch). It is able to perform 700 QR decomposition before it crushes. And indeed for smaller size it compiles:
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(700, 4), std::vector<size_t>(699,2));
}
```
Any ideas? The matrizes for the qQRare small, memory and cpu is plenty left. Maybe it is only on my machine?
Best regards MichaSebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/210offset_add is not behaving as expected2018-08-14T16:01:17+02:00RoteKekseoffset_add is not behaving as expected```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto test1 = xerus::Tensor::dirac({1,1,1},0);
auto test2 = xerus::Tensor::dirac({2,2,1},0);
test2[3] = 4;
test2[1] = 2;
test2[2] = 3;
XERUS_LOG(info, "test1 = \n" <<...```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto test1 = xerus::Tensor::dirac({1,1,1},0);
auto test2 = xerus::Tensor::dirac({2,2,1},0);
test2[3] = 4;
test2[1] = 2;
test2[2] = 3;
XERUS_LOG(info, "test1 = \n" << test1 );
XERUS_LOG(info, "test2 = \n" << test2 );
std::unique_ptr<Tensor> comb(new Tensor({3,3,2}));
comb->offset_add(test1, std::vector<size_t>({0,0,0}));
comb->offset_add(test2, std::vector<size_t>({1,1,1}));
XERUS_LOG(info, "comb = \n" << *comb );
}
```
The above code returns:
```
+00:00:00,000 testAddition.cpp : 10 : info : test1 =
1.000000
+00:00:00,000 testAddition.cpp : 11 : info : test2 =
1.000000 0.000000
0.000000 1.000000
+00:00:00,002 testAddition.cpp : 28 : info : comb =
1.000000 / 0.000000 0.000000 / 0.000000 0.000000 / 0.000000
0.000000 / 0.000000 0.000000 / 1.000000 0.000000 / 2.000000
0.000000 / 3.000000 0.000000 / 4.000000 0.000000 / 0.000000
```
I expected
```
+00:00:00,000 testAddition.cpp : 10 : info : test1 =
1.000000
+00:00:00,000 testAddition.cpp : 11 : info : test2 =
1.000000 0.000000
0.000000 1.000000
+00:00:00,002 testAddition.cpp : 28 : info : comb =
1.000000 / 0.000000 0.000000 / 0.000000 0.000000 / 0.000000
0.000000 / 0.000000 0.000000 / 1.000000 0.000000 / 2.000000
0.000000 / 0.000000 0.000000 / 3.000000 0.000000 / 4.000000
```
Is this a bug?
Cheers MichaSebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/23Code coverage detection not working properly2018-04-23T03:03:39+02:00Sebastian WolfCode coverage detection not working properlyCode coverage says:
file index.hpp : 2 of 4 tests performed
However there are only two REQUIREs in index.hpp, which are most certainly called. Probably the problem is that the corresponding functions also appear inlined?Code coverage says:
file index.hpp : 2 of 4 tests performed
However there are only two REQUIREs in index.hpp, which are most certainly called. Probably the problem is that the corresponding functions also appear inlined?Version 1.2Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/33problems with the MISC_NAMESPACE macro2018-04-23T03:03:39+02:00Fuchsi*problems with the MISC_NAMESPACE macro1. not defining it before including any individual misc/*.h file will result in a warning about undefined macros / variables
2. setting it via `#define MISC_NAMESPACE` results in `#define MISC` which interestingly results in the followi...1. not defining it before including any individual misc/*.h file will result in a warning about undefined macros / variables
2. setting it via `#define MISC_NAMESPACE` results in `#define MISC` which interestingly results in the following error message:
```
bla.cpp:(.text+0xa58): undefined reference to `(anonymous namespace)::get_call_stack()'
```
This might be the only way to reference an anonymous namespace...???version 1.1https://git.hemio.de/xerus/xerus/-/issues/44REQUIRE_TEST macro file name identification (in cases of ../ in the path)2018-04-23T03:03:39+02:00Fuchsi*REQUIRE_TEST macro file name identification (in cases of ../ in the path)Version 1.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/54Compiling xerus without runtime checks causes the test cases to end with and ...2018-04-23T03:03:39+02:00Sebastian WolfCompiling xerus without runtime checks causes the test cases to end with and segmentation fault.Version 1.0https://git.hemio.de/xerus/xerus/-/issues/61Makefile does not cover changes in .hxx files correctly2018-04-23T03:03:38+02:00Fuchsi*Makefile does not cover changes in .hxx files correctlychanges in .hxx files cause recompilation of the binary - but apparently not the text object fileschanges in .hxx files cause recompilation of the binary - but apparently not the text object filesVersion 1.0Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/65fix clang support2018-04-23T03:03:38+02:00Fuchsi*fix clang supportat the moment we cannot compile with the clangat the moment we cannot compile with the clanghttps://git.hemio.de/xerus/xerus/-/issues/70TTTensor Chop not working as intended2018-04-23T03:03:38+02:00Fuchsi*TTTensor Chop not working as intended- Number of external indices of left and right side is wrong in the operator case.
- same functionality can be obtained by simply contracting the component tensors as `nodes[i].tensorObject(i&1,j) * nodes[i+1].tensorObject(j,k&1)`, so w...- Number of external indices of left and right side is wrong in the operator case.
- same functionality can be obtained by simply contracting the component tensors as `nodes[i].tensorObject(i&1,j) * nodes[i+1].tensorObject(j,k&1)`, so why the hassle of manually counting dimensions?
- one could argue that this function is rather specific to one purpose and thus rather a part of the ALS it is being written for, than an important part of tttensor :P (alternatively this function should be less specific. eg. by allowing to remove several nodes inbetween to allow dmrg implementations to use it)version 1.1Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/73Ensure that xerus works at least with tensors of size 2^64-1 (size_t).2018-04-23T03:03:38+02:00Sebastian WolfEnsure that xerus works at least with tensors of size 2^64-1 (size_t).Tensors (e.g. TTTensors) with order 10 and dimensions 10 do not fit in an unit32, causing serious malfunction somewhere in xerus.Tensors (e.g. TTTensors) with order 10 and dimensions 10 do not fit in an unit32, causing serious malfunction somewhere in xerus.Version 1.0https://git.hemio.de/xerus/xerus/-/issues/75TTTensors canonicalize (and probably also other functions) apparently writes ...2018-04-23T03:03:38+02:00Sebastian WolfTTTensors canonicalize (and probably also other functions) apparently writes to shared data (tensorsObjects of its nodes).version 1.1Sebastian WolfSebastian Wolf