ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2018-01-18T15:55:29Zhttps://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/95Tests: Space classes2017-08-15T08:04:24ZTheo SteiningerTests: Space classesCheck if they are complete.Check if they are complete.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/94Update Wiener filter demo2017-07-29T11:34:09ZTheo SteiningerUpdate Wiener filter demoInclude all the convenience features, like dynamic parametrization, logging, versioning, etc...Include all the convenience features, like dynamic parametrization, logging, versioning, etc...https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/93Docstring: Probing2018-02-14T15:13:33ZTheo SteiningerDocstring: Probinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/92Update README2017-05-18T11:48:20ZTheo SteiningerUpdate READMEEspecially install instructions. Docker, etc...Especially install instructions. Docker, etc...Martin ReineckeMartin Reineckehttps://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/90Docstring: Energy class2017-05-19T01:24:57ZTheo SteiningerDocstring: Energy classJakob KnollmuellerJakob Knollmuellerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/89Docstring: Minimizers2017-05-19T01:25:07ZTheo SteiningerDocstring: Minimizershttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/88Docstring: Operators2017-05-15T07:07:19ZTheo SteiningerDocstring: OperatorsPumpe, Daniel (dpumpe)Pumpe, Daniel (dpumpe)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/87Docstring: Field class2017-05-19T01:24:49ZTheo SteiningerDocstring: Field classhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/86Docstring: Space classes2017-05-19T01:25:16ZTheo SteiningerDocstring: Space classesReimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/85Docstring: NIFTy2018-02-21T21:15:54ZTheo SteiningerDocstring: NIFTyhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/84Tweaking the copyright notices2017-05-24T10:40:49ZMartin ReineckeTweaking the copyright noticesThis is not urgent, but needs to be addressed before the first real public release...
The current copyright notices are insufficient/inaccurate in a few respects:
- copyright year: this should not be just "2017" but the range of year...This is not urgent, but needs to be addressed before the first real public release...
The current copyright notices are insufficient/inaccurate in a few respects:
- copyright year: this should not be just "2017" but the range of years since this file was created
- copyright holder: as far as I know, copyright is held by "Max-Planck-Society"
- author: this should be a list of all people who have significantly contributed to the file. So Marco should be added in many of the files.
I know this makes things complicated, since not all files will have the same copyright header. But I really think that the principle "better safe than sorry" applies here.
A small silver lining: I'm pretty sure that the `__init__.py` files don't need copyright notices at all; their content is trivial (in legal German: they don't have sufficient "Schöpfungshöhe" :)
Unfortunately I cannot provide a merge request since I do not know the history of the individual files.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/83Create Wiener Filter demo which utilizes full keepers functionality.2017-07-29T11:33:55ZTheo SteiningerCreate Wiener Filter demo which utilizes full keepers functionality.* Explicitly configure (MPI-)logging.
* Use keepers.versioning for restartable reconstruction.
* Use dynamic parametrization for setting `iteration_limit`, etc...* Explicitly configure (MPI-)logging.
* Use keepers.versioning for restartable reconstruction.
* Use dynamic parametrization for setting `iteration_limit`, etc...https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/82create_power_operator2017-04-29T01:16:10ZPumpe, Daniel (dpumpe)create_power_operatorHi,
while testing my code I came across a potential problem concerning volume factors in the outcome of the application of an operator created by 'create_power_operator'
minimal example to show differences between Nifty_1 and Nifty_3 ...Hi,
while testing my code I came across a potential problem concerning volume factors in the outcome of the application of an operator created by 'create_power_operator'
minimal example to show differences between Nifty_1 and Nifty_3
[tt.py](/uploads/ffe6ef7ca3fb4aae2b9a2ab3e01001c7/tt.py)
Since 'res_1!= res_2', either Nifty_1 or Nifty_3 calculates something wrong.
In my mind Nifty_1 does the calculation properly. An easy fix in Nifty_3 create_power_operator could be setting the bare keyword in line 43 of the DiagonalOperator to true.
Cheers,
Danielhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/81Drawing random fields2017-05-30T00:31:29ZPumpe, Daniel (dpumpe)Drawing random fieldsHi Theo,
while testing my algorithm I recognised that all random fields drawn from a gaussian have a unwanted symmetry. �
(minimal code extracted from wiener_filter.py example)
`
from nifty import *
# Setting up the geometr...Hi Theo,
while testing my algorithm I recognised that all random fields drawn from a gaussian have a unwanted symmetry. �
(minimal code extracted from wiener_filter.py example)
`
from nifty import *
# Setting up the geometry
s_space = RGSpace([512, 512], dtype=np.float64)
fft = FFTOperator(s_space)
h_space = fft.target[0]
p_space = PowerSpace(h_space, distribution_strategy=distribution_strategy)
# Creating the mock data
pow_spec = (lambda k: 42 / (k + 1) ** 3)
S = create_power_operator(h_space, power_spectrum=pow_spec,
distribution_strategy=distribution_strategy)
sp = Field(p_space, val=pow_spec,
distribution_strategy=distribution_strategy)
sh = sp.power_synthesize(real_signal=True)
ss = fft.inverse_times(sh)
ss_data = ss.val.get_full_data().real
pl.plot([go.Heatmap(z=ss_data)], filename='map_orig.html')`
Am I doing something wrong, did the some default set keywords in the code change or how can I fix this issue?
Thanks for your help!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/80HDF5 tests are not run by the pipelines2017-05-16T21:48:52ZMartin ReineckeHDF5 tests are not run by the pipelinesThis is a minor thing; I'm just mentioning it so we don't forget...
Although HDF5 is installed in one of the CI configurations, the relevant tests (test_serialization.py) are not executed. On my own machine, where the standard h5py pack...This is a minor thing; I'm just mentioning it so we don't forget...
Although HDF5 is installed in one of the CI configurations, the relevant tests (test_serialization.py) are not executed. On my own machine, where the standard h5py package is available, they are run when I do "nosetests -vv". So I expect there is some problem with the automatic setup (e.g. in install_h5py.sh).https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/79Rename operator property "symmetric"2017-05-01T00:35:19ZMartin ReineckeRename operator property "symmetric"Strictly speaking, the property of EndomorphicOperator (and children) called "symmetric" does not reflect the symmetry of the operator matrix, but rather whether it is self-adjoint/hermitian. (Otherwise, DiagonalOperator could always jus...Strictly speaking, the property of EndomorphicOperator (and children) called "symmetric" does not reflect the symmetry of the operator matrix, but rather whether it is self-adjoint/hermitian. (Otherwise, DiagonalOperator could always just return "True" for this property.)
I'd suggest to rename this property to "self_adjoint" or "hermitian". If there is agreement, I'll provide a merge request.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/78SHTs are not unitary transforms2017-05-15T18:23:29ZMartin ReineckeSHTs are not unitary transformsCurrently, SHTs are part of Nifty's FFT operator class, which states (via a property) that its transforms are unitary.
However this is not true for SHTs: their matrix representation is not generally square. As a consequence, the SHT ope...Currently, SHTs are part of Nifty's FFT operator class, which states (via a property) that its transforms are unitary.
However this is not true for SHTs: their matrix representation is not generally square. As a consequence, the SHT operator is not invertible.
So, on the FFT side we have:
- forward transform
- backward transform (which is the inverse, and simultaneously the adjoint of forward)
whereas for SHTs we have:
- alm2map (this can be implemented accurately)
- adjoint alm2map (also accurate)
The inverse alm2map operation ("map2alm") is currently "faked" by a weighted adjoint alm2map, but this only works in specific situations (if the map is band-limited), and in the case of Healpix only approximately.
I'm not sure if this has any significant consequences for the usage of SHTs in Nifty, but we should probably think about separating them from FFTs, to avoid confusion and potentially incorrect application of the SHT operators.
We should make it clear that SHTs can only be used in situations where only the transform from position space to harmonic space and its adjoint are required, but not its inverse.