NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2016-09-24T13:04:51Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/13WIP: Feature/field multiple space2016-09-24T13:04:51ZGhost UserWIP: Feature/field multiple spaceWIP, cast functions, and others still need sorting out.WIP, cast functions, and others still need sorting out.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/528WIP: `FieldZeroPadder`: enable padding at the start of the array2021-03-24T11:15:05ZLukas PlatzWIP: `FieldZeroPadder`: enable padding at the start of the arrayThe `FieldZeroPadder` was able to pad either in the center of the field arrays or at the end.
Added the option to also pad at the start of field arrays.The `FieldZeroPadder` was able to pad either in the center of the field arrays or at the end.
Added the option to also pad at the start of field arrays.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/322WIP: Fix aspect setting in 2D plots2019-05-03T16:14:11ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Fix aspect setting in 2D plotshttps://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 givenhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/287WIP: Fix linearization getitem2019-02-05T13:56:38ZReimar H LeikeWIP: Fix linearization getitemProblems in Linearization are not fixed yet, as the ducktape operator will yield a domain missmatch when __getitem__ is called. I wanted to reproduce that with a minimal example but it failed due to yet another bug which is described in ...Problems in Linearization are not fixed yet, as the ducktape operator will yield a domain missmatch when __getitem__ is called. I wanted to reproduce that with a minimal example but it failed due to yet another bug which is described in #259 .Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/651WIP: Generalized matrix product and a fix in endomorphic MatrixProductOperator2021-08-16T17:53:00ZNeel ShahWIP: Generalized matrix product and a fix in endomorphic MatrixProductOperatorI added a linear matrix multiplication operator that generalizes the endomorphic MatrixProductOperator. The output matches that of the endomorphic operator in case of an endomorphic application.
The target domain/domain tuple of the val...I added a linear matrix multiplication operator that generalizes the endomorphic MatrixProductOperator. The output matches that of the endomorphic operator in case of an endomorphic application.
The target domain/domain tuple of the valid shape should be specified by the user, but I kept a standard RGSpace of the valid shape as the default.\
Below is an example of an application.
dtuple = DomainTuple.make(((RGSpace(10),RGSpace(20),RGSpace(30),RGSpace(40)))\
spaces = (1,3) (apply only to 2nd and 4th spaces of domain)\
matrix = np.ones(shape=(5,15,25,20,40))\
matop = GeneralMatrixProduct(dtuple,matrix,spaces,target=None)
According to the operator's convention,\
target_shape = (10,5,30,15,25)\
(since dtuple.shape = (10,20,30,40), the 20,40 axes are summed over, and to comply with the endomorphic MatrixProductOperator the 10,30 axes retain their positions and remaining axes of the matrix are filled in order)\
matop.target = DomainTuple.make(RGSpace(shape = target_shape, distances = default, harmonic = False))\
(unless a domain or DomainTuple with shape = target_shape is passed as the target)\
returns Field.from_raw(matop.target, np,tensordot of matrix and field summed over appropriate axes)
I tested the operator's working on the example above, and that it coincides with the endomorphic MatrixProductOperator when the latter is applicable. Would this be a useful operator, and what else in it can be tested or changed?
The second change is in the endomorphic MatrixProductOperator, I fixed its functionality for application to a >1 dimensional domain (say an RGSpace(shape=(5,15,25))). The previous version uses np.dot instead of np.tensordot, so due to default axis convention in np.dot it doesn't work when more than one axes are to be summed over. I don't think this was intentional because the operator doesn't throw an error until it is applied to a field over such a domain.
There is one last change in the docstring of the matrix product operator. It has a line saying `If DomainTuple it is assumed to have only one entry`, which I think is misleading because I can apply it to a domain tuple with many subspaces like the example above. I changed the line to `If Domain it is assumed to have only one subspace`, which is what I observed.
@gedenhof , can you have a look at this?https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/444WIP: [GU] Demonstrate new class hierarchy2020-04-09T11:38:12ZMartin ReineckeWIP: [GU] Demonstrate new class hierarchyhttps://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/26WIP: initial smooth operator2016-09-24T13:02:22ZTheo SteiningerWIP: initial smooth operatorTheo 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/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/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/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/353WIP: Mf new2019-10-29T15:46:44ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Mf newhttps://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/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/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/518WIP: More restrictive scaling operator2020-06-05T08:36:57ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: More restrictive scaling operator