ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-04-02T09:42:38Zhttps://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?https://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/24Missing file in last commit?2018-03-18T10:55:45ZMartin ReineckeMissing file in last commit?Is it possible that you forgot to add a file `random.py` in your last commit?
As things are, D2O now imports Python's default `random` module, but this probably doesn't address the problems with MPI-parallel seeding you mentioned.Is it possible that you forgot to add a file `random.py` in your last commit?
As things are, D2O now imports Python's default `random` module, but this probably doesn't address the problems with MPI-parallel seeding you mentioned.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/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...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/202On nifty2go branch: Domain of signal fields2018-03-13T08:56:15ZPhilipp Arrasparras@mpa-garching.mpg.deOn nifty2go branch: Domain of signal fieldsI think there is an inconsistency in the current nifty2go branch. The WienerFilter and CriticalFilter classes assume the signal field to live in harmonic space whereas the Nonlinear* classes assume it to be in signal space.
What is the ...I think there is an inconsistency in the current nifty2go branch. The WienerFilter and CriticalFilter classes assume the signal field to live in harmonic space whereas the Nonlinear* classes assume it to be in signal space.
What is the reason for having implemented WienerFilterEnergy and Curvature this way? How do we resolve this inconsistency?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/217Parallelism in `probe_with_posterior_samples`2018-03-01T22:50:58ZPhilipp Arrasparras@mpa-garching.mpg.deParallelism in `probe_with_posterior_samples`Can we draw these samples in parallel? @pfrank, could you perhaps contribute your implementation here?Can we draw these samples in parallel? @pfrank, could you perhaps contribute your implementation here?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/224Add kwargs to plotting2018-03-01T20:29:55ZPhilipp Arrasparras@mpa-garching.mpg.deAdd kwargs to plottingCan we add `linewidth` and `alpha` to the kwargs supported by 1d-plotting routines? If so, I can do it.
Are there perhaps additional kwargs you guys need?Can we add `linewidth` and `alpha` to the kwargs supported by 1d-plotting routines? If so, I can do it.
Are there perhaps additional kwargs you guys need?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/225broken link in Readme2018-02-22T13:00:52ZSilvan Streitbroken link in ReadmeThe link to the informal introduction in https://gitlab.mpcdf.mpg.de/ift/NIFTy#first-steps is broken.The link to the informal introduction in https://gitlab.mpcdf.mpg.de/ift/NIFTy#first-steps is broken.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/222Bug in LaplaceOperator2018-02-21T21:21:01ZMartin ReineckeBug in LaplaceOperatorThe current version of `LaplaceOperator` has a bug that causes the input field to be modified whenever its `adjoint_times()` method is called.
The fix is trivial and will be applied in a few minutes.
@kjako, @reimar, @parras, @pfrank, @...The current version of `LaplaceOperator` has a bug that causes the input field to be modified whenever its `adjoint_times()` method is called.
The fix is trivial and will be applied in a few minutes.
@kjako, @reimar, @parras, @pfrank, @dpumpe, please check if this maybe fixes any mysterious problems you have encountered!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/177Documentation for FFTSmoothingOperator and DirectSmoothingOperator missing2018-02-21T21:18:52ZPhilipp Arrasparras@mpa-garching.mpg.deDocumentation for FFTSmoothingOperator and DirectSmoothingOperator missinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/85Docstring: NIFTy2018-02-21T21:15:54ZTheo SteiningerDocstring: NIFTyhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/215More generic posterior sampling2018-02-21T21:13:02ZMartin ReineckeMore generic posterior samplingIt was mentioned that the machinery for drawing posterior samples should be made more general, and should not only be available for `WienerFilterCurvature`.
I'd be happy to implement this, but I need a clear description of the required ...It was mentioned that the machinery for drawing posterior samples should be made more general, and should not only be available for `WienerFilterCurvature`.
I'd be happy to implement this, but I need a clear description of the required ingredients and the algorithm.
Concerning this functionality, there are currently several open questions:
- issue #211
- issue #200
- NIFTy4 currently has two implementations: `generate_posterior_sample()` and `generate_posterior_sample2()`, both in `nifty4/library/wiener_filter_curvature.py`. Which is the correct one?
@kjako, @reimar, @parras: please let's get together and sort this out soon!