ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2019-02-25T10:55:09Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/260extending clip2019-02-25T10:55:09ZReimar H Leikeextending clipCurrently clip clips all values by the same clipping value. However, in numpy clip can also take an array, such that every value gets clipped by a diffent clipping value. Field.clip can in principle take a dobj and then clips differently...Currently clip clips all values by the same clipping value. However, in numpy clip can also take an array, such that every value gets clipped by a diffent clipping value. Field.clip can in principle take a dobj and then clips differently for every entry, however this does not seem intended.
It would be advantageous to support passing a Field/MultiField instead of a scalar for clip.Reimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/238extra.check_value_gradient_consistency does not work for MultiField2018-05-23T09:22:38ZJakob Knollmuellerextra.check_value_gradient_consistency does not work for MultiFieldextra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead i...extra.check_value_gradient_consistency calls Field.from_random, which does not support drawing random MultiFields.
Does it make more sense to remove the static Field.from_random, which always requires an additional domain, and instead introduce something like domain.random(random_type)? Alternatively one has to include checks for MultiField or regular Field.
Jakobhttps://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/243feature request: fun with multi2018-06-15T05:40:25ZReimar H Leikefeature request: fun with multiMultifields and operators do not yet support some of the convenience functionality present for normal fields and operators. For example a MultiField that is multiplied with a BlockDiagonalOperator is not automatically converted to a Diag...Multifields and operators do not yet support some of the convenience functionality present for normal fields and operators. For example a MultiField that is multiplied with a BlockDiagonalOperator is not automatically converted to a Diagonal Operator the way it is done for fields. Minimal example attached.
[multi_issue.py](/uploads/f634d63059005da5f20731d673373e8c/multi_issue.py)Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty_gridder/-/issues/1Feature wishlist2019-09-24T09:00:52ZPhilipp Arrasparras@mpa-garching.mpg.deFeature wishlist- [x] Add single precision mode
- [x] Compute holograpic matrix as sparse matrix
- [x] Set number of threads for fft from outside
- [x] Compute w-screen on the fly and apply it in dirty2grid and grid2dirty
- [x] Exploit symmetries in w-...- [x] Add single precision mode
- [x] Compute holograpic matrix as sparse matrix
- [x] Set number of threads for fft from outside
- [x] Compute w-screen on the fly and apply it in dirty2grid and grid2dirty
- [x] Exploit symmetries in w-screen
- [x] Add primary beam to gridder? No, at least not now.
- [x] Add weighted versions for vis2grid, grid2vis, apply_holo
- [x] Test wstacking vs modified DFThttps://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/71FFT transformations, RGSpace(zerocenter)2017-04-10T23:29:10ZPumpe, Daniel (dpumpe)FFT transformations, RGSpace(zerocenter)Hi, during a few small tests Martin and me came across a serious problem concerning harmonic transformations. If one uses a RGSpace with npix%2 !=0 and zerocenter=True the FFT gives wrong results (see example res4.val).
As the handling...Hi, during a few small tests Martin and me came across a serious problem concerning harmonic transformations. If one uses a RGSpace with npix%2 !=0 and zerocenter=True the FFT gives wrong results (see example res4.val).
As the handling of the zerocenter-keyword seems to give rise to various problems and in particular complexity in the code, we have to ask the question "what is it necessary for". If we come to the conclusion that we can drop it in fewer of simplicity, which necessary functionality would we loose?
`x1 = RGSpace(200, zerocenter=False, distances=0.1)
k1 = RGRGTransformation.get_codomain(x1, zerocenter=False)
FFT1 = FFTOperator(domain=x1, target=k1,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_1 = Field(x1, val=1.)
res1 = FFT1.inverse_times(FFT1.times(test_field_1))
x2 = RGSpace(200, zerocenter=True, distances=0.1)
k2 = RGRGTransformation.get_codomain(x2, zerocenter=True)
FFT2 = FFTOperator(domain=x2, target=k2,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_2 = Field(x2, val=1.)
res2 = FFT2.inverse_times(FFT2.times(test_field_2))
x3 = RGSpace(199, zerocenter=False, distances=0.1)
k3 = RGRGTransformation.get_codomain(x3, zerocenter=False)
FFT3 = FFTOperator(domain=x3, target=k3,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_3 = Field(x3, val=1.)
res3 = FFT3.inverse_times(FFT3.times(test_field_3))
x4 = RGSpace(199, zerocenter=True, distances=0.1)
k4 = RGRGTransformation.get_codomain(x4, zerocenter=True)
FFT4 = FFTOperator(domain=x4, target=k4,
domain_dtype=np.float64,
target_dtype=np.complex64)
test_field_4 = Field(x4, val=1.)
res4 = FFT4.inverse_times(FFT4.times(test_field_4))```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/208Field.__abs__ returns incorrect data type for complex fields2018-02-06T10:57:01ZMartin ReineckeField.__abs__ returns incorrect data type for complex fieldsCurrently, calling `abs(f)` on a complex-valued field `f` returns a complex-valued field, instead of a real-valued one. This is at odds with `numpy`'s behaviour.Currently, calling `abs(f)` on a complex-valued field `f` returns a complex-valued field, instead of a real-valued one. This is at odds with `numpy`'s behaviour.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/167Field data types must be enforced consistently2017-08-15T08:05:09ZMartin ReineckeField data types must be enforced consistentlyI'm trying to debug the line searching algorithm and noticed that some of the input quantities have complex type.
This is not really acceptable, because there are no useful comparison operators defined for complex numbers, and the code ...I'm trying to debug the line searching algorithm and noticed that some of the input quantities have complex type.
This is not really acceptable, because there are no useful comparison operators defined for complex numbers, and the code does lots of comparisons. I don't understand why no exceptions are thrown; pure Python immediately complains if complex numbers are compared via <,>, etc., but numpy somehow doesn't.
We really need strict enforcement that search positions, gradients and energy values have real type.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/187Field.dim returns 0 for fields without domain2017-09-28T01:37:34ZMartin ReineckeField.dim returns 0 for fields without domain```
import nifty as ift
f=ift.Field((),val=42)
print f.val
print f.dim
```
As expected, the Field contains a single value, but its `dim` property is 0, which seems incorrect and is also inconsistent with `numpy.ndarray`'s behavior for z...```
import nifty as ift
f=ift.Field((),val=42)
print f.val
print f.dim
```
As expected, the Field contains a single value, but its `dim` property is 0, which seems incorrect and is also inconsistent with `numpy.ndarray`'s behavior for zero-dimensional arrays.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/179Field.from_random crashes mpi2018-02-15T14:31:18ZJakob KnollmuellerField.from_random crashes mpiHi,
I found another bug with mpi:
[minimal_example.py](/uploads/3863c7e25ac0661caab65a64bd964264/minimal_example.py)
the error I get is:
```
[MainThread][ERROR ] root Uncaught exception
Traceback (most recent call last):
F...Hi,
I found another bug with mpi:
[minimal_example.py](/uploads/3863c7e25ac0661caab65a64bd964264/minimal_example.py)
the error I get is:
```
[MainThread][ERROR ] root Uncaught exception
Traceback (most recent call last):
File "minimal_example-3.py", line 16, in <module>
std=some_diagonal.val)
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.1.0-py2.7.egg/nifty/field.py", line 251, in from_random
lambda shape: generator_function(dtype=f.dtype,
File "/usr/local/lib/python2.7/dist-packages/d2o/distributed_data_object.py", line 469, in apply_generator
self.set_local_data(generator(self.distributor.local_shape), copy=copy)
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.1.0-py2.7.egg/nifty/field.py", line 253, in <lambda>
**random_arguments))
File "/usr/local/lib/python2.7/dist-packages/ift_nifty-3.1.0-py2.7.egg/nifty/random.py", line 50, in normal
x *= dtype.type(std)
ValueError: operands could not be broadcast together with shapes (16,64,64) (64,64,64) (16,64,64)
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[29272,1],1]
Exit code: 1
--------------------------------------------------------------------------
```
I only get it if the std in from_random is a array, for numbers it seems to work
Jakobhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/193Field method; Field.integrate2018-01-11T13:31:00ZPumpe, Daniel (dpumpe)Field method; Field.integrateMartin, Sebastian and I think that it would be advantageous to have a Field method, `.integrate(spaces)` in case one has to integrate over one or multiple dimensions of a field. `.integrate` would thereby take care of all necessary volum...Martin, Sebastian and I think that it would be advantageous to have a Field method, `.integrate(spaces)` in case one has to integrate over one or multiple dimensions of a field. `.integrate` would thereby take care of all necessary volume factors as they appear in integrals.
What do you think about it (@reimar, @kjako @theos)?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/191Field.power_synthesize(): some clarifications needed2017-12-09T14:10:49ZMartin ReineckeField.power_synthesize(): some clarifications neededI'm trying to understand the intricacies of `Field.power_synthesize()` and am encountering a few points that are unclear to me:
- which combinations of `real_signal` and `real_power` are allowed? Specifically, is it allowed/sensible to ...I'm trying to understand the intricacies of `Field.power_synthesize()` and am encountering a few points that are unclear to me:
- which combinations of `real_signal` and `real_power` are allowed? Specifically, is it allowed/sensible to have `real_signal==True` and `real_power==False`?
- if `self.dtype==float`, does it make sense to have `real_power==False`? In that case, `local_rescaler.imag` will become zero.
Once I understand all of this better, I'd volunteer to extend the docstring, and (if necessary) add a few sanity checks to the code.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/188Field.real/imag copy arrays, contrary to documentation2018-01-11T14:25:17ZMartin ReineckeField.real/imag copy arrays, contrary to documentation```
import nifty as ift
a=ift.RGSpace(10)
f=ift.Field(a,val=1.+1j)
f.real.val+=2
f.imag.val+=2
print f.val
```
This prints '1+1j' as the field value, i.e. the manipulations of real and imaginary parts did not affect the original field....```
import nifty as ift
a=ift.RGSpace(10)
f=ift.Field(a,val=1.+1j)
f.real.val+=2
f.imag.val+=2
print f.val
```
This prints '1+1j' as the field value, i.e. the manipulations of real and imaginary parts did not affect the original field. This seems to contradict the documentation, which states that the data is not copied.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/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/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 aut...- [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/127Find good convergence criterion for DescentMinimizer2017-07-11T08:26:57ZTheo SteiningerFind good convergence criterion for DescentMinimizerAt the moment the `convergence number` is defined as `delta = abs(gradient).max() * (step_length/gradient_norm)`
Are there better measures? For a simple quadratic potential, this definition of `delta` causes a steepest descent to not tr...At the moment the `convergence number` is defined as `delta = abs(gradient).max() * (step_length/gradient_norm)`
Are there better measures? For a simple quadratic potential, this definition of `delta` causes a steepest descent to not trust the (actual true) minimum.
A good measure should be independent of scale and initial conditions.
Some possible candidates are:
* `(new_energy.position - energy.position).norm()`
* `(new_energy.position - energy.position).max()`
* `((new_energy.position - energy.position)/(1+energy.position)).norm()`
* `((new_energy.position - energy.position)/(1+energy.position)).max()`
* `step_length`
* `step_length / energy.position.norm()`
* `gradient.norm()`Martin ReineckeMartin Reineckehttps://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, ...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/162Fix class-docstrings for new operators2017-08-15T08:03:20ZTheo SteiningerFix class-docstrings for new operatorsThe docstrings for the following operators must be refactored (80-chars limit, complete missing entries, etc...)
- LaplaceOperator
- SmoothnessOperatorThe docstrings for the following operators must be refactored (80-chars limit, complete missing entries, etc...)
- LaplaceOperator
- SmoothnessOperatorJakob KnollmuellerJakob Knollmueller2017-07-12