ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-05-02T08:51:39Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/77Fix hashing/identifier of domain_objects.2017-05-02T08:51:39ZTheo SteiningerFix hashing/identifier of domain_objects.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/76dtype of spaces2017-05-01T00:37:25ZTheo Steiningerdtype of spacesInvestigate fully if spaces need a dtype from the conceptual point of view. If not -> remove it from spaces/field_types.Investigate fully if spaces need a dtype from the conceptual point of view. If not -> remove it from spaces/field_types.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/75Python 3 support2017-08-22T17:06:03ZTheo SteiningerPython 3 supporthttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/74RGSpace: get_distance_array() returns incorrect results for odd lengths2017-04-29T01:19:53ZMartin ReineckeRGSpace: get_distance_array() returns incorrect results for odd lengthsWith current master, try the following code in ipython:
```
from nifty import *
s_space = RGSpace([3])
s_space.get_distance_array('not')
```
The result I get is
```
<distributed_data_object>
array([ 0.33333333, 0.33333333, 0. ...With current master, try the following code in ipython:
```
from nifty import *
s_space = RGSpace([3])
s_space.get_distance_array('not')
```
The result I get is
```
<distributed_data_object>
array([ 0.33333333, 0.33333333, 0. ])
```
However, I would rather expect something like
`array([0., 0.33333333, 0.33333333 ])`https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/73creation of distributed_data_object without dtype2017-06-13T07:44:11ZMartin Reineckecreation of distributed_data_object without dtypeIn rg_space.py and power_space.py there are calls to the constructor of "distributed_data_object", which do not specify a "dtype" argument.
This is accepted by D2O, but an annoying message is printed to the console.
I would suggest to pr...In rg_space.py and power_space.py there are calls to the constructor of "distributed_data_object", which do not specify a "dtype" argument.
This is accepted by D2O, but an annoying message is printed to the console.
I would suggest to produce a hard error whenever the user tries to create a D2O object without specifying a type. However, for the time being: is it correct to specify "dtype=np.float64" in the two cases I mentioned?
A related question: inside the distance_array-related functions of RGSpace and LMSpace, the data type np.float128 is used. Is that deliberate or an oversight?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/72libsharp_wrapper is broken2017-05-27T14:04:09ZMartin Reineckelibsharp_wrapper is brokenWhile running comparison tests with my new wrapper code, I noticed that the gauleg() routine in libsharp_wapper, which is used from GLSpace.weight(), is broken.
The symptoms are:
- because of incorrect loop bounds, the computation will n...While running comparison tests with my new wrapper code, I noticed that the gauleg() routine in libsharp_wapper, which is used from GLSpace.weight(), is broken.
The symptoms are:
- because of incorrect loop bounds, the computation will not compute the central point when nlat is an odd number. (This is not too problematic, since NIFTy currently forbids such a setting.)
- because of the incorrect usage of abs() instead of fabs(), the iteration for determining the roots of the Legendre polynomial terminates after the first iteration and therefore gives extremely inaccurate results.
I'm not sure whether the original project is still maintained, so I'm posting the warning here. Don't use this code!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/70create_power_operator2017-04-10T12:40:19ZPumpe, Daniel (dpumpe)create_power_operatorHi Theo, while checking volume factors in my code I stumbled over a potential bug in sugar.py create_power_operator. In line 27 the DiagonalOperator should be bare=True (default is False). Else wise the application of such a "PowerOperat...Hi Theo, while checking volume factors in my code I stumbled over a potential bug in sugar.py create_power_operator. In line 27 the DiagonalOperator should be bare=True (default is False). Else wise the application of such a "PowerOperator" does not match the results as if the code would be run in Nifty 1. Or am I missing something, please correct me if I see something wrong.
# Power Spectrum differences
# NIFTY_1
x1 = rg_space(200, zerocenter=False, dist=0.1)
k1 = x1.get_codomain()
spec1 = (lambda k: 42/(1+k**2))
S1 = power_operator(k1, spec=spec1)
test1 = field(x1, val=3)
result1 = S1.inverse_times(test1)
# NIFTy_3
x3 = RGSpace(200, zerocenter=False, distances=0.1)
k3 = RGRGTransformation.get_codomain(x3)
spec3 = (lambda k:42/(1+k**2))
S3 = create_power_operator(k3, spec3)
FFT3 = FFTOperator(domain=x3, target=k3,
domain_dtype=np.float64,
target_dtype=np.complex64)
test3 = Field(x3, val=3)
result3 = FFT3.inverse_times(S3.inverse_times(FFT3.times(test3)))https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/69Documentation bug in RGSpace?2017-04-05T18:48:07ZMartin ReineckeDocumentation bug in RGSpace?The docstring for RGSpace says that "only even numbers of grid points per axis are supported":
https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/rg_space/rg_space.py#L76
However there are no checks in the sources that e...The docstring for RGSpace says that "only even numbers of grid points per axis are supported":
https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/rg_space/rg_space.py#L76
However there are no checks in the sources that enforce this constraint.
In fact, some tests explicitly specify odd grid dimensions.
So I think that this line should be removed.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/68How to run unit tests on the command line?2017-04-05T14:09:00ZMartin ReineckeHow to run unit tests on the command line?Before creating a merge request, I'd like to run the test suite to make sure there are no regressions.
Unfortunately "python setup.py test" doesn't do anything helpful, and I'm not familiar enough with Python projects to run the tests c...Before creating a merge request, I'd like to run the test suite to make sure there are no regressions.
Unfortunately "python setup.py test" doesn't do anything helpful, and I'm not familiar enough with Python projects to run the tests completely by hand.
Could the testing procedure please be documented in README.md?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/67Arbitrary constraints on GL geometry2017-05-01T01:34:10ZMartin ReineckeArbitrary constraints on GL geometryIn gl_space.py on current master, there are constraints on the grid layout which in my opinion make no sense.
- in _parse_nlat, the number of rings is not allowed to be odd. Why ist this the case? I would argue that any positive number o...In gl_space.py on current master, there are constraints on the grid layout which in my opinion make no sense.
- in _parse_nlat, the number of rings is not allowed to be odd. Why ist this the case? I would argue that any positive number of rings is allowed and useful.
- in _parse_nlon, a warning is given if nlon!=2*nlat-1. Depending on the actual values of lmax and mmax for the codomain, this choice is not necessarily the best one.
For GL grids, the connections between nlat, nlon, mmax and lmax should be the following:
- nlat = lmax+1 (this is always a good choice, and a warning could safely be given if the user specifies something different)
- nlon >= 2*mmax+1 (this is the minimum number of pixels per ring that can represent spherical harmonics up to and including mmax. However, it may be preferrable to choose a slightly higher nlon for performance reasons: if possible, nlon should be a product of prime factors <=5).
I am aware that the constructor for GLSpace currently does not have the desired lmax and mmax values at hand, and so cannot warn if the relations above do not hold. However, the current tests should be changed, since they are arbitrary and their restrictions do not improve the code in any way.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/66Bug in gl_space.py?2017-05-01T01:34:57ZMartin ReineckeBug in gl_space.py?In gl_space.py I stumbled over the statement
at https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/gl_space/gl_space.py#L164
` lat = qr_tuple[0]*(np.pi/(self.nlat-1)) `
It seems that the code assumes that the ri...In gl_space.py I stumbled over the statement
at https://gitlab.mpcdf.mpg.de/ift/NIFTy/blob/master/nifty/spaces/gl_space/gl_space.py#L164
` lat = qr_tuple[0]*(np.pi/(self.nlat-1)) `
It seems that the code assumes that the ring latitudes of the GL grid are equidistant ... which is definitely not the case.
However I'm wondering if the "get_distance_array" functionality is needed at all for spaces that do not live in the harmonic domain. If I understand correctly, this is only used for binning when producing a power spectrum.
If this assumption is correct, I suggest to remove the "distance_array" related methods from GL and HP spaces. (This involves removing a few tests as well.)
Maybe it would be good to make it explicit in the class hierarchy that this method is only supported by spaces which live in the harmonic domain.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/64Add poisson statistics to Field class2018-01-18T16:01:29ZTheo SteiningerAdd poisson statistics to Field classLambda must be field valued.Lambda must be field valued.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/63Extend functionality of `Field.from_random`2018-03-22T13:13:33ZTheo SteiningerExtend functionality of `Field.from_random`1. Add poisson statistics
2. Allow for fields as variable inputs (mean, std, lambda, etc...)1. Add poisson statistics
2. Allow for fields as variable inputs (mean, std, lambda, etc...)Theo SteiningerTheo Steiningerhttps://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/61Unreachable code in _local_transform in rg_transforms.py?2018-04-02T09:42:38ZTheo SteiningerUnreachable code in _local_transform in rg_transforms.py? In rg_transform.py in _local_transform the following check is made:
if axes is None or 0 in axes:
local_offset_Q = val.distributor.local_shape[0] % 2
Since _local_transform is only called `if not ( axes is None or 0 ... In rg_transform.py in _local_transform the following check is made:
if axes is None or 0 in axes:
local_offset_Q = val.distributor.local_shape[0] % 2
Since _local_transform is only called `if not ( axes is None or 0 in axes)` (see line 424 in rg_transform.py) this line of code is rever reached. https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/60Configuration for FFT during (de)briefing.2016-10-25T13:23:30ZTheo SteiningerConfiguration for FFT during (de)briefing.Make it optional, whether the briefing should try to (FFT-)transform the input. By this the user could avoid that somewhere still a FFT takes place, although not wanted.Make it optional, whether the briefing should try to (FFT-)transform the input. By this the user could avoid that somewhere still a FFT takes place, although not wanted.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/59PowerSpectrumOperator2016-10-25T13:26:17ZTheo SteiningerPowerSpectrumOperatorEvaluate if it makes sense to create an operator which extracts the power spectrum from a given field along a certain 'space-axis'. Evaluate if it makes sense to create an operator which extracts the power spectrum from a given field along a certain 'space-axis'. Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/58Operator behaviour being faced with fields on multiple spaces2016-10-25T13:26:02ZTheo SteiningerOperator behaviour being faced with fields on multiple spacesBy default: The domains on which the operator is defined must match completely.
Optional: 'spaces'-keyword which tells the operator which of the field's spaces correspond to its domains.
By default: The domains on which the operator is defined must match completely.
Optional: 'spaces'-keyword which tells the operator which of the field's spaces correspond to its domains.
Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/57Add sanity checks to power_space_paradict.2017-01-20T00:36:37ZTheo SteiningerAdd sanity checks to power_space_paradict.Theo SteiningerTheo Steininger