ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-05-19T01:24:49Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/87Docstring: Field class2017-05-19T01:24:49ZTheo SteiningerDocstring: Field classhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/89Docstring: Minimizers2017-05-19T01:25:07ZTheo SteiningerDocstring: Minimizershttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/85Docstring: NIFTy2018-02-21T21:15:54ZTheo SteiningerDocstring: NIFTyhttps://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/88Docstring: Operators2017-05-15T07:07:19ZTheo SteiningerDocstring: OperatorsPumpe, Daniel (dpumpe)Pumpe, Daniel (dpumpe)https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/93Docstring: Probing2018-02-14T15:13:33ZTheo SteiningerDocstring: Probinghttps://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/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/177Documentation for FFTSmoothingOperator and DirectSmoothingOperator missing2018-02-21T21:18:52ZPhilipp Arrasparras@mpa-garching.mpg.deDocumentation for FFTSmoothingOperator and DirectSmoothingOperator missinghttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/234Documentation for our volume factor approach?2018-06-27T15:54:46ZMartin ReineckeDocumentation for our volume factor approach?Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible...Do we have a short document describing why (and how) our approach with almost no volume factors works?
Vanessa Boehm asked me for an explanation, which I can't give, and I expect more requests of that sort.
@reimar, would it be possible to add something to our documentation?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/349Do not track ipynb and instead use jupytext2022-05-28T08:50:24ZGordian EdenhoferDo not track ipynb and instead use jupytextSee https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/702#note_111326 .See https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/702#note_111326 .Gordian EdenhoferGordian Edenhoferhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/268Do we still need NFFT?2019-04-29T08:25:22ZMartin ReineckeDo we still need NFFT?I'd like to remove the `nifty5.library.NFFT` class, since it will most likely not be used in the future and has a fairly inconvenient dependency on `pynfft` and the nfft package.
Any objections? @parras?I'd like to remove the `nifty5.library.NFFT` class, since it will most likely not be used in the future and has a fairly inconvenient dependency on `pynfft` and the nfft package.
Any objections? @parras?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/192Drawing gaussian random fields over multiple domains2017-09-23T07:14:41ZPumpe, Daniel (dpumpe)Drawing gaussian random fields over multiple domainsHi,
currently I am facing some inconsistencies for drawing gaussian random fields over multiple domains. Yet I did not find the root of these inconsistencies. However in the minimal test example below, `s_1` and `s_2` do not match, nei...Hi,
currently I am facing some inconsistencies for drawing gaussian random fields over multiple domains. Yet I did not find the root of these inconsistencies. However in the minimal test example below, `s_1` and `s_2` do not match, neither mean nor variance even though they should be drawn from the same gaussian just in two different ways. Further none of the drawn fields, `s_1` `s_2`, obey the desired spectra.
What am I doing wrong or missing?
```
from nifty import *
x_0 = RGSpace(50, zerocenter=False, distances=.5)
k_0 = RGRGTransformation.get_codomain(x_0)
p_0 = PowerSpace(harmonic_partner=k_0)
x_1 = RGSpace(75, zerocenter=False, distances=.25)
k_1 = RGRGTransformation.get_codomain(x_1)
p_1 = PowerSpace(harmonic_partner=k_1)
fft_0 = FFTOperator(domain=x_0, target=k_0)
fft_1 = FFTOperator(domain=x_1, target=k_1)
p_spec_0 = Field(p_0, val=lambda l: 1/(1+l)**3)
p_spec_1 = Field(p_1, val=lambda k: 10/(1+k)**5)
def random_field_method_1():
w = Field((x_0, x_1), val=0.)
for ii in xrange(100):
outer = Field((p_0, p_1), val=np.outer(p_spec_0.val, p_spec_1.val))
sk = outer.power_synthesize()
w += fft_0.inverse_times(fft_1.inverse_times(sk, spaces=1), spaces=0)
return w/100.
def random_field_method_2():
w = Field((x_0, x_1), val=0.)
S_0 = create_power_operator(k_0, sqrt(p_spec_0))
S_1 = create_power_operator(k_1, sqrt(p_spec_1))
for ii in xrange(100):
rand = Field.from_random('normal', domain=(x_0, x_1))
rand_k = fft_0.times(fft_1.times(rand, spaces=1), spaces=0)
sk = S_0.times(S_1.times(rand_k, spaces=1), spaces=0)
w += fft_0.inverse_times(fft_1.inverse_times(sk, spaces=1), spaces=0)
return w/100.
def analyze_power(signal):
sk = fft_0.times(fft_1.times(signal,spaces=1), spaces=0)
power = sk.power_analyze()
p_drawn_0 = power.sum(spaces=1)/p_spec_1.sum()
p_drawn_1 = power.sum(spaces=0)/p_spec_0.sum()
return p_drawn_0, p_drawn_1
s_1 = random_field_method_1()
s_2 = random_field_method_2()
method_1_power_0, method_1_power_1 = analyze_power(s_1)
methdo_2_power_0, method_2_power_2 = analyze_power(s_2)
```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 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/240Drawing random fields in multi domains2018-05-23T10:15:45ZPhilipp Arrasparras@mpa-garching.mpg.deDrawing random fields in multi domainsThe following command breaks:
```
ift.Field.from_random("normal", ift.MultiDomain.make({'a': ift.RGSpace(1)}))
```
How can I fix that? Or is it not implemented yet?The following command breaks:
```
ift.Field.from_random("normal", ift.MultiDomain.make({'a': ift.RGSpace(1)}))
```
How can I fix that? Or is it not implemented yet?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/135Drawing random fields, problem on monopol and highest frequency2017-05-23T23:39:28ZPumpe, Daniel (dpumpe)Drawing random fields, problem on monopol and highest frequencyJakob and I encountered a problem with .power_synthesize.
```
from nifty import *
import numpy as np
x1 = RGSpace(200, zerocenter=False, distances=.1)
k1 = RGRGTransformation.get_codomain(x1)
# setting spaces
npix = np.array(...Jakob and I encountered a problem with .power_synthesize.
```
from nifty import *
import numpy as np
x1 = RGSpace(200, zerocenter=False, distances=.1)
k1 = RGRGTransformation.get_codomain(x1)
# setting spaces
npix = np.array([200]) # number of pixels
total_volume = 1. # total length
# setting signal parameters
lambda_s = .2 # signal correlation length
sigma_s = 1.5 # signal variance
# calculating parameters
k_0 = 4./(2*np.pi*lambda_s)
a_s = sigma_s**2.*lambda_s*total_volume
# creation of spaces
x1 = RGSpace(npix, distances=total_volume/npix,
zerocenter=False)
k1 = RGRGTransformation.get_codomain(x1)
p1 = PowerSpace(harmonic_partner=k1, logarithmic=False)
# # creating Power Operator with given spectrum
spec = (lambda k: a_s/(1+(k/k_0)**2)**2)
p_field = Field(p1, val=spec, dtype=np.float64)
# creating FFT-Operator and Response-Operator with Gaussian convolution
FFTOp = FFTOperator(domain=x1, target=k1,
domain_dtype=np.float64,
target_dtype=np.complex128)
# drawing a random field
sp = Field(p1, val=lambda z: spec(z) ** (1. / 2))
no_spec= 10000
sps = Field(p1, val=0.)
for ii in xrange(no_spec):
sk = sp.power_synthesize(real_signal=True, mean=0.)
sps += Field(p1, val=sk.power_analyze()**2, dtype=np.float64)
mean_power = sps/10000.
```
First and last mode of mean_power are wrong by a factor of 2.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/231draw_sample() definition2018-03-28T13:42:23ZChristoph Lienharddraw_sample() definitionthe `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probab...the `draw_sample()` function for linear operators seems to lack a precise definition.
Whereas in the case of a curvature C the `draw_sample` function draws a sample from the corresponding Gaussian approximation of the underlying probability distribution with said curvature (i.e. exp(-0.5 x^+ Cx) ), in the case of a `DiagonalOperator` D it seems to use the distribution wrt the inverse of it (i.e. exp(-0.5 x^+ D^-1 x) )
I propose changing the latter to match the former for consistency.
The curvature definition is more likely to be the one that someone actually wants (at least for the curvature case. For the diagonal operator case one could start arguing, but ... consistency!). Also the `draw_sample` function for the `DiagonalOperator` class is not that hard to change.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/245dtypes in UnitLogGauss2018-06-27T15:55:19ZPhilipp Arrasparras@mpa-garching.mpg.dedtypes in UnitLogGauss```
import numpy as np
import nifty5 as ift
space = ift.RGSpace(2)
f = ift.from_random('normal', space)
var_f = ift.Variable(f)
g = ift.from_random('normal', space, dtype=np.complex)
var_g = ift.Variable(g)
multi = ift.MultiField({'f':...```
import numpy as np
import nifty5 as ift
space = ift.RGSpace(2)
f = ift.from_random('normal', space)
var_f = ift.Variable(f)
g = ift.from_random('normal', space, dtype=np.complex)
var_g = ift.Variable(g)
multi = ift.MultiField({'f': f, 'g': g})
var = ift.Variable(multi)
op = ift.ScalingOperator(1j, space)
op_multi = ift.ScalingOperator(1j, var.value.domain)
lh_f = ift.library.UnitLogGauss(op(var_f))
lh_g = ift.library.UnitLogGauss(op(var_g))
lh = ift.library.UnitLogGauss(op_multi(var))
print(lh_f.value)
print(lh_f.gradient)
print()
print(lh_g.value)
print(lh_g.gradient)
print()
print(lh.value)
print(lh.gradient['f'])
print(lh.gradient['g'])
```
Results in:
```
2.230929182659062
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
0.30445727594179295
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
2.535386458600855
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([-1.52732309+0.j, -1.45915817+0.j])
nifty5.Field instance
- domain = DomainTuple, len: 1
RGSpace(shape=(2,), distances=(0.5,), harmonic=False)
- val = array([0.25117854+0.27192986j, 0.45978435-0.51036889j])
```
I would expect that the gradient has the same `dtype` as the input.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/318Ducc dependency2021-03-07T13:33:04ZJakob RothDucc dependencySo far DUCC was an optional dependency of nifty7. Now it is strictly required because of the import in https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/src/library/nft.py#L20
Is this intended?So far DUCC was an optional dependency of nifty7. Now it is strictly required because of the import in https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/NIFTy_7/src/library/nft.py#L20
Is this intended?