ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2020-05-22T09:26:39Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/303Jacobian consistency check broken for CorrelatedField with N > 12020-05-22T09:26:39ZPhilipp Arrasparras@mpa-garching.mpg.deJacobian consistency check broken for CorrelatedField with N > 1If the return statement here
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/test/test_operators/test_correlated_fields.py#L92
is removed, the jacobian tests fail for the individual amplitudes and the whole model.If the return statement here
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_6/test/test_operators/test_correlated_fields.py#L92
is removed, the jacobian tests fail for the individual amplitudes and the whole model.Philipp HaimPhilipp Haimhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/302Invalid call to inverse2020-06-24T15:04:05ZGordian EdenhoferInvalid call to inverseWhy is nifty calling `.inverse` of an operator that definitely does not support it?
```ipython
In [40]: n2f_jac
Out[40]:
ChainOperator:
DiagonalOperator
OuterProduct
In [41]: n2f_jac.domain
Out[41]:
DomainTuple:
HPSpace(nside=16)
...Why is nifty calling `.inverse` of an operator that definitely does not support it?
```ipython
In [40]: n2f_jac
Out[40]:
ChainOperator:
DiagonalOperator
OuterProduct
In [41]: n2f_jac.domain
Out[41]:
DomainTuple:
HPSpace(nside=16)
In [42]: n2f_jac.target
Out[42]:
DomainTuple:
UnstructuredDomain(shape=(30,))
HPSpace(nside=16)
In [43]: n2f_jac.capability
Out[43]: 3
In [44]: ift.extra.consistency_check(n2f_jac)
~/Projects/nifty/nifty6/extra.py in consistency_check(op, domain_dtype, target_dtype, atol, rtol, only_r_linear)
201 _actual_domain_check_linear(op, domain_dtype)
202 _actual_domain_check_linear(op.adjoint, target_dtype)
--> 203 _actual_domain_check_linear(op.inverse, target_dtype)
~/Projects/nifty/nifty6/operators/linear_operator.py in inverse(self)
86 Returns a LinearOperator object which behaves as if it were
87 the inverse of this operator."""
---> 88 return self._flip_modes(self.INVERSE_BIT)
~/Projects/nifty/nifty6/operators/chain_operator.py in _flip_modes(self, trafo)
123 if trafo == ADJ or trafo == INV:
124 return self.make(
--> 125 [op._flip_modes(trafo) for op in reversed(self._ops)])
~/Projects/nifty/nifty6/operators/chain_operator.py in <listcomp>(.0)
123 if trafo == ADJ or trafo == INV:
124 return self.make(
--> 125 [op._flip_modes(trafo) for op in reversed(self._ops)])
~/Projects/nifty/nifty6/operators/diagonal_operator.py in _flip_modes(self, trafo)
149 if trafo & self.INVERSE_BIT:
--> 150 xdiag = 1./xdiag # This operator contains zeros zeros on one axis
FloatingPointError: divide by zero encountered in true_divide
In [45]: n2f_jac(r).val
Out[45]:
array([[ 2.87943447e-02, 2.84809183e-02, 2.86276722e-02, ...,
2.85864172e-02, 2.88285874e-02, 2.88791209e-02],
...,
[ 0.00000000e+00, 1.46037080e-16, 0.00000000e+00, ...,
1.43154658e-16, -1.34704751e-16, 0.00000000e+00], # zero except for numerical fluctuations
[ 3.18092631e-02, 3.11583354e-02, 3.14395536e-02, ...,
3.13576202e-02, 3.18985295e-02, 3.20487145e-02]])
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/301Broken GaussianEnergy2020-05-19T16:19:40ZGordian EdenhoferBroken GaussianEnergySampling with a Gaussian energy and no mean was broken in one of the recent merge request.
Applying the following path
```patch
diff --git a/demos/getting_started_3.py b/demos/getting_started_3.py
index 2dcffa17..c053e0a0 100644
--- a/...Sampling with a Gaussian energy and no mean was broken in one of the recent merge request.
Applying the following path
```patch
diff --git a/demos/getting_started_3.py b/demos/getting_started_3.py
index 2dcffa17..c053e0a0 100644
--- a/demos/getting_started_3.py
+++ b/demos/getting_started_3.py
@@ -109,8 +109,7 @@ if __name__ == '__main__':
minimizer = ift.NewtonCG(ic_newton)
# Set up likelihood and information Hamiltonian
- likelihood = (ift.GaussianEnergy(mean=data, inverse_covariance=N.inverse) @
- signal_response)
+ likelihood = ift.GaussianEnergy(inverse_covariance=N.inverse) @ ift.Adder(data, neg=True) @ signal_response
H = ift.StandardHamiltonian(likelihood, ic_sampling)
initial_mean = ift.MultiField.full(H.domain, 0.)
```
results in the demo failing though it actually should do the exact same thing as before.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/300Streamline arguments position2020-05-19T13:05:11ZGordian EdenhoferStreamline arguments positionSwitch positional arguments to get a consistent order of e.g. `domain` within the positional arguments of all operators.
Affected operators are:
* `ift.from_random`
* `ift.OuterProduct`
@lerou You said that you are keeping a list of op...Switch positional arguments to get a consistent order of e.g. `domain` within the positional arguments of all operators.
Affected operators are:
* `ift.from_random`
* `ift.OuterProduct`
@lerou You said that you are keeping a list of operators that annoy you by their inconsistency. Can you amend the list with such cases please?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/298Tests are taking too long2020-05-19T08:02:40ZMartin ReineckeTests are taking too longOn my laptop, the Nifty regression test are taking almost 10 minutes at the moment, which starts to get really problematic during development. Is there a chance of reducing test sizes and/or avoiding redundancies in the current tests?
T...On my laptop, the Nifty regression test are taking almost 10 minutes at the moment, which starts to get really problematic during development. Is there a chance of reducing test sizes and/or avoiding redundancies in the current tests?
The biggest problem by far is test_correlated_fields.py, which accounts for roughly 40% of the testing time. Next is test_jacobian.py with 20%; next is test_energy_gradients.py.
@parras, @pfrank, @phaimhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/297Really obsolete Nifty docs are still online2020-05-14T06:58:53ZMartin ReineckeReally obsolete Nifty docs are still onlineI searched online for "nifty documentation" today, and the second hit was
https://wwwmpa.mpa-garching.mpg.de/ift/nifty/start.html
Can we please remove these completely obsolete files from the public internet? Our potential users might b...I searched online for "nifty documentation" today, and the second hit was
https://wwwmpa.mpa-garching.mpg.de/ift/nifty/start.html
Can we please remove these completely obsolete files from the public internet? Our potential users might be grateful :)Torsten EnsslinTorsten Ensslinhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/295Suggestion: Add dtype property to DomainTuple2020-04-26T15:24:18ZPhilipp Arrasparras@mpa-garching.mpg.deSuggestion: Add dtype property to DomainTupleI suggest to add a property called `dtype` to `DomainTuple`. When wrapping a numpy array as `Field` the constructor would check that the dtype of the array and the `DomainTuple` coincide. Functions like `from_random` do not need to take ...I suggest to add a property called `dtype` to `DomainTuple`. When wrapping a numpy array as `Field` the constructor would check that the dtype of the array and the `DomainTuple` coincide. Functions like `from_random` do not need to take a dtype any more. In particular, sampling from e.g. `DiagonalOperator`s become unambiguous in terms of drawing either a real or a complex field. This in turn would simplify the KL because the `lh_sampling_dtype` would disappear.
I am not 100% sure how to treat `RGSpace.get_default_codomain()`. Would the default codomain of a real space be real again or complex? My suggestion is to add an optional argument to that function and take as default the same dtype as the original space.
Also I am not sure how to tell the `DomainTuple` its dtype. I suggest as an additional argument of `DomainTuple.make()`.
What do you think about that, @mtr @pfrank @reimar?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/293[GU] Simplify point-wise Field operations2020-04-14T06:46:41ZMartin Reinecke[GU] Simplify point-wise Field operationsCurrently, point-wise operations on Nifty objects are not really implemented in a beautiful way: they are injected via some nasty Python tricks into `Field`, `MultiField`, `Operator` and the `sugar` module, and a slightly more complicate...Currently, point-wise operations on Nifty objects are not really implemented in a beautiful way: they are injected via some nasty Python tricks into `Field`, `MultiField`, `Operator` and the `sugar` module, and a slightly more complicated variant is added to `Linearization`.
My plan is to have a single method in `Field`, `MultiField`, `Linearization` and `Operator`, which is called `ptw` (or `pointwise`), which takes a string describing the requested pointwise operation (like "sin", "exp", "one_over" etc.). Implementation of the actual operations would be fairly trivial via a dictionary mapping these names to their `numpy` equivalents, and also describing their derivatives via `numpy` or custom functions where necessary.
If we like, we can leave the global pointwise functions injected into `sugar.py` unchanged for aesthetic reasons :)
Opinions?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/292Many Linearization methods explicitly expect Fields2020-04-03T07:53:56ZMartin ReineckeMany Linearization methods explicitly expect FieldsWhile working on Field/MultiField unification, I noticed that the largest part of `Linearization` members do not accept `MultiFields`; a clear example is `sinc`, which explicitly creates a `Field` for its output, but many other methods b...While working on Field/MultiField unification, I noticed that the largest part of `Linearization` members do not accept `MultiFields`; a clear example is `sinc`, which explicitly creates a `Field` for its output, but many other methods break in more obscure ways.
If we want unification, we need all `Linearization` methods to work on `Multifields`, which is quite a bit of tedious work. Any volunteers?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/291Problematic MultiField methods2021-03-24T09:26:17ZMartin ReineckeProblematic MultiField methodsCurrently, `MultiField` has methods like `s_sum`, `clip`, and many transcendental functions. I'm wondering whether they make any sense: what's the point of computing the sum over all values in several fields ... or computing the sine of ...Currently, `MultiField` has methods like `s_sum`, `clip`, and many transcendental functions. I'm wondering whether they make any sense: what's the point of computing the sum over all values in several fields ... or computing the sine of all field entries?
We currently use `MultiField`'s `norm` property in minimization, but given that the components of the `MultiField` may have vastly different scales, is this actually a clever thing to do? This basically means that we stop minimizing once the field component with the largest values has converged ... not necessarily what we want.
@parras, @pfrank, @reimar, @kjakohttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/289Overflows after updating NIFTy2020-03-27T14:50:45ZPhilipp Arrasparras@mpa-garching.mpg.deOverflows after updating NIFTyWhen updating to the new interpolation scheme (https://gitlab.mpcdf.mpg.de/ift/nifty/commit/37a5691e3013ca36303ee4c3e78c74485f516793), I get overflows in the minimization where I did not get any before. I am confused since the both gradi...When updating to the new interpolation scheme (https://gitlab.mpcdf.mpg.de/ift/nifty/commit/37a5691e3013ca36303ee4c3e78c74485f516793), I get overflows in the minimization where I did not get any before. I am confused since the both gradient tests work better than before and the accuracy of the approximation is better. Maybe the operator works better now so that actually an inconsistency in my model is triggered or so. I have the feeling that it is not the operator's fault... ;)
@gedenhof can you share your observations about the overflows? If it is the same commit as for me, then I will go ahead and try to assemble a minimal demonstration case but I think this might be a lot of work so maybe we can find the problem without that.
@gedenhof, @lerouhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/288Make convergence tests less fragile2020-03-22T13:06:44ZMartin ReineckeMake convergence tests less fragileThe switch to `numpy`'s new RNG interface has shown that some of our convergence and consistency tests are not very robust: in principle these tests should succeed for any random seed we use during the problem setup, but this is apparent...The switch to `numpy`'s new RNG interface has shown that some of our convergence and consistency tests are not very robust: in principle these tests should succeed for any random seed we use during the problem setup, but this is apparently not the case. We should have a closer look at the problematic tests and fix them accordingly.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/287Switch to new random interface of numpy2020-03-24T11:25:13ZPhilipp Arrasparras@mpa-garching.mpg.deSwitch to new random interface of numpy`np.random.seed` is legacy. The numpy docs say:
> The best practice is to **not** reseed a BitGenerator, rather to recreate a new one. This method is here for legacy reasons.
> This example demonstrates best practice.
```python
from nu...`np.random.seed` is legacy. The numpy docs say:
> The best practice is to **not** reseed a BitGenerator, rather to recreate a new one. This method is here for legacy reasons.
> This example demonstrates best practice.
```python
from numpy.random import MT19937
from numpy.random import RandomState, SeedSequence
rs = RandomState(MT19937(SeedSequence(123456789)))
# Later, you want to restart the stream
rs = RandomState(MT19937(SeedSequence(987654321)))
```
We might want to migrate eventually.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/286NIFTy grand unification: unify MultiFields and Fields2020-04-07T17:33:33ZMartin ReineckeNIFTy grand unification: unify MultiFields and Fields- all new fields have the internal structure of a MultiField
- a classic "standard" field is represented by a new field with a single key
that is the empty string
- Many of our operators work on part of a DomainTuple (e.g. FFTOperator)...- all new fields have the internal structure of a MultiField
- a classic "standard" field is represented by a new field with a single key
that is the empty string
- Many of our operators work on part of a DomainTuple (e.g. FFTOperator).
Typically this is specified by passing the domain and additionally a "spaces"
argument, which is None, int of tupe of ints.
Since in the future every domain is a "multi-domain", this is no longer
sufficient: the partial domain must now contain an additional string defining
the name of the required field component. This requires an update
(and renaming) of "parse_spaces", "infer_space" etc.
Maybe it's good to introduce a new "PartialDomain" class which contains
* a string containing the desired field component, and
* an integer tuple containing the desired subspaces of that component
- "MultiField" will be renamed to "Field"; "Field" will probably be renamed
to some internal helper class or completely implemented within the new "Field".
- "MultiDomain" will be renamed to ???; "DomainTuple" will probably become
"_DomainTuple", i.e. it should not be directly accessed by external users.
- "makeField" and "makeDomain" become static "make" members of "Field" and
"Domain"Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/285Performance of Operator Jacobians2020-03-10T10:32:22ZReimar H LeikePerformance of Operator JacobiansMany of our operators call the Jacobian of Linearizations more than once, leading to exponential performance losses in chains of operators, as uncovered by the test_for_performance_issues branch.
TODOS:
- [x] extend the tests to not o...Many of our operators call the Jacobian of Linearizations more than once, leading to exponential performance losses in chains of operators, as uncovered by the test_for_performance_issues branch.
TODOS:
- [x] extend the tests to not only cover energy operators
- [x] fix all uncovered performance issueshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/284Inconsistency of .sum() for Fields and Linearizations2020-03-11T23:04:51ZPhilipp Arrasparras@mpa-garching.mpg.deInconsistency of .sum() for Fields and LinearizationsIs it wanted that `Linearization.sum()` returns a scalar Field but `Field.sum()` returns an actual scalar, i.e. in most situations a `float`? `MultiField.sum()` inherits the behaviour from `Field`.
Linearizations: https://gitlab.mpcdf.m...Is it wanted that `Linearization.sum()` returns a scalar Field but `Field.sum()` returns an actual scalar, i.e. in most situations a `float`? `MultiField.sum()` inherits the behaviour from `Field`.
Linearizations: https://gitlab.mpcdf.mpg.de/ift/nifty/blob/NIFTy_6/nifty6/linearization.py#L237
Fields: https://gitlab.mpcdf.mpg.de/ift/nifty/blob/NIFTy_6/nifty6/field.py#L382
MultiFields: https://gitlab.mpcdf.mpg.de/ift/nifty/blob/NIFTy_6/nifty6/multi_field.py#L169https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/282FieldZeroPadder2020-02-19T16:45:27ZVincent EberleFieldZeroPadderFieldZeropadding.adjoint doesn't work in 2 dimensions.FieldZeropadding.adjoint doesn't work in 2 dimensions.Philipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/281[NIFTy6] Boost performance of Correlated Fields2019-12-06T13:53:49ZPhilipp Arrasparras@mpa-garching.mpg.de[NIFTy6] Boost performance of Correlated FieldsDo PowerDistributor only on one slice and copy it with ContractionOperator.adjoint afterwards. The power distributor appears to be the bottleneck of correlated field evaluations currently.Do PowerDistributor only on one slice and copy it with ContractionOperator.adjoint afterwards. The power distributor appears to be the bottleneck of correlated field evaluations currently.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/280[NIFTy6] Implement partial insert operator for multi fields2019-12-06T16:54:00ZPhilipp Arrasparras@mpa-garching.mpg.de[NIFTy6] Implement partial insert operator for multi fieldshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/279Consistent ordering of domain and non-domain arguments for standard operators2019-12-06T08:34:31ZGordian EdenhoferConsistent ordering of domain and non-domain arguments for standard operatorsCurrently, the order in which arguments shall be provided differs between operators, e.g. `ift.from_global_data` and `ift.full` both take the domain as first argument, while `ift.ScalingOperator` requires the factor with which to scale a...Currently, the order in which arguments shall be provided differs between operators, e.g. `ift.from_global_data` and `ift.full` both take the domain as first argument, while `ift.ScalingOperator` requires the factor with which to scale a field as first argument and the domain as second. Moving to NIFTY6 might be the perfect opportunity to fix this either by consistently requiring the domain to be e.g. the first argument or by making the `ift.ScalingOperator` more flexible by swapping arguments in a suitable manner during initialization.