ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-05-28T06:56:12Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/117Make "master" the default branch of the repository2017-05-28T06:56:12ZMartin ReineckeMake "master" the default branch of the repositoryThe Nifty_1 branch is (or at least should be) more or less unused by now. I suggest making "master" the default branch.The Nifty_1 branch is (or at least should be) more or less unused by now. I suggest making "master" the default branch.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/116Allow plots of the sphere without depending on healpy2017-05-28T06:56:12ZMartin ReineckeAllow plots of the sphere without depending on healpyIt should not be a big effort to provide basic plotting functionality for functions on the sphere without having to import healpy. I will take care of this.It should not be a big effort to provide basic plotting functionality for functions on the sphere without having to import healpy. I will take care of this.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/115Remove "Makefile"2017-05-28T06:56:12ZMartin ReineckeRemove "Makefile"Is this file needed for anything? It has not been updated for two years and seems disconnected from the rest of the package.Is this file needed for anything? It has not been updated for two years and seems disconnected from the rest of the package.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/114implement PowerSpace nbins>dim check2017-05-28T06:56:12ZReimar H Leikeimplement PowerSpace nbins>dim checkPowerSpace should raise an exception if nbins is bigger than the number of dimensionsPowerSpace should raise an exception if nbins is bigger than the number of dimensionsReimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/113Simplify direct smoothing code2017-05-28T06:56:12ZMartin ReineckeSimplify direct smoothing codeIf I understood correctly, this functionality performs Gaussian smoothing on a (non-equidistant) array of data.
I can implement this efficiently and without using Cython; I just need some help in the case that the array is distributed over several MPI tasks...
Implementing this would get rid of Nifty's Cython dependence.If I understood correctly, this functionality performs Gaussian smoothing on a (non-equidistant) array of data.
I can implement this efficiently and without using Cython; I just need some help in the case that the array is distributed over several MPI tasks...
Implementing this would get rid of Nifty's Cython dependence.Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/112adjoint_inverse_times vs. inverse_adjoint_times2017-05-28T06:56:12ZTheo Steiningeradjoint_inverse_times vs. inverse_adjoint_timesIf a (left&right)-inverse of an operator exists, both methods are the same.If a (left&right)-inverse of an operator exists, both methods are the same.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/111Unitary vs. Isometric&Coisometric2017-05-28T06:56:12ZTheo SteiningerUnitary vs. Isometric&CoisometricSHT are in general not unitary but they can be (co)isometric. In this case, there exist left- and right-inverses. Do we want to distinguish unitary -> (co)isometric in order to automatically enable e.g. `inverse_times` for certain isometric SHTs?SHT are in general not unitary but they can be (co)isometric. In this case, there exist left- and right-inverses. Do we want to distinguish unitary -> (co)isometric in order to automatically enable e.g. `inverse_times` for certain isometric SHTs?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/110RGSpace hermitian decomposition bug for zerocentered & odd-number of pixels2017-05-28T06:56:12ZTheo SteiningerRGSpace hermitian decomposition bug for zerocentered & odd-number of pixelsTheo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/109Discuss default dtype problems for FFT/SHT Operator2017-05-28T06:56:12ZTheo SteiningerDiscuss default dtype problems for FFT/SHT Operatorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/107Add NIFTy 3 virtualenv to prelude.2017-05-28T06:56:12ZTheo SteiningerAdd NIFTy 3 virtualenv to prelude.Pumpe, Daniel (dpumpe)Pumpe, Daniel (dpumpe)https://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 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!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/141Many tests are apparently skipped2017-05-31T07:24:21ZMartin ReineckeMany tests are apparently skippedThe @expand decorator use in our tests doesn't seem to work as we expect...
For example, the `test_pipundexInversion` method in test_power_space_test.py should be instantiated for the 10 different `RGSpace`s and the 2 `LMSpace`s in `HARMONIC_SPACES`. In fact, there are only test names like
`test_pipundexInversion_RGSpace_not_None_3_False`
and
`test_pipundexInversion_LMSpace_fftw_None_3_True`
It seems that the constructor arguments to the spaces in HARMONIC_SPACES are not reflected in the names of the tests, and so the same test name is created over and over, and only run once in the end.
I have no idea how to fix this.The @expand decorator use in our tests doesn't seem to work as we expect...
For example, the `test_pipundexInversion` method in test_power_space_test.py should be instantiated for the 10 different `RGSpace`s and the 2 `LMSpace`s in `HARMONIC_SPACES`. In fact, there are only test names like
`test_pipundexInversion_RGSpace_not_None_3_False`
and
`test_pipundexInversion_LMSpace_fftw_None_3_True`
It seems that the constructor arguments to the spaces in HARMONIC_SPACES are not reflected in the names of the tests, and so the same test name is created over and over, and only run once in the end.
I have no idea how to fix this.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/143Try to avoid the exponentiation operator where possible2017-06-05T00:47:12ZMartin ReineckeTry to avoid the exponentiation operator where possibleLoosely related to issue 142, I have started a branch trying to get rid of the exponentiation expressions (i.e. `**`) in Nifty where they are not really needed.
If you can avoid `**`, please do. It has a very strange precedence. While it is clear why the expressions mentioned in issue 142 need brackets (once one thinks about it long enough), there are *really* bizarre cases, like the following from https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/minimization/line_searching/line_search_strong_wolfe.py#L347
`d1[0, 1] = -db ** 2`
In Python, this is equivalent to "-(db*db)", although the spaces and general experience suggest otherwise.
In Fortran, the value of this expression would be "db*db".
[Edit: sorry, this is incorrect; I blindly trusted information on the internet :(]
So please, whenever you have to use `**`, be _very_ explicit with brackets!Loosely related to issue 142, I have started a branch trying to get rid of the exponentiation expressions (i.e. `**`) in Nifty where they are not really needed.
If you can avoid `**`, please do. It has a very strange precedence. While it is clear why the expressions mentioned in issue 142 need brackets (once one thinks about it long enough), there are *really* bizarre cases, like the following from https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/minimization/line_searching/line_search_strong_wolfe.py#L347
`d1[0, 1] = -db ** 2`
In Python, this is equivalent to "-(db*db)", although the spaces and general experience suggest otherwise.
In Fortran, the value of this expression would be "db*db".
[Edit: sorry, this is incorrect; I blindly trusted information on the internet :(]
So please, whenever you have to use `**`, be _very_ explicit with brackets!https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/138Support pyfftw even if MPI is not present2017-06-05T02:15:59ZMartin ReineckeSupport pyfftw even if MPI is not presentThis will allow using multi-threaded FFTs which can be a big help in large calculations.This will allow using multi-threaded FFTs which can be a big help in large calculations.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/140Dependencies in README file2017-06-05T11:29:49ZPhilipp ArrasDependencies in README fileDuring install I noticed that the PyPI packages `mpi4py`, `nose_parameterized` and `plotly`, which I needed to get NIFTy to run, are not mentioned in the README.During install I noticed that the PyPI packages `mpi4py`, `nose_parameterized` and `plotly`, which I needed to get NIFTy to run, are not mentioned in the README.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/147Probing harmonic domain, ```.generate_probe```2017-06-08T14:33:07ZPumpe, Daniel (dpumpe)Probing harmonic domain, ```.generate_probe```Hi,
for a classical critical filter run, inferring a power spectrum one has to probe the ```PropagatorOperator``` in its harmonic domain. Consequently this requires to get harmonic probes. These probes have to fulfil a few conditions, i.e. random_type= 'pm1' or 'normal', std=1, mean=0, real_signal=True. For gauss-distributed random numbers this is easy to get, however for 'pm1' currently I do not see a straight way.
For the 1-d case getting 'pm1' random numbers in the ```Prober``` could look like this,
```
def generate_probe(self):
""" a random-probe generator """
if self.domain[0].harmonic:
f = Field(self.domain, val=0., dtype=np.complex)
for ii in xrange(int(self.domain[0].shape[0]/2.-1.)):
real = np.random.randint(-1, 2)
img = np.random.randint(-1, 2)
f.val[ii+1] = np.complex(real, img)
f.val[-(ii+1)] = f.val[ii+1].conjugate()
mono = np.random.randint(-1, 2)
f.val[0] = np.complex(mono, 0.)
else:
f = Field.from_random(random_type=self.random_type,
domain=self.domain,
distribution_strategy=self.distribution_strategy)
uid = np.random.randint(1e18)
return (uid, f)
```Hi,
for a classical critical filter run, inferring a power spectrum one has to probe the ```PropagatorOperator``` in its harmonic domain. Consequently this requires to get harmonic probes. These probes have to fulfil a few conditions, i.e. random_type= 'pm1' or 'normal', std=1, mean=0, real_signal=True. For gauss-distributed random numbers this is easy to get, however for 'pm1' currently I do not see a straight way.
For the 1-d case getting 'pm1' random numbers in the ```Prober``` could look like this,
```
def generate_probe(self):
""" a random-probe generator """
if self.domain[0].harmonic:
f = Field(self.domain, val=0., dtype=np.complex)
for ii in xrange(int(self.domain[0].shape[0]/2.-1.)):
real = np.random.randint(-1, 2)
img = np.random.randint(-1, 2)
f.val[ii+1] = np.complex(real, img)
f.val[-(ii+1)] = f.val[ii+1].conjugate()
mono = np.random.randint(-1, 2)
f.val[0] = np.complex(mono, 0.)
else:
f = Field.from_random(random_type=self.random_type,
domain=self.domain,
distribution_strategy=self.distribution_strategy)
uid = np.random.randint(1e18)
return (uid, f)
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/148Which data types do we allow for Field.dtype?2017-06-09T10:18:39ZMartin ReineckeWhich data types do we allow for Field.dtype?It seems that defining a Field with an integer dtype can produce quite unexpected results:
```
In [1]: from nifty import *
In [2]: import numpy as np
In [3]: s=RGSpace((4,))
In [4]: f=Field(s,val=np.arange(4))
In [5]: f.dot(f,bare=False)
Out[5]: 0
```
I suggest that we limit the allowed data types for Nifty fields to floating point and complex floating point. This could be enforced in Field._infer_dtype().It seems that defining a Field with an integer dtype can produce quite unexpected results:
```
In [1]: from nifty import *
In [2]: import numpy as np
In [3]: s=RGSpace((4,))
In [4]: f=Field(s,val=np.arange(4))
In [5]: f.dot(f,bare=False)
Out[5]: 0
```
I suggest that we limit the allowed data types for Nifty fields to floating point and complex floating point. This could be enforced in Field._infer_dtype().https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/134Direct smoothing with logarithmic distances doesn't conserve the norm.2017-06-12T00:38:52ZTheo SteiningerDirect smoothing with logarithmic distances doesn't conserve the norm.The direct smoothing doesn't conserve the norm of an input field and also distributes the weight differently depending on the scale.
```
from nifty import *
x = RGSpace((2048), harmonic=True)
xp = PowerSpace(x)
f = Field(xp, val = 1.)
f.val[100] = 10
f.val[500] = 10
f.val[50] = 10
sm = SmoothingOperator(xp, sigma=0.1, log_distances=True)
g = sm(f)
f.dot(f)
g.dot(g)
plo = plotting.PowerPlotter(title='power.html')
plo(g)
```
![image](/uploads/cb6ec21b1814083df3a09594367cae14/image.png)
The direct smoothing doesn't conserve the norm of an input field and also distributes the weight differently depending on the scale.
```
from nifty import *
x = RGSpace((2048), harmonic=True)
xp = PowerSpace(x)
f = Field(xp, val = 1.)
f.val[100] = 10
f.val[500] = 10
f.val[50] = 10
sm = SmoothingOperator(xp, sigma=0.1, log_distances=True)
g = sm(f)
f.dot(f)
g.dot(g)
plo = plotting.PowerPlotter(title='power.html')
plo(g)
```
![image](/uploads/cb6ec21b1814083df3a09594367cae14/image.png)
Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/149Behaviour of the Field class on empty domains2017-06-12T23:24:23ZSebastian HutschenreuterBehaviour of the Field class on empty domainsField seems to do odd things when the domain is set empty under variation of the dtype keyword.
I know that he example is rather artificial, non the less I thought I should mention it.
In [2]: ff = Field(domain=(),dtype=np.float)
In [3]: ff.val.get_full_data()
[MainThread][WARNING ] _distributor_factory Distribution strategy was set to 'not' because of global_shape == ()
Out[3]: array(0.0)
In [4]: ff = Field(domain=(),dtype=np.complex)
In [5]: ff.val.get_full_data()
[MainThread][WARNING ] _distributor_factory Distribution strategy was set to 'not' because of global_shape == ()
Out[5]: array((8.772981689857213+0j))Field seems to do odd things when the domain is set empty under variation of the dtype keyword.
I know that he example is rather artificial, non the less I thought I should mention it.
In [2]: ff = Field(domain=(),dtype=np.float)
In [3]: ff.val.get_full_data()
[MainThread][WARNING ] _distributor_factory Distribution strategy was set to 'not' because of global_shape == ()
Out[3]: array(0.0)
In [4]: ff = Field(domain=(),dtype=np.complex)
In [5]: ff.val.get_full_data()
[MainThread][WARNING ] _distributor_factory Distribution strategy was set to 'not' because of global_shape == ()
Out[5]: array((8.772981689857213+0j))https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/150The dot product of a field with itself2017-06-12T23:31:34ZSebastian HutschenreuterThe dot product of a field with itselfThe dot product only considers the volume factors of the first field in case bare=False. This leads to the (in my mind) odd result noted below.
In [2]: np.random.seed(123)
In [3]: rgf = Field(domain=RGSpace(4),val=np.random.randn(4))
In [4]: rgf.dot(rgf)
Out[4]: 1.1305730855452751
This is equal to
In [5]: (rgf.weight(power=1) * rgf).sum()
Out[5]: 1.1305730855452751
Wouldn't the two following cases be more appropriate, depending on the context?
In [6]: (rgf.weight(power=1) * rgf.weight(power=1)).sum()
Out[6]: 0.28264327138631878
In [7]: (rgf*rgf).sum()
Out[7]: 4.5222923421811005The dot product only considers the volume factors of the first field in case bare=False. This leads to the (in my mind) odd result noted below.
In [2]: np.random.seed(123)
In [3]: rgf = Field(domain=RGSpace(4),val=np.random.randn(4))
In [4]: rgf.dot(rgf)
Out[4]: 1.1305730855452751
This is equal to
In [5]: (rgf.weight(power=1) * rgf).sum()
Out[5]: 1.1305730855452751
Wouldn't the two following cases be more appropriate, depending on the context?
In [6]: (rgf.weight(power=1) * rgf.weight(power=1)).sum()
Out[6]: 0.28264327138631878
In [7]: (rgf*rgf).sum()
Out[7]: 4.5222923421811005