ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-01-11T13:30:42Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/196What does Field.vdot() do if the spaces keyword is present?2018-01-11T13:30:42ZMartin ReineckeWhat does Field.vdot() do if the spaces keyword is present?What is the expected result if we call
`a.vdot(b,spaces=0)`
where a is a Field living on one space and b is a Field living on two spaces?
I'm asking because the documentation says that the result should be float or complex, but the co...What is the expected result if we call
`a.vdot(b,spaces=0)`
where a is a Field living on one space and b is a Field living on two spaces?
I'm asking because the documentation says that the result should be float or complex, but the code actually returns a Field object.
Is there an undocumented constraint that both Fields must have the same number of domains?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/197Error found by dimensional analysis2018-01-26T14:55:37ZMartin ReineckeError found by dimensional analysisThe test case below was distilled from `wiener_filter_via_curvature.py` by Torsten and me.
It indicates that there is a unit error in the way we compute the mock signal.
```
import numpy as np
import nifty as ift
import numericalunits a...The test case below was distilled from `wiener_filter_via_curvature.py` by Torsten and me.
It indicates that there is a unit error in the way we compute the mock signal.
```
import numpy as np
import nifty as ift
import numericalunits as nu
np.random.seed(43)
correlation_length = 0.05*nu.m
field_sigma = 2.* nu.K
response_sigma = 0.01*nu.m
# stupid power spectrum, but we only care about units now
def power_spectrum(k):
a = 4 * correlation_length * field_sigma**2
return a / (1 + k * correlation_length) ** 4
# Total side-length of the domain
L = 2.*nu.m
# Grid resolution (pixels per axis)
N_pixels = 512
signal_space = ift.RGSpace([N_pixels], distances=L/N_pixels)
harmonic_space = ift.FFTOperator.get_default_codomain(signal_space)
fft = ift.FFTOperator(harmonic_space, target=signal_space)
power_space = ift.PowerSpace(harmonic_space)
mock_power = ift.Field(power_space, val=power_spectrum(power_space.kindex))
mock_harmonic = mock_power.power_synthesize(real_signal=True)
mock_signal = fft(mock_harmonic)
print "signal mean (measured in K):", mock_signal.mean()/nu.K
print "signal mean (measured in K/sqrt(m)): ", mock_signal.mean()*np.sqrt(nu.m)/nu.K
```
If this code is run several times (I tested with the `nightly` branch), the first printed number changes, but the second one does not, which means that the unit for the mock_signal field is actually sqrt(m)/K, which is not the intended one.
My guess is that we either have a dimensional error in `power_spectrum()` or in `Field.power_synthesize()`.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/99Tests: Energy class2018-01-30T20:40:21ZTheo SteiningerTests: Energy classhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/97Tests: Operators2018-01-18T15:55:29ZTheo SteiningerTests: Operatorshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/96Tests: Field class2018-01-19T08:55:09ZTheo SteiningerTests: Field class2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/93Docstring: Probing2018-02-14T15:13:33ZTheo SteiningerDocstring: Probinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/91Docstring: NIFTy config & logging2018-01-19T08:54:57ZTheo SteiningerDocstring: NIFTy config & logging2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/85Docstring: NIFTy2018-02-21T21:15:54ZTheo SteiningerDocstring: NIFTyhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/198Design problem in InvertibleOperatorMixin2018-01-26T15:02:39ZMartin ReineckeDesign problem in InvertibleOperatorMixinThe constructor for `InvertibleOperatorMixin` currently allows specifying iteration starting values via `forward_x0` and `backward_x0`. This is problematic for several reasons:
- these vectors have to live over the full domain of a late...The constructor for `InvertibleOperatorMixin` currently allows specifying iteration starting values via `forward_x0` and `backward_x0`. This is problematic for several reasons:
- these vectors have to live over the full domain of a later operator application call, and thereby restrict the general applicability of the operator which is one of Nifty's current design goals.
- `forward_x0` is used in `times()` and `adjoint_inverse_times()` although it is most likely not a good guess for at least one of both. Analogously for `backward_x0`.
- A starting guess is directly coupled to a concrete argument for which the operator is invoked; it is not a property of the operator, but of the operator/argument combination. So if one sets up an `InvertibleOperatorMixin` using the currently available tools, it will only work well for a single specific field.
I would much prefer being able to supply a starting guess with every `times()` (or `adjoint_times()` etc.) call; I'm thinking about a clean approach for this. Suggestions are welcome!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/199Fairly urgent: decide on convention for diagonal in DiagonalOperator2017-11-16T10:02:14ZMartin ReineckeFairly urgent: decide on convention for diagonal in DiagonalOperatorRecently I removed the last remaining uses of the `bare` keyword in some methods of `DiagonalOperator`, and this change has now been merged into the `nightly` branch. The code now behaves as if `bare=False`, which was the default before....Recently I removed the last remaining uses of the `bare` keyword in some methods of `DiagonalOperator`, and this change has now been merged into the `nightly` branch. The code now behaves as if `bare=False`, which was the default before.
However Torsten argues that it would be more natural to behave as if `bare=True`.
Both is fine with me, but we need to decide very quickly, because the first people have started adapting to `nightly` and will be unhappy if they have to change their codes again!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/65Profile Field.dot2018-01-19T08:55:37ZTheo SteiningerProfile Field.dotField.dot uses the DiagonalOperator in order to do dot products that only affect certain spaces of the partner. Maybe the fields are unnecessarily copied -> profiling is needed to ensure efficiency.Field.dot uses the DiagonalOperator in order to do dot products that only affect certain spaces of the partner. Maybe the fields are unnecessarily copied -> profiling is needed to ensure efficiency.Theo SteiningerTheo Steininger2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/64Add poisson statistics to Field class2018-01-18T16:01:29ZTheo SteiningerAdd poisson statistics to Field classLambda must be field valued.Lambda must be field valued.https://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/nifty/-/issues/38Enable nifty_fft classes to operate on global NIFTy MPI communicator2018-01-12T09:21:39ZTheo SteiningerEnable nifty_fft classes to operate on global NIFTy MPI communicatorRelated to Issue #37 Related to Issue #37 Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/32Matplotlib backend hardcoded in __init__.py2018-01-18T15:57:29ZButler, David (dbutler)Matplotlib backend hardcoded in __init__.pyThe backend selection for matplotlib is hardcoded in '__init__.py". The chosen backend 'Agg' only functions when printing to a file, it does not allow launching plot windows directly from the terminal.
Selecting a different backend via ...The backend selection for matplotlib is hardcoded in '__init__.py". The chosen backend 'Agg' only functions when printing to a file, it does not allow launching plot windows directly from the terminal.
Selecting a different backend via 'use' must be done before importing NIFTy and may instead break file outputs.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/27Implement clean preconditioning for sqrt-able precondidioners in conjugate gr...2018-01-18T15:58:56ZTheo SteiningerImplement clean preconditioning for sqrt-able precondidioners in conjugate gradientS^(-1/2) (1+ S^(1/2) M S^(1/2)) S^(-1/2)S^(-1/2) (1+ S^(1/2) M S^(1/2)) S^(-1/2)Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/9Add "S_inv" keyword to propagator_operator2018-01-18T15:57:53ZTorsten EnsslinAdd "S_inv" keyword to propagator_operatorIf S_inv is set to an inverse operator, it should be use instead of S.inverse_multiply/times in
D^-1 = S_inv + M
Usecase: Sometimes only a non-invertable smoothness enforcing operator S_inv \propto k^2 or k^4 should be used, or an ...If S_inv is set to an inverse operator, it should be use instead of S.inverse_multiply/times in
D^-1 = S_inv + M
Usecase: Sometimes only a non-invertable smoothness enforcing operator S_inv \propto k^2 or k^4 should be used, or an explicitly coded pixel space operator. 2018-01-19https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/200Make generate_posterior_sample() an attribute of WienerFilterCurvature?2018-02-06T09:34:51ZMartin ReineckeMake generate_posterior_sample() an attribute of WienerFilterCurvature?The method `generate_posterior_sample()` in `sugar.py` requires its second argument to be of type `WienerFilterCurvature` and is quite dependent on `WienerFilterCurvature`'s internal design (e.g. that it has members called S, R and N and...The method `generate_posterior_sample()` in `sugar.py` requires its second argument to be of type `WienerFilterCurvature` and is quite dependent on `WienerFilterCurvature`'s internal design (e.g. that it has members called S, R and N and what their exact types are).
I think it might be cleaner to move ths method into the class.
@kjako, @theos, what is your opinion?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/201Add preconditioning to all our minimizers?2018-01-26T15:01:10ZMartin ReineckeAdd preconditioning to all our minimizers?As far as I understand, it should be possible to speed up all our minimization algorithms (not ony ConjugateGradient) by using an adequate preconditioner if available.
Unfortunately this is not discussed in the Nocedal&Wright book, unle...As far as I understand, it should be possible to speed up all our minimization algorithms (not ony ConjugateGradient) by using an adequate preconditioner if available.
Unfortunately this is not discussed in the Nocedal&Wright book, unless I have missed something. So I'm looking for implementation hints.
@theos, @kjako, @reimar, any tips, links to papers etc. ?Martin ReineckeMartin Reineckehttps://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?