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/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/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/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/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/204Binary operations on Tensors use update operators2017-11-21T13:33:42+01:00Philipp TrunschkeBinary operations on Tensors use update operatorsFor example: xerus::Tensor::operator/ calls xerus::Tensor::operator/=
This causes unexpected behaviour.For example: xerus::Tensor::operator/ calls xerus::Tensor::operator/=
This causes unexpected behaviour.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/198libxerus_misc.a is falsy build with -lcholmod etc.2017-05-22T16:15:43+02:00Fuchsi*libxerus_misc.a is falsy build with -lcholmod etc.Version 3.0https://git.hemio.de/xerus/xerus/-/issues/197premature deallocation of temporary tensors in python2017-05-23T00:53:41+02:00Fuchsi*premature deallocation of temporary tensors in pythonindexing a temporary tensor leads to invalid memory access. the lifetime of the tensor likely has to be bound to the lifetime of the resulting indexed tensor somehow...
eg.
~~~ python
xe.frob_norm(xe.Tensor.identity({10,10})(i&0))
~~~indexing a temporary tensor leads to invalid memory access. the lifetime of the tensor likely has to be bound to the lifetime of the resulting indexed tensor somehow...
eg.
~~~ python
xe.frob_norm(xe.Tensor.identity({10,10})(i&0))
~~~Version 3.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/185improve creation of random orthogonal matrices / tensors2017-03-28T21:55:56+02:00Fuchsi*improve creation of random orthogonal matrices / tensorsusing a QR on a i.i.d. gaussian random matrix will only create orthogonal matrices distributed according to the haar measure if the diagonal entries of the upper-triangular matrix are normalized (eg. all positive). for the lapack call dg...using a QR on a i.i.d. gaussian random matrix will only create orthogonal matrices distributed according to the haar measure if the diagonal entries of the upper-triangular matrix are normalized (eg. all positive). for the lapack call dgeqrf that we use so far this is not the case.Version 3.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/184pyton wrapper broken by changes in measurement sets2017-03-28T21:55:56+02:00Fuchsi*pyton wrapper broken by changes in measurement setsVersion 3.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/178timestamp of log msg is from before the execution of whatever is printed2017-03-28T21:55:56+02:00Fuchsi*timestamp of log msg is from before the execution of whatever is printedVersion 3.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/177error.log is always created2017-03-28T21:55:56+02:00Fuchsi*error.log is always createdmaybe we should remove the feature of streaming the log to a file altogether. same thing can be achieved by calling the application with "./foo 2>error.log"maybe we should remove the feature of streaming the log to a file altogether. same thing can be achieved by calling the application with "./foo 2>error.log"Version 3.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/176Exception in test cases with -D_GLIBCXX_DEBUG active2017-03-28T21:55:56+02:00Sebastian WolfException in test cases with -D_GLIBCXX_DEBUG active```
| resize_dimension starting: /usr/include/c++/5.3.1/bits/random.h:1683: std::uniform_int_distribution<_IntType>::param_type::param_type(_IntType, _IntType) [with _IntType = long unsigned int]: Assertion '_M_a <= _M_b' failed.
``````
| resize_dimension starting: /usr/include/c++/5.3.1/bits/random.h:1683: std::uniform_int_distribution<_IntType>::param_type::param_type(_IntType, _IntType) [with _IntType = long unsigned int]: Assertion '_M_a <= _M_b' failed.
```Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/169replace allocator may use one past the end index2017-03-28T21:55:56+02:00Fuchsi*replace allocator may use one past the end indexin line 78 of allocator.cpp
````
if (xm::astore.buckets[numBucket].empty()) {
````in line 78 of allocator.cpp
````
if (xm::astore.buckets[numBucket].empty()) {
````Version 2.3Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/168LOG_ABSOLUTE_TIME not compatible to GCC 4.92017-03-28T21:55:56+02:00Fuchsi*LOG_ABSOLUTE_TIME not compatible to GCC 4.9std::put_time was only added in GCC 5.0 -> we need to find another solution (likely some ugly c functions - dig in git to check what we used before put_time?)std::put_time was only added in GCC 5.0 -> we need to find another solution (likely some ugly c functions - dig in git to check what we used before put_time?)Version 2.3Fuchsi*Fuchsi*