NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2020-03-25T13:32:31Zhttps://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/439Small unifications2020-04-03T07:51:25ZPhilipp Arrasparras@mpa-garching.mpg.deSmall unificationsMartin ReineckeMartin Reineckehttps://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/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/476TEST2020-05-19T13:42:15ZMartin ReineckeTESThttps://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/491Quick fix?2020-05-21T10:12:55ZPhilipp Arrasparras@mpa-garching.mpg.deQuick fix?https://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/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/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/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/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/541WIP: More constant support (new version)2020-06-18T17:26:40ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: More constant support (new version)https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/527WIP: More constant support2020-06-18T18:19:39ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: More constant supportMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/537WIP: Test Fisher matrix using definition2020-06-19T08:53:13ZReimar H LeikeWIP: Test Fisher matrix using definitionIt was long requested to have a way to test Fisher matrices for their correctness. In this branch, we test whether the sample expectation value
```math
\left<\frac{\partial H(d|x)}{\partial x}\frac{\partial H(d|x)}{\partial x^\dagger}\ri...It was long requested to have a way to test Fisher matrices for their correctness. In this branch, we test whether the sample expectation value
```math
\left<\frac{\partial H(d|x)}{\partial x}\frac{\partial H(d|x)}{\partial x^\dagger}\right>_{P(d|x)}
```
agrees with the actual fisher metric. We do so by comparing the fisher application at one random vector with the expectation value defined above. The test is however only statistically true for the limit of many data realizations $d$, and thus the error margins have to be taken large in order to avoid false postives.Philipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/546WIP: Allow for opting out of asperity and flexibility2020-06-30T21:11:27ZGordian EdenhoferWIP: Allow for opting out of asperity and flexibilityhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/538WIP: Pointwise Safe Exponential Function2020-07-16T08:17:03ZLukas PlatzWIP: Pointwise Safe Exponential FunctionExponential overflows introduce an often times unnessecary source of run abortions into reconstructions. Especially in early reconstructions, when the position is still far from converged, stray samples tend to cause exponential overflow...Exponential overflows introduce an often times unnessecary source of run abortions into reconstructions. Especially in early reconstructions, when the position is still far from converged, stray samples tend to cause exponential overflows during the minimizations, if not mitigated.
I propose to add a 'safe' exponential function to the pointwise functions which surpesses exponential overflows. It does this by clipping input value to safe limits prior to applying the exponential function.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/560Leaky clip2020-07-17T13:09:27ZLukas PlatzLeaky clipProposed by @lerou in !538, this MR adds the pointwise function `leaky_clip` to NIFTy.
Not sure if this should go into NIFTy 6 or 7, but it would be useful in both.Proposed by @lerou in !538, this MR adds the pointwise function `leaky_clip` to NIFTy.
Not sure if this should go into NIFTy 6 or 7, but it would be useful in both.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/536WIP: Catch FloatingPointError exeception in `energy.at` to store crashing position2020-07-17T13:10:31ZLukas PlatzWIP: Catch FloatingPointError exeception in `energy.at` to store crashing positionMost numerical errors (overflows, divisions by zero, …) with NIFTy occur during minimization runs. Tracking down what caused the fault condition is hard, as the NIFTy minimizers only return positions on non-faulty exits and the exact loc...Most numerical errors (overflows, divisions by zero, …) with NIFTy occur during minimization runs. Tracking down what caused the fault condition is hard, as the NIFTy minimizers only return positions on non-faulty exits and the exact location of the numerical error has to be reconstructed manually by observing the tracelog.
Typically, the numerical errors occur in the energy functionals to be minimized. Because of this, I propose to augment those to pickle their position on internal crashes.
This will help users in reconstructing the state at crash and in finding the crash reasons.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/571Instance helpers2020-10-20T10:44:25ZPhilipp Arrasparras@mpa-garching.mpg.deInstance helpers