ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-05-02T08:01:18Zhttps://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 opera...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/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...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/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' ...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_bundle2018-04-04https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/34Add fft_machine keyword to the rg_space.copy()2018-04-02T09:42:38ZTheo SteiningerAdd fft_machine keyword to the rg_space.copy()https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/43field.smooth on rg_space produces non-sensible results on multiple spaces2018-04-02T09:42:38ZTheo Steiningerfield.smooth on rg_space produces non-sensible results on multiple spaces from nifty import *
x = rg_space((8,))
f = field((x,x), val=1)
f.val[3] = 10
f.smooth(spaces=0, sigma=0.0001).val
The result of the last operation does not make sense, as the columns are
<distributed_da... from nifty import *
x = rg_space((8,))
f = field((x,x), val=1)
f.val[3] = 10
f.smooth(spaces=0, sigma=0.0001).val
The result of the last operation does not make sense, as the columns are
<distributed_data_object>
array([ 1.00000104, 0.99999867, 1.00000355, 5.49999423, 1.00000607,
5.49999423, 1.00000355, 0.99999867])
instead of
<distributed_data_object>
array([ 1.00000104, 0.99999822, 1.00000607, 9.99999023, 1.00000607,
0.99999822, 1.00000104, 0.99999911])
https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/45Possibly invert Fourier-transformation responsibilities2018-04-02T09:42:38ZTheo SteiningerPossibly invert Fourier-transformation responsibilitiesRight now, the domain-space computes the data for the codomain-space. The field then uses this data together with the new data. For the spherical spaces this produces strange if-else blocks in the calc_transform methods.
It would be ...Right now, the domain-space computes the data for the codomain-space. The field then uses this data together with the new data. For the spherical spaces this produces strange if-else blocks in the calc_transform methods.
It would be clearer when the codomain-space computed its data directly: e.g. lm_space then has two sub-methods: transform_from_hp and transform_from_glhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/49Move `check_codomain` in Transformation to child classes2018-04-02T09:42:38ZTheo SteiningerMove `check_codomain` in Transformation to child classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/50Use gdi(gc[fft_module]) in RGRGTransformation.__init__2018-04-02T09:42:38ZTheo SteiningerUse gdi(gc[fft_module]) in RGRGTransformation.__init__https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/52Merge Transform and Transformation classes2018-04-02T09:42:38ZTheo SteiningerMerge Transform and Transformation classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/53Add check_codomain cache to Transformation Classes2018-04-02T09:42:38ZTheo SteiningerAdd check_codomain cache to Transformation Classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/54Move get_codomain from space to Transformator classes2018-04-02T09:42:38ZTheo SteiningerMove get_codomain from space to Transformator classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/61Unreachable code in _local_transform in rg_transforms.py?2018-04-02T09:42:38ZTheo SteiningerUnreachable code in _local_transform in rg_transforms.py? In rg_transform.py in _local_transform the following check is made:
if axes is None or 0 in axes:
local_offset_Q = val.distributor.local_shape[0] % 2
Since _local_transform is only called `if not ( axes is None or 0 ... In rg_transform.py in _local_transform the following check is made:
if axes is None or 0 in axes:
local_offset_Q = val.distributor.local_shape[0] % 2
Since _local_transform is only called `if not ( axes is None or 0 in axes)` (see line 424 in rg_transform.py) this line of code is rever reached. https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/62FFTOperator fails for zerocenter=True spaces.2018-04-02T09:42:38ZDixit, Jait (jaitd)FFTOperator fails for zerocenter=True spaces.Both scenarios fail:
```
from nifty import *
x = RGSpace((16,), zerocenter=True)
f = Field((x,x), val=1)
fft = FFTOperator(x)
fft(f, spaces=(1,))
```
```
from nifty import *
x = RGSpace((16,), zerocenter=True)
f = Field((x,), val=1)
fft ...Both scenarios fail:
```
from nifty import *
x = RGSpace((16,), zerocenter=True)
f = Field((x,x), val=1)
fft = FFTOperator(x)
fft(f, spaces=(1,))
```
```
from nifty import *
x = RGSpace((16,), zerocenter=True)
f = Field((x,), val=1)
fft = FFTOperator(x)
fft(f)
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/151Potential name confusion for Field.dot()2018-04-02T09:42:38ZMartin ReineckePotential name confusion for Field.dot()I just noticed the hard way that the behaviour of Field.dot() and numpy.dot() is subtly different ...
While Field.dot() takes the complex conjugate of its second argument, numpy.dot() doesn't; the correct numpy function to call would be...I just noticed the hard way that the behaviour of Field.dot() and numpy.dot() is subtly different ...
While Field.dot() takes the complex conjugate of its second argument, numpy.dot() doesn't; the correct numpy function to call would be numpy.vdot().
The question is whether we should rename Field.dot() to Field.vdot() for the sake of consistency with numpy. Otherwise we might risk confusing people with numpy background.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 probab...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/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 opera...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/207Meaning of Field methods mean(), var() and std() is unclear2018-03-23T08:24:14ZMartin ReineckeMeaning of Field methods mean(), var() and std() is unclearAre we sure that the `Field` reduction methods `mean()`, `var()` and `std()` are doing what we expect from them?
Currently, `mean()` computes a straightforward average over all entries, without taking volume factors into account. Is thi...Are we sure that the `Field` reduction methods `mean()`, `var()` and `std()` are doing what we expect from them?
Currently, `mean()` computes a straightforward average over all entries, without taking volume factors into account. Is this what we want? For `GLSpace`s, the result may not be the desired one.
@theos, @kjako, @dpumpe, @reimar: what are the official/intended semantics?Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/63Extend functionality of `Field.from_random`2018-03-22T13:13:33ZTheo SteiningerExtend functionality of `Field.from_random`1. Add poisson statistics
2. Allow for fields as variable inputs (mean, std, lambda, etc...)1. Add poisson statistics
2. Allow for fields as variable inputs (mean, std, lambda, etc...)Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/25Meta-issue: how to deal with open D2O issues?2018-03-20T14:57:13ZMartin ReineckeMeta-issue: how to deal with open D2O issues?@theos, @ensslint:
There are currently 22 open issues in D2O, and I don't expect that Theo will have the time to work on them. Unfortunately, no one else has the necessary knowledge.
Any suggestions how to proceed here?@theos, @ensslint:
There are currently 22 open issues in D2O, and I don't expect that Theo will have the time to work on them. Unfortunately, no one else has the necessary knowledge.
Any suggestions how to proceed here?