NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2020-05-10T19:18:53Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/457Fix makeOp2020-05-10T19:18:53ZMartin ReineckeFix makeOphttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/456Add consistency check to jacobian tests2020-05-13T11:34:28ZPhilipp Arrasparras@mpa-garching.mpg.deAdd consistency check to jacobian testsMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/455Fix a bug where studentt would only work if theta is a scalar2020-05-01T09:27:09ZReimar H LeikeFix a bug where studentt would only work if theta is a scalarMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/454no more default dtype for draw_sample()2020-04-27T09:40:59ZMartin Reineckeno more default dtype for draw_sample()Open questions:
- why don't we pass on the `dtype` in `sampling_enabler.py`, line 72?
- in `calculate_position` in `sugar.py` we don't have a `dtype` available; do we need to introduce one?
@parras, @pfrank, @kjako, @reimarOpen questions:
- why don't we pass on the `dtype` in `sampling_enabler.py`, line 72?
- in `calculate_position` in `sugar.py` we don't have a `dtype` available; do we need to introduce one?
@parras, @pfrank, @kjako, @reimarhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/453Fix mpi kl2020-04-22T14:14:52ZPhilipp Arrasparras@mpa-garching.mpg.deFix mpi klhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/452Add basic mpi kl tests2020-04-19T08:00:35ZPhilipp Arrasparras@mpa-garching.mpg.deAdd basic mpi kl testsMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/451Flip fft and ifft2020-05-13T11:23:05ZMartin ReineckeFlip fft and iffthttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/450Attempt fix for GenLeibnizTensor2020-04-17T07:12:20ZPhilipp FrankAttempt fix for GenLeibnizTensorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/449Rename demos in order to get people to look at the ipynb first2020-04-17T08:55:20ZPhilipp Arrasparras@mpa-garching.mpg.deRename demos in order to get people to look at the ipynb firstMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/448ComposedTensor of arbitrary order2020-04-14T06:43:45ZPhilipp FrankComposedTensor of arbitrary orderGeneralization of `ComposedTensor` to arbitrary n-th order derivatives.Generalization of `ComposedTensor` to arbitrary n-th order derivatives.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/447more derivatives mr2020-04-12T13:02:25ZPhilipp Frankmore derivatives mrPhilipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/445Add multi field support for find_position2020-04-18T15:38:02ZPhilipp Arrasparras@mpa-garching.mpg.deAdd multi field support for find_positionMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/443Switch spaces operator2020-04-16T14:12:19ZLukas PlatzSwitch spaces operatorOperator to permute the domain entries of a field in pairs.Operator to permute the domain entries of a field in pairs.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/442added norm keyword argument for healpix plots2020-04-07T17:18:25ZReimar H Leikeadded norm keyword argument for healpix plotsMartin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/441MF Plotting: plot MF fields with arbitray domain order2020-04-06T06:21:52ZLukas PlatzMF Plotting: plot MF fields with arbitray domain orderCurrently, the plotting routine only accepts MF-fields if the frequency axis is the last axis.
Remove this arbitrary restriction, add `freq_space_idx` keyword to `plot.add()`.Currently, the plotting routine only accepts MF-fields if the frequency axis is the last axis.
Remove this arbitrary restriction, add `freq_space_idx` keyword to `plot.add()`.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/438fix and stricter tests2020-04-01T16:01:21ZMartin Reineckefix and stricter testshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/437Even more elegant random numbers?2020-04-01T14:43:47ZMartin ReineckeEven more elegant random numbers?Having to manually `push` and `pop` SeedSequences to the internal stack of the `random` module promises to be a bit error-prone, because it's easy to forget the `pop` operation.
What do you think about using a context manager like I'm d...Having to manually `push` and `pop` SeedSequences to the internal stack of the `random` module promises to be a bit error-prone, because it's easy to forget the `pop` operation.
What do you think about using a context manager like I'm demonstrating in a few cases in `test_random.py`?
If you like it, I'll use the new construct in all places where it's appropriate.
@parras, @gedenhofhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/436improve docstrings2020-04-01T10:21:11ZMartin Reineckeimprove docstringshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/435allow reading and restoring the state of the random module2020-04-01T09:55:45ZMartin Reineckeallow reading and restoring the state of the random modulehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/434Operator tree optimiser2020-05-20T09:00:26ZRouven LemmerzOperator tree optimiserIn order to prevent operators from calculating the same fields multiple times, one can set variables and input these into the operator tree.
The variables are set via a `FieldAdapter`. This has been used in !417.
An operator tree takes ...In order to prevent operators from calculating the same fields multiple times, one can set variables and input these into the operator tree.
The variables are set via a `FieldAdapter`. This has been used in !417.
An operator tree takes as an input a Field and outputs a Field. Cutting out equal subtrees and using their output as the new input for the pruned operator tree is one way to achieve more performance. This is done by `optimize_subtrees`.
There are some more improvements one has to make: `_OpChain` operators make the tree very complex and they have to be unpacked.
In `op2(op1) + op1` the first Summand has to be checked for whether it contains parts of the second Summand.
`optimize_node` does this, while `optimize_all_nodes` traverses the tree and applies it to (usually, see Problem 1) every node.
Some Problems:
1. Currently only searching for nodes at the end of operator chains, but
`optimize_all_nodes( (op + op)(op + op) )`
can happen
2. Subtrees are only replaced at node points, but one should also compare the vertices above and replace it
3. Only comparing by ids is done, one might add a cache to prevent same operators from going unnoticed (similar to the `DomainTuple` cache
4. `op = optimize_subtrees(optimize_all_nodes(op))` generates better results than
`op = optimize_all_nodes(optimize_subtrees(op))`.
As of now I'm unsure in how far changing the way the operator trees are stored could be improved to make this optimisation easier and/or faster.
@mtr @gedenhof