ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2021-09-24T08:03:42Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/337Possible error in assert_equal and assert_allclose for MultiFields2021-09-24T08:03:42ZPhilipp FrankPossible error in assert_equal and assert_allclose for MultiFieldsIn their current form, both methods `assert_equal` and `assert_allclose` only perform a one sided test for `MultiFields`. This leads to some unexpected behaviour when comparing two Fields which are only equal one some sub-domain. In particular the following test
```
import nifty8 as ift
d = ift.RGSpace(10)
d = ift.MultiDomain.make({'a' : d, 'b' : d})
f = ift.from_random(d)
fp = f.extract_by_keys(['a',])
ift.extra.assert_equal(fp, f)
```
will pass, but
```
ift.extra.assert_equal(f, fp)
```
produces an error, as only the keys of the first input are looped over. The same goes for `assert_allclose`.
This does not look like an intended behaviour to me. @mtr, @parras, am I missing something here?In their current form, both methods `assert_equal` and `assert_allclose` only perform a one sided test for `MultiFields`. This leads to some unexpected behaviour when comparing two Fields which are only equal one some sub-domain. In particular the following test
```
import nifty8 as ift
d = ift.RGSpace(10)
d = ift.MultiDomain.make({'a' : d, 'b' : d})
f = ift.from_random(d)
fp = f.extract_by_keys(['a',])
ift.extra.assert_equal(fp, f)
```
will pass, but
```
ift.extra.assert_equal(f, fp)
```
produces an error, as only the keys of the first input are looped over. The same goes for `assert_allclose`.
This does not look like an intended behaviour to me. @mtr, @parras, am I missing something here?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/336Sampling dtypes in sandwich operators2021-09-22T08:26:46ZPhilipp Arrasparras@mpa-garching.mpg.deSampling dtypes in sandwich operatorsI think (but I am not sure), that it is relatively important to fix the FIXME that @pfrank has put here:
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_8/src/operators/sandwich_operator.py#L77I think (but I am not sure), that it is relatively important to fix the FIXME that @pfrank has put here:
https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_8/src/operators/sandwich_operator.py#L77https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/335CorrelatedFieldMaker amplitude normalization breaks fluctuation amplitude2021-08-24T10:52:00ZLukas PlatzCorrelatedFieldMaker amplitude normalization breaks fluctuation amplitudeIf one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?If one adds more than one amplitude operator to a `CorrelatedFieldMaker` and sets a very small/large offset standard deviation, the field fluctuation amplitude gets distorted.
This is because in `get_normalized_amplitudes()` every amplitude operator gets devided by `self.azm` and the results of this function are then multiplied with an outer product to create the joint amplitude operator.
In CFs with more than one amplitude operator, this results in the joint amplitude operator being divided by multiples of the zeromode operator and thus an incorrect output scaling behavior.
To demonstrate this effect, I created correlated field operators for identical 2d fields, but one with a single amplitude operator for `ift.RGSpace((N, N)` and one with two amplitude operators on `ift.RGSpace(N)`. From top to bottom, I varied the `offset std` setting passed to `set_amplitude_total_offset()` and in each case plotted a histogram of the sampled fields' standard deviation.
![output](/uploads/6779601e231148c36a77a91aa8e7fd62/bug.png)
One can clearly see the output fluctuation amplitude is independant from the `offset_std` for the 'single' case, as it should be, but not for the 'dual' case.
A fix for this is proposed in merge requests !669 and !670.
To reproduce, run the following code:
```
import nifty7 as ift
import matplotlib.pyplot as plt
fluct_pars = {
'fluctuations': (1.0, 0.1),
'flexibility': None,
'asperity': None,
'loglogavgslope': (-2.0, 0.2),
'prefix': 'flucts_',
'dofdex': None
}
n_offsets = 5
n_samples = 1000
dom_single = ift.RGSpace((25, 25))
dom_dual = ift.RGSpace(25)
fig, axs = plt.subplots(nrows=n_offsets, ncols=2, figsize=(12, 4 * n_offsets))
for i in range(n_offsets):
cfmaker_single = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_dual = ift.CorrelatedFieldMaker(prefix='str(i)_')
cfmaker_single.add_fluctuations(dom_single, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
cfmaker_dual.add_fluctuations(dom_dual, **fluct_pars)
offset_std = 10 ** -i
zm_pars = {'offset_mean': 0.,
'offset_std': (offset_std, offset_std / 10.)}
cfmaker_single.set_amplitude_total_offset(**zm_pars)
cfmaker_dual.set_amplitude_total_offset(**zm_pars)
cf_single = cfmaker_single.finalize(prior_info=0)
cf_dual = cfmaker_dual.finalize(prior_info=0)
samples_single = [cf_single(ift.from_random(cf_single.domain)).val.std() for _ in range(n_samples)]
samples_dual = [cf_dual(ift.from_random(cf_dual.domain)).val.std() for _ in range(n_samples)]
_ = axs[i, 0].hist(samples_single, bins=20, density=True)
_ = axs[i, 1].hist(samples_dual, bins=20, density=True)
axs[i, 0].set_title(f'offset_std = {offset_std:1.0e}, single')
axs[i, 1].set_title(f'offset_std = {offset_std:1.0e}, dual')
axs[i, 0].set_xlabel('sample std')
axs[i, 1].set_xlabel('sample std')
plt.tight_layout()
plt.show()
```
Any comments?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/333New feature: Add flag to minisanity that disables terminal colors2021-08-05T12:39:13ZPhilipp Arrasparras@mpa-garching.mpg.deNew feature: Add flag to minisanity that disables terminal colorsPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/334`MetricGaussianKL` changed its interface (there is not `.make`) but there is ...2021-07-01T15:34:54ZGordian Edenhofer`MetricGaussianKL` changed its interface (there is not `.make`) but there is no corresponding changelog entryhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/323Final steps for release2021-06-11T19:59:51ZPhilipp Arrasparras@mpa-garching.mpg.deFinal steps for release- [x] Check documentation generation for warnings and errors -> !636
- [x] Check pytest output for warnings -> #329 + !635, !634
- [x] Run `isort` on whole repository
```sh
find . -type f -name '*.py' | xargs isort
```
- [x] Update author list again
```sh
git shortlog -s origin/NIFTy_6..origin/NIFTy_7 | cut -f2-
```
- [x] Fast-forward `NIFTy_8` to `origin/NIFTy_7` branch
- [x] Rename nifty7 -> nifty8 on NIFTy_8 branch
```sh
rm nifty7
ln -s src nifty8
find . -type f -exec sed -i 's/nifty7/nifty8/g' {} \;
find . -type f -exec sed -i 's/NIFTy_7/NIFTy_8/g' {} \;
find . -type f -exec sed -i 's/NIFTy7/NIFTy8/g' {} \; # Only partially!
```
- [x] Rename NIFTy_6 -> NIFTy_7 in `.gitlab-ci.yml` (for doc generation)
- [x] NIFTy_8 subsection in `README.md` in contributors section
- [x] NIFTy_7 section in `ChangeLog.md`
- [x] Make NIFTy_7 the default branch of the gitlab repository
- [x] Add daily pipeline schedule for `NIFTy_8` branch and remove the one for `NIFTy_6`- [x] Check documentation generation for warnings and errors -> !636
- [x] Check pytest output for warnings -> #329 + !635, !634
- [x] Run `isort` on whole repository
```sh
find . -type f -name '*.py' | xargs isort
```
- [x] Update author list again
```sh
git shortlog -s origin/NIFTy_6..origin/NIFTy_7 | cut -f2-
```
- [x] Fast-forward `NIFTy_8` to `origin/NIFTy_7` branch
- [x] Rename nifty7 -> nifty8 on NIFTy_8 branch
```sh
rm nifty7
ln -s src nifty8
find . -type f -exec sed -i 's/nifty7/nifty8/g' {} \;
find . -type f -exec sed -i 's/NIFTy_7/NIFTy_8/g' {} \;
find . -type f -exec sed -i 's/NIFTy7/NIFTy8/g' {} \; # Only partially!
```
- [x] Rename NIFTy_6 -> NIFTy_7 in `.gitlab-ci.yml` (for doc generation)
- [x] NIFTy_8 subsection in `README.md` in contributors section
- [x] NIFTy_7 section in `ChangeLog.md`
- [x] Make NIFTy_7 the default branch of the gitlab repository
- [x] Add daily pipeline schedule for `NIFTy_8` branch and remove the one for `NIFTy_6`NIFTy7 releasePhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/330Write guide how to define custom non-linearities2021-06-10T11:39:25ZPhilipp Arrasparras@mpa-garching.mpg.deWrite guide how to define custom non-linearitiesNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/332Rename `Likelihood` -> `LogLikelihood`2021-06-10T10:44:36ZPhilipp Arrasparras@mpa-garching.mpg.deRename `Likelihood` -> `LogLikelihood`NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/331Build html coverage report of both release and develop branch2021-06-09T15:51:21ZPhilipp Arrasparras@mpa-garching.mpg.deBuild html coverage report of both release and develop branchNIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/329Performance check (in ift.check_operator) broken for BernoulliEnergy2021-06-07T10:42:14ZLukas PlatzPerformance check (in ift.check_operator) broken for BernoulliEnergyThe operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?The operator performance check introduced in [`a50ec021`](https://gitlab.mpcdf.mpg.de/ift/nifty/-/commit/a50ec021e457dc8f4e199c6331c67167eec0fdb7) changes the operator test position [by a factor of two](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/a50ec021e457dc8f4e199c6331c67167eec0fdb7/nifty6/extra.py#L146) for the 'application to a linearization' test. This breaks the test for the `BernoulliEnergy`, as it creates input values outside the interval of `[0, 1)`.
@reimar, since you coded this function: does the factor of two serve a valuable purpose, or can we safely delete it?NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/325Update general documentation to GeoVI2021-05-31T08:43:03ZPhilipp Arrasparras@mpa-garching.mpg.deUpdate general documentation to GeoVIAt the end of https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/docs/source/ift.rst MGVI is explicitly discussed. Let's add a discussion on GeoVI here or alternatively add a new file to the documentation for GeoVI alone.At the end of https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/docs/source/ift.rst MGVI is explicitly discussed. Let's add a discussion on GeoVI here or alternatively add a new file to the documentation for GeoVI alone.NIFTy7 releasehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/326Check NIFTy_7 documentation generation for error messages2021-05-30T17:30:29ZPhilipp Arrasparras@mpa-garching.mpg.deCheck NIFTy_7 documentation generation for error messagesNIFTy7 releasePhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/322Update contributors list2021-05-30T17:28:48ZPhilipp Arrasparras@mpa-garching.mpg.deUpdate contributors listNIFTy7 releasePhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/324Update `demos/mgvi_visualized.py` to GeoVI2021-05-30T14:49:38ZPhilipp Arrasparras@mpa-garching.mpg.deUpdate `demos/mgvi_visualized.py` to GeoVINIFTy7 releasePhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/321Windows compatibility2021-05-05T17:08:08ZLukas PlatzWindows compatibilityA collaborator of mine just tried to install Nifty on a Windows machine in an Anaconda environment and had the problem that the symlink from `nifty7` to `src` was apparently breaking the setup. Once she removed it and renamed `src` to `nifty7`, the setup worked.
I have not checked if this is the general behavior under Windows or if it is just her setup, but assume it is the former.
Has anybody else experience with this and can weigh in?
What was the rationale behind changing the source location and introducing the symlink?
Cheers,
LukasA collaborator of mine just tried to install Nifty on a Windows machine in an Anaconda environment and had the problem that the symlink from `nifty7` to `src` was apparently breaking the setup. Once she removed it and renamed `src` to `nifty7`, the setup worked.
I have not checked if this is the general behavior under Windows or if it is just her setup, but assume it is the former.
Has anybody else experience with this and can weigh in?
What was the rationale behind changing the source location and introducing the symlink?
Cheers,
Lukashttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/308Fisher test for VariableCovarianceGaussianEnergy not sensitive2021-04-09T12:56:45ZPhilipp Arrasparras@mpa-garching.mpg.deFisher test for VariableCovarianceGaussianEnergy not sensitiveOn the branch `metric_tests` I have introduced a breaking factor (949578182c660faee1ea7344d79993d9d1b35310) and the test does not break. I am not sure how to fix it. Is it even possible to fix it in this case? Do we need two test cases, one where the mean is sampled and one where the variance is sampled?On the branch `metric_tests` I have introduced a breaking factor (949578182c660faee1ea7344d79993d9d1b35310) and the test does not break. I am not sure how to fix it. Is it even possible to fix it in this case? Do we need two test cases, one where the mean is sampled and one where the variance is sampled?Reimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/320Is `ift.operators.operator._FunctionApplier` exposed to the NIFTy namespace? ...2021-04-07T10:02:09ZLukas PlatzIs `ift.operators.operator._FunctionApplier` exposed to the NIFTy namespace? If not, why?I just had the case where I wanted to prepend a pointwise operator to a give operator. For *ap*pending a pointwise operator, we have the syntax `op.ptw()`, but do we also have a direct way to *pre*pend an operator?
What I came up with in a hunch was `op @ ift.ScalingOperator(op.domain, 1.).abs()`, but that is just horrible.
Is there a simple way to do this that I forgot? If not, why don't we expose `operator._FunctionApplier` as `ift.FunctionApplier`?
Cheers!I just had the case where I wanted to prepend a pointwise operator to a give operator. For *ap*pending a pointwise operator, we have the syntax `op.ptw()`, but do we also have a direct way to *pre*pend an operator?
What I came up with in a hunch was `op @ ift.ScalingOperator(op.domain, 1.).abs()`, but that is just horrible.
Is there a simple way to do this that I forgot? If not, why don't we expose `operator._FunctionApplier` as `ift.FunctionApplier`?
Cheers!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/317MaternKernel implementation2021-03-24T09:12:11ZVincent EberleMaternKernel implementation# Matern Kernel
I thought it is a good idea to create this issue to keep everyone up-to-date who is involved in developement or already uses the Matern_kernel.
https://gitlab.mpcdf.mpg.de/ift/nifty/-/tree/matern_kernel
@matteani @jroth @parras @sding @gedenhof @vkainz
If I forgot somebody, just mention them to make sure that they are notified.
# TODO
- [x] Implementation of a**b by Simon and Philipp
- [x] Tests
- [x] Cosmetics
- [x] Demo
- [x] Make statistics_summary work for Matern Kernel fluctuations# Matern Kernel
I thought it is a good idea to create this issue to keep everyone up-to-date who is involved in developement or already uses the Matern_kernel.
https://gitlab.mpcdf.mpg.de/ift/nifty/-/tree/matern_kernel
@matteani @jroth @parras @sding @gedenhof @vkainz
If I forgot somebody, just mention them to make sure that they are notified.
# TODO
- [x] Implementation of a**b by Simon and Philipp
- [x] Tests
- [x] Cosmetics
- [x] Demo
- [x] Make statistics_summary work for Matern Kernel fluctuationshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/319AttributeError: 'OperatorAdapter' object has no attribute 'duckape'2021-03-07T22:57:53ZGordian EdenhoferAttributeError: 'OperatorAdapter' object has no attribute 'duckape'OperatorAdapter, e.g. the adjoint of an operator, should support ducktaping.OperatorAdapter, e.g. the adjoint of an operator, should support ducktaping.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/318Ducc dependency2021-03-07T13:33:04ZJakob RothDucc dependencySo far DUCC was an optional dependency of nifty7. Now it is strictly required because of the import in https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/src/library/nft.py#L20
Is this intended?So far DUCC was an optional dependency of nifty7. Now it is strictly required because of the import in https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/src/library/nft.py#L20
Is this intended?