NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2020-04-17T07:12:20Zhttps://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/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/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/444WIP: [GU] Demonstrate new class hierarchy2020-04-09T11:38:12ZMartin ReineckeWIP: [GU] Demonstrate new class hierarchyhttps://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/440Rework of pointwise operations2020-04-11T06:47:55ZMartin ReineckeRework of pointwise operationsMartin ReineckeMartin Reineckehttps://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/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 @gedenhofhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/433Extend MatrixProductOperator to be able to operate on subdomains of fields2020-04-01T08:53:41ZLukas PlatzExtend MatrixProductOperator to be able to operate on subdomains of fieldsNeeded in my mf analysis, for example.Needed in my mf analysis, for example.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/432Use a generator for MetricGaussianKL.samples2020-03-26T09:05:03ZMartin ReineckeUse a generator for MetricGaussianKL.samples@gedenhof what do you think? Please feel free to improve this.@gedenhof what do you think? Please feel free to improve this.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/431metric_gaussian_kl.py: Fix samples property2020-03-25T14:41:05ZGordian 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 a list can
not be added to a tuple in python.Fix a bug which was introduced in eded7903fb making it impossible to
access the sample property of a KL with mirrored samples as a list can
not be added to a tuple in python.