xerus issueshttps://git.hemio.de/xerus/xerus/-/issues2017-05-09T16:42:09+02:00https://git.hemio.de/xerus/xerus/-/issues/194improve speed of Ax=b solve operations for matrices2017-05-09T16:42:09+02:00Fuchsi*improve speed of Ax=b solve operations for matricesperform checks similar to matlab: https://de.mathworks.com/help/matlab/ref/mldivide.html
for dense matrices:
- [X] not square operator -> use QR or SVD
- [ ] implement check & solver for permuted triangular matrices
- [x] not Hermitian -> LU solver
- [x] all positive / all negative diagonal -> try cholesky
- [X] default to LDL solver otherwise
for sparse:
- [ ] check for diagonality -> scale input
- [ ] check bandwidth < threshold -> banded solver
- [ ] implement check & solver for permuted triangular matrices
- [ ] not Hermitian -> LU solver
- [ ] all positive / all negative diagonal -> try cholesky
- [X] default to LDL solver otherwiseperform checks similar to matlab: https://de.mathworks.com/help/matlab/ref/mldivide.html
for dense matrices:
- [X] not square operator -> use QR or SVD
- [ ] implement check & solver for permuted triangular matrices
- [x] not Hermitian -> LU solver
- [x] all positive / all negative diagonal -> try cholesky
- [X] default to LDL solver otherwise
for sparse:
- [ ] check for diagonality -> scale input
- [ ] check bandwidth < threshold -> banded solver
- [ ] implement check & solver for permuted triangular matrices
- [ ] not Hermitian -> LU solver
- [ ] all positive / all negative diagonal -> try cholesky
- [X] default to LDL solver otherwiseVersion Xhttps://git.hemio.de/xerus/xerus/-/issues/190pydoc strings2019-03-12T16:25:44+01:00Fuchsi*pydoc stringsVersion Xhttps://git.hemio.de/xerus/xerus/-/issues/172Add TT-Cross Approximation2019-03-04T12:39:27+01:00Sebastian WolfAdd TT-Cross ApproximationVersion XPhilipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/130more example systems2019-03-04T13:56:09+01:00Fuchsi*more example systemsWhen writing example systems, consider adding them to the library and / or homepage as examples.
possible examples include:
- Hennon-Heiles potential in schredinger eq
- masters equation
- some tensor completion / recovery
- standard hamiltonians (spin systems)
- simple fem system (diffusion?) with qtt
- uq systemWhen writing example systems, consider adding them to the library and / or homepage as examples.
possible examples include:
- Hennon-Heiles potential in schredinger eq
- masters equation
- some tensor completion / recovery
- standard hamiltonians (spin systems)
- simple fem system (diffusion?) with qtt
- uq systemVersion Xhttps://git.hemio.de/xerus/xerus/-/issues/118new contraction heuristics2017-07-13T16:42:00+02:00Fuchsi*new contraction heuristics- [ ] implement brute force search for small number of nodes
- [ ] write more elaborate heuristics
- [ ] statistics about which heuristics were the best how often- [ ] implement brute force search for small number of nodes
- [ ] write more elaborate heuristics
- [ ] statistics about which heuristics were the best how oftenVersion Xhttps://git.hemio.de/xerus/xerus/-/issues/79Allow transformations between arbitary TensorNetworks without casting to Full...2019-03-04T14:30:32+01:00Sebastian WolfAllow transformations between arbitary TensorNetworks without casting to FullTensor.Version Xhttps://git.hemio.de/xerus/xerus/-/issues/69SparseTensor aware contraction heuristics2019-03-04T14:31:16+01:00Sebastian WolfSparseTensor aware contraction heuristicsThe complexity of sparse contractions is significantly different to the dense one and therefore requires new heuristics to detemrine the contraction order.The complexity of sparse contractions is significantly different to the dense one and therefore requires new heuristics to detemrine the contraction order.Version Xhttps://git.hemio.de/xerus/xerus/-/issues/42templatized value_t to allow calculations with complex numbers2019-03-04T14:54:41+01:00Fuchsi*templatized value_t to allow calculations with complex numbersThis would also simplify issue #39 and is required for most quantum calculations.
- [ ] overloaded wrapper functions for lapacke, blas and suitesparse
- [ ] prob. two template types: value_t and real_t (return value of forb_norm eg. should not be complex)
- [ ] optionally interaction between different templatized versions (eg. Tensor<double> with Tensor<float>?)This would also simplify issue #39 and is required for most quantum calculations.
- [ ] overloaded wrapper functions for lapacke, blas and suitesparse
- [ ] prob. two template types: value_t and real_t (return value of forb_norm eg. should not be complex)
- [ ] optionally interaction between different templatized versions (eg. Tensor<double> with Tensor<float>?)Version Xhttps://git.hemio.de/xerus/xerus/-/issues/38flop counts of all operations to better be able to compare algorithms2018-04-01T13:07:03+02:00Fuchsi*flop counts of all operations to better be able to compare algorithmsruntimes are ok, but heavily dependent on optimization efforts. FLOP counts are much more robust across architectures and independent of the writing effort put into the algorithms.runtimes are ok, but heavily dependent on optimization efforts. FLOP counts are much more robust across architectures and independent of the writing effort put into the algorithms.Version Xhttps://git.hemio.de/xerus/xerus/-/issues/55get rid of lapacke dependency2020-04-29T21:00:47+02:00Fuchsi*get rid of lapacke dependencyThe lapacke dependency is annoying (cannot be assumed to be installed), we only need few functions of it and those can easily be written manually.
- [ ] import lapacke source to 3rdParty folder
- [ ] unify functions to get rid of unnecessary transpositions
- [ ] allocate a thread_local work array to get rid of allocations per call
- [ ] use performance analysis (from makefile) to benchmarkThe lapacke dependency is annoying (cannot be assumed to be installed), we only need few functions of it and those can easily be written manually.
- [ ] import lapacke source to 3rdParty folder
- [ ] unify functions to get rid of unnecessary transpositions
- [ ] allocate a thread_local work array to get rid of allocations per call
- [ ] use performance analysis (from makefile) to benchmarkVersion XPhilipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/48doxygen modern layout2018-04-23T03:03:35+02:00Fuchsi*doxygen modern layoutVersion XFuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/243The runtime of unittests2019-04-05T01:21:15+02:00Sebastian WolfThe runtime of unittestsAs there were some complains about the runtime of the unit-tests by @example, we should probably discuss how to deal with those.
Personally I am fine with a runtime of ~5min, but this of course depends on hardware and style of working. Also using e.g. Valgrind increase the runtime to currently ~30min. Still I don't think we should remove working test-cases on which people spend time to implement just because they take time to run. So I would suggest to split the unit-tests in a "quick" and a "long" category such that people without time and/or without fast hardware can run a reduced subset of the tests (e.g. all unit test which typically require less than 0.5s)?As there were some complains about the runtime of the unit-tests by @example, we should probably discuss how to deal with those.
Personally I am fine with a runtime of ~5min, but this of course depends on hardware and style of working. Also using e.g. Valgrind increase the runtime to currently ~30min. Still I don't think we should remove working test-cases on which people spend time to implement just because they take time to run. So I would suggest to split the unit-tests in a "quick" and a "long" category such that people without time and/or without fast hardware can run a reduced subset of the tests (e.g. all unit test which typically require less than 0.5s)?Version X