ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2019-02-01T08:36:45Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/226Minimizers don't work reliably on nonlinear problems2019-02-01T08:36:45ZMartin ReineckeMinimizers don't work reliably on nonlinear problemsWe are seeing quite a lot of strange problems in our minimizations, typically when nonlinearities are involved.
So far I have not found any real bugs in our minimizers, so my suspicion is that we have to add constraints to our fields of unknowns, to prevent them wandering into regions where energy values are too high, gradients too small etc. Our current attempts to clip the nonlinearities or to manually reset the positions whenever they move out of the accepted area do not work well, so I suggest trying algorithms like SciPy's 'L-BFGS-B', 'COBYLA', etc., which have native support for constraints.
If that turns out to work well, we can try to add constraints also to our own solvers.We are seeing quite a lot of strange problems in our minimizations, typically when nonlinearities are involved.
So far I have not found any real bugs in our minimizers, so my suspicion is that we have to add constraints to our fields of unknowns, to prevent them wandering into regions where energy values are too high, gradients too small etc. Our current attempts to clip the nonlinearities or to manually reset the positions whenever they move out of the accepted area do not work well, so I suggest trying algorithms like SciPy's 'L-BFGS-B', 'COBYLA', etc., which have native support for constraints.
If that turns out to work well, we can try to add constraints also to our own solvers.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/227Renaming 'structured' and 'unstructered' domains.2018-04-06T11:24:55ZTheo SteiningerRenaming 'structured' and 'unstructered' domains.In my opinion the wording of 'structured' and 'unstructured' domains is misleading. The 'unstructured' domains can have plenty of structure, too, e.g. a vector-field. Mathematically, 'structured' domains are manifolds and 'unstructured' domains are fibers/Fasern that are defined on top of the product of all manifolds. Together, everything forms a fiber-bundle.
See, for reference:
https://en.wikipedia.org/wiki/Fiber_bundleIn my opinion the wording of 'structured' and 'unstructured' domains is misleading. The 'unstructured' domains can have plenty of structure, too, e.g. a vector-field. Mathematically, 'structured' domains are manifolds and 'unstructured' domains are fibers/Fasern that are defined on top of the product of all manifolds. Together, everything forms a fiber-bundle.
See, for reference:
https://en.wikipedia.org/wiki/Fiber_bundle2018-04-04https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/228diagonal Operator with zeros2018-03-13T12:41:15ZReimar H Leikediagonal Operator with zerosCurrently the DiagonalOperator always has the capability of inverse_times. However, this is only legal if there are no zeros on the diagonal. One should either document that a non-zero diagonal is expected or change the properties of the operator dependent on the input.Currently the DiagonalOperator always has the capability of inverse_times. However, this is only legal if there are no zeros on the diagonal. One should either document that a non-zero diagonal is expected or change the properties of the operator dependent on the input.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/229Allow redirection of NIFTy's console output2018-03-14T18:56:03ZMartin ReineckeAllow redirection of NIFTy's console outputNIFTy still prints to the console occasionally (via the dobj.mprint() method). It should be possible to redirect this output to arbitrary file handles (or /dev/null) on user request.NIFTy still prints to the console occasionally (via the dobj.mprint() method). It should be possible to redirect this output to arbitrary file handles (or /dev/null) on user request.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/230Generalized DOFDistributor2018-03-23T15:45:22ZMartin ReineckeGeneralized DOFDistributorIf we extend the `DOFDistributor` to allow for an optional set of weights, it becomes much more powerful.
For example, such an enhanced `DOFDistributor` can be used to describe a line-of-sight response, so we don't need a dedicated operator for this any more.
(The complicated task of computing the appropriate mappings and weights does not go away of course, but it is now separated from the distribution operation itself, which is good.)
@ensslint, @kjako, @reimar, @pfrank, @parras, would this be a way to go forward?If we extend the `DOFDistributor` to allow for an optional set of weights, it becomes much more powerful.
For example, such an enhanced `DOFDistributor` can be used to describe a line-of-sight response, so we don't need a dedicated operator for this any more.
(The complicated task of computing the appropriate mappings and weights does not go away of course, but it is now separated from the distribution operation itself, which is good.)
@ensslint, @kjako, @reimar, @pfrank, @parras, would this be a way to go forward?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/231draw_sample() definition2018-03-28T13:42:23ZChristoph Lienharddraw_sample() definitionthe `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probability distribution with said curvature (i.e. exp(-0.5 x^+ Cx) ), in the case of a `DiagonalOperator` D it seems to use the distribution wrt the inverse of it (i.e. exp(-0.5 x^+ D^-1 x) )
I propose changing the latter to match the former for consistency.
The curvature definition is more likely to be the one that someone actually wants (at least for the curvature case. For the diagonal operator case one could start arguing, but ... consistency!). Also the `draw_sample` function for the `DiagonalOperator` class is not that hard to change.the `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probability distribution with said curvature (i.e. exp(-0.5 x^+ Cx) ), in the case of a `DiagonalOperator` D it seems to use the distribution wrt the inverse of it (i.e. exp(-0.5 x^+ D^-1 x) )
I propose changing the latter to match the former for consistency.
The curvature definition is more likely to be the one that someone actually wants (at least for the curvature case. For the diagonal operator case one could start arguing, but ... consistency!). Also the `draw_sample` function for the `DiagonalOperator` class is not that hard to change.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/232Random seed in extra/tests2018-04-26T15:01:09ZPhilipp Arrasparras@mpa-garching.mpg.deRandom seed in extra/testsIf one calls tests like `nifty4.extra.consistency_check(op)` the random seed afterwards is different. Would it be sensible to reset the numpy random seed?If one calls tests like `nifty4.extra.consistency_check(op)` the random seed afterwards is different. Would it be sensible to reset the numpy random seed?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/233Incorrect Energy.curvature() call in minimizers/conjugate_gradient.py?2018-04-20T13:47:34ZLukas PlatzIncorrect Energy.curvature() call in minimizers/conjugate_gradient.py?In [minimization/conjugate_gradient.py, line 76](https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/NIFTy_4/nifty4/minimization/conjugate_gradient.py#L76) there is a call to 'energy.curvature(d)'.
However all energies defined in NIFTy only have argument-less curvature methods.
Still, the ConjugateGradient Class is usable without error messages. What am I missing?In [minimization/conjugate_gradient.py, line 76](https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/NIFTy_4/nifty4/minimization/conjugate_gradient.py#L76) there is a call to 'energy.curvature(d)'.
However all energies defined in NIFTy only have argument-less curvature methods.
Still, the ConjugateGradient Class is usable without error messages. What am I missing?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/234Documentation for our volume factor approach?2018-06-27T15:54:46ZMartin ReineckeDocumentation for our volume factor approach?Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible to add something to our documentation?Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible to add something to our documentation?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/236try except in InverseEnabler.draw_sample2018-05-02T08:01:18ZChristoph Lienhardtry except in InverseEnabler.draw_samplejust catching every error in the `draw_sample` function of the `InversionEnabler` class might shadow 'real' errors.
IMO only `ValueError`s should be excepted.
(just had a problem and only got the 'cannot draw from inverse of this operator', which is weird, if the InversionEnabler is on. Also I was not drawing from the inverse.
The reason was, that the `try` clause caught a completely different error jumped into `except` where it tried to draw a sample from the inverse of said operator, which was not implemented for that operator)just catching every error in the `draw_sample` function of the `InversionEnabler` class might shadow 'real' errors.
IMO only `ValueError`s should be excepted.
(just had a problem and only got the 'cannot draw from inverse of this operator', which is weird, if the InversionEnabler is on. Also I was not drawing from the inverse.
The reason was, that the `try` clause caught a completely different error jumped into `except` where it tried to draw a sample from the inverse of said operator, which was not implemented for that operator)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/237Comparing Fields to floats2018-05-16T10:08:38ZPhilipp Arrasparras@mpa-garching.mpg.deComparing Fields to floatsIs the following behaviour intended?
```
import nifty4 as ift
f = ift.Field.full(ift.RGSpace(1), 1.)
if f == 0.:
print(f==0.)
```
Results in:
```
nifty4.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(1,), distances=(1.0,), harmonic=False)
- val = array([False])
```Is the following behaviour intended?
```
import nifty4 as ift
f = ift.Field.full(ift.RGSpace(1), 1.)
if f == 0.:
print(f==0.)
```
Results in:
```
nifty4.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(1,), distances=(1.0,), harmonic=False)
- val = array([False])
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/238extra.check_value_gradient_consistency does not work for MultiField2018-05-23T09:22:38ZJakob Knollmuellerextra.check_value_gradient_consistency does not work for MultiFieldextra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead introduce something like domain.random(random_type)? Alternatively one has to include checks for MultiField or regular Field.
Jakobextra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead introduce something like domain.random(random_type)? Alternatively one has to include checks for MultiField or regular Field.
Jakobhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/239Branch cleanup2018-05-23T12:36:47ZMartin ReineckeBranch cleanupI'd like to cleanup the branches which are no longer used. Could you please give me feedback which ones of your branches are still needed?
@reimar: easy_samples
Another question: should we merge the `working_on_demos` branch?I'd like to cleanup the branches which are no longer used. Could you please give me feedback which ones of your branches are still needed?
@reimar: easy_samples
Another question: should we merge the `working_on_demos` branch?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/240Drawing random fields in multi domains2018-05-23T10:15:45ZPhilipp Arrasparras@mpa-garching.mpg.deDrawing random fields in multi domainsThe following command breaks:
```
ift.Field.from_random("normal", ift.MultiDomain.make({'a': ift.RGSpace(1)}))
```
How can I fix that? Or is it not implemented yet?The following command breaks:
```
ift.Field.from_random("normal", ift.MultiDomain.make({'a': ift.RGSpace(1)}))
```
How can I fix that? Or is it not implemented yet?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/241SmoothnessOperator ill-posedness2019-02-01T08:30:45ZSebastian KehlSmoothnessOperator ill-posednessVisualizing nifty's SmoothnessOperator [smoothingoperator.pdf](/uploads/34b3a1a3e4326d00dc2695b100224f9f/smoothingoperator.pdf) over some PowerSpace, I was wondering whether having no penalty on the highest frequency entry (indicated by the empty last row and column in the attached picture) is the desired behavior?
I understand that this might be desired for the zero mode (and maybe the next one too) since the data should be informative enough to render the overall problem well-posed. But for the highest frequency mode, I would expect heavy problems in optimization from leaving this degree-of-freedom basically free.Visualizing nifty's SmoothnessOperator [smoothingoperator.pdf](/uploads/34b3a1a3e4326d00dc2695b100224f9f/smoothingoperator.pdf) over some PowerSpace, I was wondering whether having no penalty on the highest frequency entry (indicated by the empty last row and column in the attached picture) is the desired behavior?
I understand that this might be desired for the zero mode (and maybe the next one too) since the data should be informative enough to render the overall problem well-posed. But for the highest frequency mode, I would expect heavy problems in optimization from leaving this degree-of-freedom basically free.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/242Sandwich does not like Field buns2018-05-29T12:35:17ZJakob KnollmuellerSandwich does not like Field bunsHi,
The SandwichOperator does not accept Fields as bun, as they do not have an .adjoint method. I propose either to allow Fields and cast them to Diagonal operators or to check for them in the init.Hi,
The SandwichOperator does not accept Fields as bun, as they do not have an .adjoint method. I propose either to allow Fields and cast them to Diagonal operators or to check for them in the init.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/243feature request: fun with multi2018-06-15T05:40:25ZReimar H Leikefeature request: fun with multiMultifields and operators do not yet support some of the convenience functionality present for normal fields and operators. For example a MultiField that is multiplied with a BlockDiagonalOperator is not automatically converted to a Diagonal Operator the way it is done for fields. Minimal example attached.
[multi_issue.py](/uploads/f634d63059005da5f20731d673373e8c/multi_issue.py)Multifields and operators do not yet support some of the convenience functionality present for normal fields and operators. For example a MultiField that is multiplied with a BlockDiagonalOperator is not automatically converted to a Diagonal Operator the way it is done for fields. Minimal example attached.
[multi_issue.py](/uploads/f634d63059005da5f20731d673373e8c/multi_issue.py)Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/244Update to NIFTy_52018-06-27T15:54:39ZPhilipp Arrasparras@mpa-garching.mpg.deUpdate to NIFTy_5- [x] Create NIFTy fork (@mtr @parras)
- [ ] Move KL and poisson demo from GlobalNewton to NIFTy fork. (@parras)
- [x] Revert documentation to NIFTy4 (@parras)
Use `Model` for constructing the following energies (@mtr, @jruestig, @reimar, @pfrank):
- [ ] `GaussianLH`, `PoissonianLH` (new curvature)
- [ ] `NoiseModel`
- [ ] `make_correlated_field` (move from GlobalNewton)
- [ ] `make_amplitude_model` (move from GlobalNewton)
- [ ] `make_multifrequency_correlated_field` / `separable_correlations`(move from GlobalNewton and adopt)
To this end one probably needs to implement a Gaussian and a Poissonian likelihood which is to be used in all energies (see GlobalNewton repository). Please add documentation directly.
Documentation:
- [ ] Documentation on volume factors (see also #234, @reimar, @maxn).
- [ ] Add Models (@hutsch) and MultiFields (@mtr ) to top-level documentation.
- [ ] `__add__` and ` __sub__` of `Energy` (@mtr)
- [ ] `Constant` (@jruestig, @clienhar)
- [ ] `LocalModel` (@jruestig, @clienhar)
- [ ] `Model` (@jruestig, @clienhar)
- [ ] `Add` in models (@jruestig, @clienhar)
- [ ] `ScalarMul` (@jruestig, @clienhar)
- [ ] `LinearModel` (@jruestig, @clienhar)
- [ ] `Variable` (@jruestig, @clienhar)
- [ ] `ModelGradientOperator` (@clienhar)
- [ ] `SamplingEnabler` (@kjako)
- [ ] `SelectionOperator` (@lplatz)
Tests:
- [ ] Consistency checks for all linear operators (see `ift.extra`!). (@lplatz, @silvan, @mawandro)
- [ ] Gradient consistency checks for all energies in library (see `ift.extra`, do that when the energies are rewritten). (@lplatz, @silvan, @mawandro)
- [ ] Unit tests for all new functionality, especially for models. (@parras, @jruestig)
- [ ] Write `ift.extra.model_consistency_check` and check every model with it (@reimar, @silvan)
Demos:
- [X] Fix `demos/poisson_demo.py` or move poisson demo from GlobalNewton here.
- [X] Think about concept for demos. Which ones? How universal? Which features? MAP solution for multi-problems until Jakob's paper is out?
- [ ] Write demos (first `demo/advanced.py`, then `getting_started_123`, 1: R=mask, WF, 2: R=mask, PoissonLogNormal, 3: R=LOS, PosTanh, Gauss, AmplitudeReconstruction). Start when energies are ready. (@kjako, @natalia)
Internals:
- [ ] Add something like a `CurvatureInversionEnabler` class, which takes an `Energy`, an `IterationController` and (optionally) a preconditioner and adds invertability to the energy's curvature operator. Having such a class would probably allow for some code reductions in many energy classes. (This is now tracked as issue #246). (@mtr)
- [x] Move classes out of `model.py` except `Model`.
- [ ] Revert automatical casting of `Field` to `Model`. (@parras)
- [ ] Rewrite `__add__` of `Energy` such that no trees are created (@mtr).
To be discussed:
- [X] Automatically cast `Field` to `Model` when multiplied with a `Model`?- [x] Create NIFTy fork (@mtr @parras)
- [ ] Move KL and poisson demo from GlobalNewton to NIFTy fork. (@parras)
- [x] Revert documentation to NIFTy4 (@parras)
Use `Model` for constructing the following energies (@mtr, @jruestig, @reimar, @pfrank):
- [ ] `GaussianLH`, `PoissonianLH` (new curvature)
- [ ] `NoiseModel`
- [ ] `make_correlated_field` (move from GlobalNewton)
- [ ] `make_amplitude_model` (move from GlobalNewton)
- [ ] `make_multifrequency_correlated_field` / `separable_correlations`(move from GlobalNewton and adopt)
To this end one probably needs to implement a Gaussian and a Poissonian likelihood which is to be used in all energies (see GlobalNewton repository). Please add documentation directly.
Documentation:
- [ ] Documentation on volume factors (see also #234, @reimar, @maxn).
- [ ] Add Models (@hutsch) and MultiFields (@mtr ) to top-level documentation.
- [ ] `__add__` and ` __sub__` of `Energy` (@mtr)
- [ ] `Constant` (@jruestig, @clienhar)
- [ ] `LocalModel` (@jruestig, @clienhar)
- [ ] `Model` (@jruestig, @clienhar)
- [ ] `Add` in models (@jruestig, @clienhar)
- [ ] `ScalarMul` (@jruestig, @clienhar)
- [ ] `LinearModel` (@jruestig, @clienhar)
- [ ] `Variable` (@jruestig, @clienhar)
- [ ] `ModelGradientOperator` (@clienhar)
- [ ] `SamplingEnabler` (@kjako)
- [ ] `SelectionOperator` (@lplatz)
Tests:
- [ ] Consistency checks for all linear operators (see `ift.extra`!). (@lplatz, @silvan, @mawandro)
- [ ] Gradient consistency checks for all energies in library (see `ift.extra`, do that when the energies are rewritten). (@lplatz, @silvan, @mawandro)
- [ ] Unit tests for all new functionality, especially for models. (@parras, @jruestig)
- [ ] Write `ift.extra.model_consistency_check` and check every model with it (@reimar, @silvan)
Demos:
- [X] Fix `demos/poisson_demo.py` or move poisson demo from GlobalNewton here.
- [X] Think about concept for demos. Which ones? How universal? Which features? MAP solution for multi-problems until Jakob's paper is out?
- [ ] Write demos (first `demo/advanced.py`, then `getting_started_123`, 1: R=mask, WF, 2: R=mask, PoissonLogNormal, 3: R=LOS, PosTanh, Gauss, AmplitudeReconstruction). Start when energies are ready. (@kjako, @natalia)
Internals:
- [ ] Add something like a `CurvatureInversionEnabler` class, which takes an `Energy`, an `IterationController` and (optionally) a preconditioner and adds invertability to the energy's curvature operator. Having such a class would probably allow for some code reductions in many energy classes. (This is now tracked as issue #246). (@mtr)
- [x] Move classes out of `model.py` except `Model`.
- [ ] Revert automatical casting of `Field` to `Model`. (@parras)
- [ ] Rewrite `__add__` of `Energy` such that no trees are created (@mtr).
To be discussed:
- [X] Automatically cast `Field` to `Model` when multiplied with a `Model`?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/245dtypes in UnitLogGauss2018-06-27T15:55:19ZPhilipp Arrasparras@mpa-garching.mpg.dedtypes in UnitLogGauss```
import numpy as np
import nifty5 as ift
space = ift.RGSpace(2)
f = ift.from_random('normal', space)
var_f = ift.Variable(f)
g = ift.from_random('normal', space, dtype=np.complex)
var_g = ift.Variable(g)
multi = ift.MultiField({'f': f, 'g': g})
var = ift.Variable(multi)
op = ift.ScalingOperator(1j, space)
op_multi = ift.ScalingOperator(1j, var.value.domain)
lh_f = ift.library.UnitLogGauss(op(var_f))
lh_g = ift.library.UnitLogGauss(op(var_g))
lh = ift.library.UnitLogGauss(op_multi(var))
print(lh_f.value)
print(lh_f.gradient)
print()
print(lh_g.value)
print(lh_g.gradient)
print()
print(lh.value)
print(lh.gradient['f'])
print(lh.gradient['g'])
```
Results in:
```
2.230929182659062
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
0.30445727594179295
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
2.535386458600855
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
```
I would expect that the gradient has the same `dtype` as the input.```
import numpy as np
import nifty5 as ift
space = ift.RGSpace(2)
f = ift.from_random('normal', space)
var_f = ift.Variable(f)
g = ift.from_random('normal', space, dtype=np.complex)
var_g = ift.Variable(g)
multi = ift.MultiField({'f': f, 'g': g})
var = ift.Variable(multi)
op = ift.ScalingOperator(1j, space)
op_multi = ift.ScalingOperator(1j, var.value.domain)
lh_f = ift.library.UnitLogGauss(op(var_f))
lh_g = ift.library.UnitLogGauss(op(var_g))
lh = ift.library.UnitLogGauss(op_multi(var))
print(lh_f.value)
print(lh_f.gradient)
print()
print(lh_g.value)
print(lh_g.gradient)
print()
print(lh.value)
print(lh.gradient['f'])
print(lh.gradient['g'])
```
Results in:
```
2.230929182659062
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
0.30445727594179295
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
2.535386458600855
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
```
I would expect that the gradient has the same `dtype` as the input.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/246Slight re-design of the `Energy` class2018-06-27T20:37:45ZMartin ReineckeSlight re-design of the `Energy` classCurrently, most energy classes take constructor arguments which allow their curvatures to be inverted. This only makes sense as long as we are not working very much with sums of energies. In this latter case, it doesn't matter if the individual curvatures are invertible or not, we just need to make sure that the summed-up curvature is invertible.
I'd like to propose the following changes:
- All inversion-related functionality is removed from the energy classes we currently have
- the `Energy` base class gets a new method `make_curvature_invertible()`, which takes an `IterationController` and optionally another `Energy` that serves as a preconditioner (we need an `Energy` here and not simply a `LinearOperator`, since the preconditioning might depend on position). This method returns a new `Energy` object, with invertible curvature.
- we add a new class `SamplingEnabledEnergy`, whose constructor takes two energies `prior` and `likelihood` and an `IterationController`. It returns an energy object that behaves like the sum of prior and likelihood, and returns a sampling-enabled curvature.Currently, most energy classes take constructor arguments which allow their curvatures to be inverted. This only makes sense as long as we are not working very much with sums of energies. In this latter case, it doesn't matter if the individual curvatures are invertible or not, we just need to make sure that the summed-up curvature is invertible.
I'd like to propose the following changes:
- All inversion-related functionality is removed from the energy classes we currently have
- the `Energy` base class gets a new method `make_curvature_invertible()`, which takes an `IterationController` and optionally another `Energy` that serves as a preconditioner (we need an `Energy` here and not simply a `LinearOperator`, since the preconditioning might depend on position). This method returns a new `Energy` object, with invertible curvature.
- we add a new class `SamplingEnabledEnergy`, whose constructor takes two energies `prior` and `likelihood` and an `IterationController`. It returns an energy object that behaves like the sum of prior and likelihood, and returns a sampling-enabled curvature.