NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2020-06-05T08:36:57Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/518WIP: More restrictive scaling operator2020-06-05T08:36:57ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: More restrictive scaling operatorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/517WIP: Jacobian test not assuming C-linearity2020-06-05T08:36:16ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Jacobian test not assuming C-linearityhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/357WIP: Work on simplify for constant input2020-05-27T17:16:29ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Work on simplify for constant inputPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/511WIP: Made _sumup of KL faster by summing up in parallel when possible2020-05-27T15:38:26ZReimar H LeikeWIP: Made _sumup of KL faster by summing up in parallel when possibleMarked as work in progress because
1. has to be tested whether it is really faster
2. Speed could in theory be even more increased if one uses the numpy versions of communication, i.e. Send and Recv
The basic idea of this change is...Marked as work in progress because
1. has to be tested whether it is really faster
2. Speed could in theory be even more increased if one uses the numpy versions of communication, i.e. Send and Recv
The basic idea of this change is to sum up the KL in a tree-type structure. This goes as follows.
Suppose we have this list:
```
1 2 3 4 5 6
```
Then we combine the numbers pairwise:
```
1 2 3 4 5 6
| / | / | /
3 7 11
```
We then iterate this procedure:
```
3 7 11
| / |
10 11
```
Here the 11 was at the end of the list, and was thus not summed. Finally we get
```
10 11
| /
21
```
This procedure converges in O(ln(N)) steps, if N is the length of the list.
Suppose the objects of the list are distributed over different MPI tasks, then in every step we need at most N/2 communications. However, because the range of numbers is shared consecutively, every task needs to communicate at most 2 times per iteration, so most communications are done in parallel. The method is organized such that the result of a sum is always computed by the higher ranked tasks. i.e. if the list is distributed over 4 tasks as follows:
```
1 1 2 2 3 4
```
Then the ranks that hold the sums evolve as follows:
```
1 1 2 3 3 4
| / | / | /
1 3 4
```
So far two communication were needed, with task 3 needing to communicate twice. It continues as
```
1 3 4
| / |
3 4
| /
| /
4
```
with two more necessary communications. In the end task 4 broadcasts the result.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/500WIP: More restrictive scaling operator2020-05-25T11:06:55ZReimar H LeikeWIP: More restrictive scaling operatorScalingOperators do not know the dtype, on which theyu operate. This can lead to problems if complex scalingOperators act on real fields, as this causes it to cast the input to a complex number. However, the adjoint then does not cast th...ScalingOperators do not know the dtype, on which theyu operate. This can lead to problems if complex scalingOperators act on real fields, as this causes it to cast the input to a complex number. However, the adjoint then does not cast this number back, leading to inconsistencies. This branch therefore raises an error whenever a ScalingOperator with complex factor acts on a real input, forcing the User to use an adjoint Realizer to cast the field to a complex one first.
The DiagonalOperator should probably do the same check.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/491Quick fix?2020-05-21T10:12:55ZPhilipp Arrasparras@mpa-garching.mpg.deQuick fix?https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/484WIP: Find position multifields2020-05-20T10:37:02ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Find position multifieldshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/476TEST2020-05-19T13:42:15ZMartin ReineckeTESThttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/473WIP: Resolve "Streamline arguments position"2020-05-19T11:40:08ZRouven LemmerzWIP: Resolve "Streamline arguments position"Closes #300Closes #300https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/409Simplify licensing2020-05-13T11:36:53ZGordian EdenhoferSimplify licensingFixes #283 .Fixes #283 .https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/439Small unifications2020-04-03T07:51:25ZPhilipp Arrasparras@mpa-garching.mpg.deSmall unificationsMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/430metric_gaussian_kl.py: Fix samples property2020-03-25T13:32:31ZGordian Edenhofermetric_gaussian_kl.py: Fix samples propertyFix a bug which was introduced in eded7903fb making it impossible to
access the sample property of a KL with mirrored samples as tuples
can not be added to lists.Fix a bug which was introduced in eded7903fb making it impossible to
access the sample property of a KL with mirrored samples as tuples
can not be added to lists.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/424Add Wiener process and integrated Wiener process2020-03-16T17:44:52ZPhilipp Arrasparras@mpa-garching.mpg.deAdd Wiener process and integrated Wiener processhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/420Update year in copyright2020-03-15T13:46:07ZPhilipp Arrasparras@mpa-garching.mpg.deUpdate year in copyrighthttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/290WIP: added a value linearization consistency check2020-03-09T11:06:20ZReimar H LeikeWIP: added a value linearization consistency checkAdded a test that checks wether an operator yields the same result if called with Linearization or without (different code might be called in either case).
Would be ready to merge, however one could extend the tests, e.g. make one check ...Added a test that checks wether an operator yields the same result if called with Linearization or without (different code might be called in either case).
Would be ready to merge, however one could extend the tests, e.g. make one check that checks all the linear consistency checks if it is called with a linear operator and checks all the gradient and nonlinear consistency as well as the linear consistency for the jacobian when called with an Operator. That way we could unify the consistency checks and gain more coverage.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/393WIP: Add convience functions to Operator2020-03-09T10:59:32ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Add convience functions to Operatorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/412Gig energy cleanup pa2020-03-06T12:05:47ZPhilipp Arrasparras@mpa-garching.mpg.deGig energy cleanup pahttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/397Unbreak MetricGaussianKL_MPI in nifty62019-12-09T13:36:11ZGordian EdenhoferUnbreak MetricGaussianKL_MPI in nifty6In commit eda70a19f7, the internal config handling scheme was removed
without ensuring that MetricGaussianKL_MPI is imported. This lead to a
state in which the MPI version of the KL is never imported. Fix this by
always importing MetricG...In commit eda70a19f7, the internal config handling scheme was removed
without ensuring that MetricGaussianKL_MPI is imported. This lead to a
state in which the MPI version of the KL is never imported. Fix this by
always importing MetricGaussianKL_MPI in __init__.py.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/354WIP: Independent sl amplitudes2019-12-06T15:26:35ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Independent sl amplitudeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/367WIP: Normalized amplitudes pp2019-11-26T09:53:12ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Normalized amplitudes pp