NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2018-04-02T09:42:38Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/49WIP: refactor _distance_array_helper2018-04-02T09:42:38ZDixit, Jait (jaitd)WIP: refactor _distance_array_helperThe original implementation accepted an array which infact was just an integer cast as `np.ndarray` for each element of which (in this case 1), `m` was calculated which in turn was used to calculate the distance, which again was an `np.n...The original implementation accepted an array which infact was just an integer cast as `np.ndarray` for each element of which (in this case 1), `m` was calculated which in turn was used to calculate the distance, which again was an `np.ndarray`.
I've removed an unnecessary variable `size` and the implementation now directly uses the 'index' provided. The results are identical as the original implementation.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/375WIP: Projection Operators by Maxim2021-04-07T10:12:08ZLukas PlatzWIP: Projection Operators by MaximAdding the two projection operators Maxim wrote for his master Thesis to NIFTy.
They project sections of spherical spaces onto RGSpaces of similar resolution, conserving different properties each.Adding the two projection operators Maxim wrote for his master Thesis to NIFTy.
They project sections of spherical spaces onto RGSpaces of similar resolution, conserving different properties each.https://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/367WIP: Normalized amplitudes pp2019-11-26T09:53:12ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Normalized amplitudes pphttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/80WIP: Newton2017-05-06T23:50:14ZTheo SteiningerWIP: Newtonhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/20WIP: move smooth operation to field2016-09-24T13:02:33ZDixit, Jait (jaitd)WIP: move smooth operation to field- Refactor transformation_factory
- Add sanity checks and basic framework for smooth- Refactor transformation_factory
- Add sanity checks and basic framework for smoothTheo SteiningerTheo Steiningerhttps://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/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/534WIP: More derivatives2021-03-24T17:08:39ZPhilipp FrankWIP: More derivativesStart to include `DiffTensor` and `Taylor` into nifty.
Taylor is now an `Operator`.
Operators can now keep track of higher derivatives via `Taylor` Objects.
Open Issues and Todos:
- Write Tests
- `Linearization` vs `Difftensor`
I think ...Start to include `DiffTensor` and `Taylor` into nifty.
Taylor is now an `Operator`.
Operators can now keep track of higher derivatives via `Taylor` Objects.
Open Issues and Todos:
- Write Tests
- `Linearization` vs `Difftensor`
I think the latter can replace the former at some point
@parras @mtr I am happy for any input, suggestions!https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/446WIP: More derivatives2021-03-24T17:09:35ZMartin ReineckeWIP: More derivativesJust adding this merge request to simplify looking at diffs and have a place for discussion.
@pfrank, @parras, @reimar, @kjakoJust adding this merge request to simplify looking at diffs and have a place for discussion.
@pfrank, @parras, @reimar, @kjakohttps://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/353WIP: Mf new2019-10-29T15:46:44ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Mf newhttps://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/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/7WIP: Issue/4/add axis to dto rebased2016-05-02T10:52:21ZGhost UserWIP: Issue/4/add axis to dto rebasedTheo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/178WIP: Issue173 wiener filter demos2017-11-29T12:48:42ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Issue173 wiener filter demosHier mein Vorschlag für die beiden WienerFilter demos.
Was haltet ihr davon, wenn wir das wf_via_curvature durch ein 1D-Beispiel mit Rekonstruktion im Ortsraum ersetzen? Das wäre dann noch einfacher für den Einstieg. Da hätte ich auch w...Hier mein Vorschlag für die beiden WienerFilter demos.
Was haltet ihr davon, wenn wir das wf_via_curvature durch ein 1D-Beispiel mit Rekonstruktion im Ortsraum ersetzen? Das wäre dann noch einfacher für den Einstieg. Da hätte ich auch was da.
Cheers
Philipphttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/26WIP: initial smooth operator2016-09-24T13:02:22ZTheo SteiningerWIP: initial smooth operatorTheo SteiningerTheo Steiningerhttps://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/168WIP: Fixing wiener filter demo2017-08-02T21:13:16ZJakob KnollmuellerWIP: Fixing wiener filter demoI added some distribution_strategies in wiener_filter_via_hamiltonian.py, the WienerFilterEnergy now also uses the given inverter and distribution_strategies are now set in InvertibleOperatorMixin if no x0 is givenI added some distribution_strategies in wiener_filter_via_hamiltonian.py, the WienerFilterEnergy now also uses the given inverter and distribution_strategies are now set in InvertibleOperatorMixin if no x0 is given