ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2016-07-22T20:57:34Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/47meta_volume vs volume2016-07-22T20:57:34ZTheo Steiningermeta_volume vs volumeSpace.weight methods use volume instead of meta volume.
Isn't this choice arbitrary? By excluding pixes from the weight that contain no new information, we weight according to the 'information volume' instead with the 'geometrical volu...Space.weight methods use volume instead of meta volume.
Isn't this choice arbitrary? By excluding pixes from the weight that contain no new information, we weight according to the 'information volume' instead with the 'geometrical volume'. Also: LMspace (at least for real signal space partners) stores only one half of the pair-wise complex conjugated numbers, RGSpace with complexity==1 stores the full thing. The inner dot product treats them differently.
Definition of meta-volume:
The meta volumes are the volumes associated with each component of a field, taking into account field components that are not explicitly included in the array of field values but are determined by symmetry conditions.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/48LMSpace with complex signal space partners2017-01-20T00:46:08ZTheo SteiningerLMSpace with complex signal space partnersLMSpace stores only one half of the complex-conjugated pairs one gets if the signal field was real valued. In this case the dot product between a=(a_-1, a_0, a_1) and b=(...) can be computed by simply taking a_0*b*0 + 2*(a_1.real*b_1.rea...LMSpace stores only one half of the complex-conjugated pairs one gets if the signal field was real valued. In this case the dot product between a=(a_-1, a_0, a_1) and b=(...) can be computed by simply taking a_0*b*0 + 2*(a_1.real*b_1.real + a_1.imag*b_1.imag) as a_-1 and a_1 are complex-conjugated.
If the signal space field was complex, one gets something with cc-symmetry for the real and the imaginary part of this field respectively; modulo i. FFT is linear -> the result has no cc-symmetry anymore.
Solution: Store the full lm spectrum for LMSpace. Apply the action of libsharp (transform, smooth) on the half sum and half difference of a field with its transposed as this reconstructs the cc-symmetric parts comming from the real (imaginary, resp.)-part of the signal field. Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/49Move `check_codomain` in Transformation to child classes2018-04-02T09:42:38ZTheo SteiningerMove `check_codomain` in Transformation to child classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/50Use gdi(gc[fft_module]) in RGRGTransformation.__init__2018-04-02T09:42:38ZTheo SteiningerUse gdi(gc[fft_module]) in RGRGTransformation.__init__https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/51Make HPSpace, LMSpace, GLSpace available even if the needed modules are not a...2016-07-22T22:57:35ZTheo SteiningerMake HPSpace, LMSpace, GLSpace available even if the needed modules are not available....just raise an exception in doubt....just raise an exception in doubt.Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/52Merge Transform and Transformation classes2018-04-02T09:42:38ZTheo SteiningerMerge Transform and Transformation classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/53Add check_codomain cache to Transformation Classes2018-04-02T09:42:38ZTheo SteiningerAdd check_codomain cache to Transformation Classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/54Move get_codomain from space to Transformator classes2018-04-02T09:42:38ZTheo SteiningerMove get_codomain from space to Transformator classeshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/56RGSpace smoothing2016-10-25T13:23:45ZTheo SteiningerRGSpace smoothingRewrite the RGSpace smoothing method such that it uses a Fourier Transformation Operator instead of self.calc_transform(...).Rewrite the RGSpace smoothing method such that it uses a Fourier Transformation Operator instead of self.calc_transform(...).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 Steiningerhttps://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/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/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/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/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/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/75Python 3 support2017-08-22T17:06:03ZTheo SteiningerPython 3 supporthttps://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/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.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.