ift issueshttps://gitlab.mpcdf.mpg.de/groups/ift/-/issues2017-07-06T05:50:23Zhttps://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/6d2o cumsum and flatten rely on certain features of distribution strategy2017-07-06T05:50:23ZTheo Steiningerd2o cumsum and flatten rely on certain features of distribution strategycumsum and flatten assume: if the shape of the d2o changes through flattening, the distribution strategy was "slicing". cumsum and flatten assume: if the shape of the d2o changes through flattening, the distribution strategy was "slicing". Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/5Add function d2o.arange2017-07-06T05:50:23ZTheo SteiningerAdd function d2o.arangeTheo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/4Add unit tests for `copy=True/False` functionality2017-07-06T05:50:23ZTheo SteiningerAdd unit tests for `copy=True/False` functionalityTheo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/235Improved LOS response?2018-04-30T09:19:16ZMartin ReineckeImproved LOS response?@kjako mentioned some time ago that the current LOSResponse exhibits some artifacts. I suspect that they are caused by our method to compute the "influence" of lines of sight on individual data points.
Currently, the influence of a line...@kjako mentioned some time ago that the current LOSResponse exhibits some artifacts. I suspect that they are caused by our method to compute the "influence" of lines of sight on individual data points.
Currently, the influence of a line of sight on a data point is simply proportional to the length of its intersection with the cell around the data point. It doesn't matter whether the LOS cuts the cell near the edges or goes straight through the center. This also implies that tiny shifts of a line of sight may lead to dramatic changes of its influences on data points, which is probably not desirable.
I propose to use an approach that is more similar to SPH methods:
- each data point has a sphere of influence with a given R_max (similar to the cell distances)
- it interacts with all lines of sight that intersect its sphere of influence
- the interaction strength scales with the integral along the line of sight over a function f(r) around the data point, which falls to zero at R_max.
My expectation is that this will reduce grid-related artifacts.
@ensslint, @kjako: does this sound worthwhile to try?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/250[post Nifty6] new design for the `Field` class?2019-12-02T20:58:52ZMartin Reinecke[post Nifty6] new design for the `Field` class?I'm wondering whether we can solve most of our current problems regarding fields and multifields by introducing a single new `Field` class that
- unifies the current `Field` and `MultiField` classes (a classic field would have a single d...I'm wondering whether we can solve most of our current problems regarding fields and multifields by introducing a single new `Field` class that
- unifies the current `Field` and `MultiField` classes (a classic field would have a single dictionary entry with an empty string as name)
- is immutable
- can contain scalars or array-like objects to describe field content (maybe even functions?)
If we have such a class we can again demand that all operations on fields require identical domains, and we can still avoid writing huge zero-filled arrays by writing scalar zeros instead.
@reimar, @kjako, @parras please let me know what you think.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/258Branch cleanup2019-05-21T06:55:16ZMartin ReineckeBranch cleanupI'd like to get a better understanding which branches are still used and which ones can be deleted:
- new_los (I'll adjust the code for NIFTy 5)
- new_sampling (@reimar is this still relevant?)
- symbolicDifferentiation (@parras do you w...I'd like to get a better understanding which branches are still used and which ones can be deleted:
- new_los (I'll adjust the code for NIFTy 5)
- new_sampling (@reimar is this still relevant?)
- symbolicDifferentiation (@parras do you want to keep this?)
- yango_minimizer (@reimar ?)
- addUnits (@parras ?)
- theo_master (I guess I'll convert this into a tag)
- nifty2go (is anyone still using this? Otherwise I'd convert it into a tag as well)
@ensslint, any comments?Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/274Restructure DOFDistributor2019-10-17T13:44:44ZJakob KnollmuellerRestructure DOFDistributorHi,
I just want to document the thought to change the DOFDistributor to a BinDistributor and build it analogous to the adjoint numpy bincount function. This should make things more clear and allow for operations on fields of any one-dim...Hi,
I just want to document the thought to change the DOFDistributor to a BinDistributor and build it analogous to the adjoint numpy bincount function. This should make things more clear and allow for operations on fields of any one-dimensional domain. We could get rid of the DOFSpace and change the default to an UnstructuredDomain
Jakobhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/276testing differentiability for complex operators2021-03-08T08:36:30ZReimar H Leiketesting differentiability for complex operatorsThe routine extra.check_jacobian_consistency only checks derivatives in real direction. There are two other interesting cases: differentiability in real and imaginary direction and complex derifferentiability (which is the former with th...The routine extra.check_jacobian_consistency only checks derivatives in real direction. There are two other interesting cases: differentiability in real and imaginary direction and complex derifferentiability (which is the former with the additional requirement that df/d(Imag) = i*df/d(Re)).Reimar H LeikeReimar H Leikehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/286NIFTy grand unification: unify MultiFields and Fields2020-04-07T17:33:33ZMartin ReineckeNIFTy grand unification: unify MultiFields and Fields- all new fields have the internal structure of a MultiField
- a classic "standard" field is represented by a new field with a single key
that is the empty string
- Many of our operators work on part of a DomainTuple (e.g. FFTOperator)...- all new fields have the internal structure of a MultiField
- a classic "standard" field is represented by a new field with a single key
that is the empty string
- Many of our operators work on part of a DomainTuple (e.g. FFTOperator).
Typically this is specified by passing the domain and additionally a "spaces"
argument, which is None, int of tupe of ints.
Since in the future every domain is a "multi-domain", this is no longer
sufficient: the partial domain must now contain an additional string defining
the name of the required field component. This requires an update
(and renaming) of "parse_spaces", "infer_space" etc.
Maybe it's good to introduce a new "PartialDomain" class which contains
* a string containing the desired field component, and
* an integer tuple containing the desired subspaces of that component
- "MultiField" will be renamed to "Field"; "Field" will probably be renamed
to some internal helper class or completely implemented within the new "Field".
- "MultiDomain" will be renamed to ???; "DomainTuple" will probably become
"_DomainTuple", i.e. it should not be directly accessed by external users.
- "makeField" and "makeDomain" become static "make" members of "Field" and
"Domain"Martin ReineckeMartin Reineckehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/288Make convergence tests less fragile2020-03-22T13:06:44ZMartin ReineckeMake convergence tests less fragileThe switch to `numpy`'s new RNG interface has shown that some of our convergence and consistency tests are not very robust: in principle these tests should succeed for any random seed we use during the problem setup, but this is apparent...The switch to `numpy`'s new RNG interface has shown that some of our convergence and consistency tests are not very robust: in principle these tests should succeed for any random seed we use during the problem setup, but this is apparently not the case. We should have a closer look at the problematic tests and fix them accordingly.https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/290Data types for the Grand Unification2020-04-08T18:20:48ZMartin ReineckeData types for the Grand Unification```
Space:
structured or unstructured set of points (current NIFTy's "Domain")
SpaceTuple:
external product of zero or more Spaces (current NIFTy's "DomainTuple")
SpaceTuple = (Space, Space, ...)
SpaceTupleDict:
diction...```
Space:
structured or unstructured set of points (current NIFTy's "Domain")
SpaceTuple:
external product of zero or more Spaces (current NIFTy's "DomainTuple")
SpaceTuple = (Space, Space, ...)
SpaceTupleDict:
dictionary (with string keys) of one or more SpaceTuples
SpaceTupleDict = {name1: SpaceTuple1, name2: SpaceTuple2, ...}
(current NIFTy's "MultiDomain")
Domain:
This is an abstract concept. Can currently be represented by SpaceTuple or SpaceTupleDict
Special domains:
ScalarDomain: empty SpaceTuple
Operator:
- Operators take an Operand defined on an input domain, transform it in some way
and return a new Operand defined on a (possibly different) target domain.
- Operators can be concatenated, as long as the domains at the interface are
identical. The result is another Operator.
Operand:
- Operand objects represent fields and potentially their Jacobians and metrics.
- an Operand object can be asked for its "value" and (if configured accordingly)
its Jacobian. If the target domain of an Operand object is scalar, a metric
may also be available.
- Applying an Operator to an Operand object will always return another Operand object.
class Operator(object):
@property
def domain(self):
# return input domain
@property
def target(self):
# return output domain
def __call__(self, other):
# if isinstance(other, Operand) return an Operand object
# else return an Operator object
def __matmul__(self, other):
return self(other)
class LinearOperator(Operator):
# more or less analogous to the current LinearOperator
class Operand(object):
# this unifies current NIFTy's Field, MultiField, and Linearization classes
@property
def domain(self):
# if no Jacobian is present, return None, else the Jacobian's domain.
@property
def target(self):
# return the domain on which the value of the Operand is defined. This is
# also the Jacobian's target (if a Jacobian is defined)
@property
def val(self):
# return a low level data structure holding the actual values (currently numpy.ndarray
# or dictionary of numpy.ndarrays. Read-only.
def val_rw(self):
# return a writeable copy of `val`
def fld(self):
# return am Operand that only contains the value content of this object. Its Jacobian and
# potential higher derivatives will be `None`.
@property
def jac(self):
return a Jacobian LinearOperator if possible, else None
@property
def want_metric(self):
return True or False
@property
def metric(self):
if self.jacobian is None, raise an exception
if self.target is not ScalarDomain, raise an exception
if not self.want_metric, raise an exception
if metric cannot be computed, raise an exception
return metric
```
https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/291Problematic MultiField methods2021-03-24T09:26:17ZMartin ReineckeProblematic MultiField methodsCurrently, `MultiField` has methods like `s_sum`, `clip`, and many transcendental functions. I'm wondering whether they make any sense: what's the point of computing the sum over all values in several fields ... or computing the sine of ...Currently, `MultiField` has methods like `s_sum`, `clip`, and many transcendental functions. I'm wondering whether they make any sense: what's the point of computing the sum over all values in several fields ... or computing the sine of all field entries?
We currently use `MultiField`'s `norm` property in minimization, but given that the components of the `MultiField` may have vastly different scales, is this actually a clever thing to do? This basically means that we stop minimizing once the field component with the largest values has converged ... not necessarily what we want.
@parras, @pfrank, @reimar, @kjakohttps://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/313Better adjointness tests2020-11-18T19:24:15ZMartin ReineckeBetter adjointness testsFor the gridder paper, @parras and I have been thinking about better criteria for measuring the adjointness of two operators.
In Nifty, we test the adjointness of the operators `Op1` and `Op2` by drawing random fields `a` (living on `Op1...For the gridder paper, @parras and I have been thinking about better criteria for measuring the adjointness of two operators.
In Nifty, we test the adjointness of the operators `Op1` and `Op2` by drawing random fields `a` (living on `Op1.target`) and `b` (living on `Op1.domain`) and testing whether `abs(vdot(a, Op1(b)) - vdot(Op2(a), b))` is "small". But we don't really have a good definition of what "small" means.
Our idea was to compare this expression to `min(|a|*|Op1(b)|, |Op2(a)|*|b|)`. So our reference value is basically the smaller (to be pessimistic) of the two dot products, but with their cosine terms removed, so that we do not run into problems when, for example, `a` is orthogonal to `Op1(b)`.
@reimar, @pfrank, do you think this makes sense?https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/327Improvement: Simplify for const could be more potent2021-05-30T17:20:04ZPhilipp Arrasparras@mpa-garching.mpg.deImprovement: Simplify for const could be more potentThe following script demonstrates that the `simplify_for_const` machinery is not able to efficiently deal with partially constant `MultiField`s.
```python
import nifty7 as ift
import numpy as np
dom = ift.RGSpace(10)
e = ift.VariableCo...The following script demonstrates that the `simplify_for_const` machinery is not able to efficiently deal with partially constant `MultiField`s.
```python
import nifty7 as ift
import numpy as np
dom = ift.RGSpace(10)
e = ift.VariableCovarianceGaussianEnergy(dom, "a", "b", np.float64)
fa = ift.FieldAdapter(dom, "a")
fb = ift.FieldAdapter(dom, "b")
e1 = e(fa.adjoint@fa + fb.adjoint@fb)
print(e1)
inp = ift.from_random(fa.domain)
print(e1.simplify_for_constant_input(inp))
```https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/328What is the correct gradient at zero for `pointwise.unit_step`?2021-08-16T16:58:38ZLukas PlatzWhat is the correct gradient at zero for `pointwise.unit_step`?I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we...I just noticed that the gradient of the pointwise function `unit_step` [is set to be always zero](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L91).
Is that correct, or should we return `np.nan` if the input is exactly zero, like for examples `sign` [does](https://gitlab.mpcdf.mpg.de/ift/nifty/-/blob/4772fce8b032135e39702ffb4b52b33f5deefe20/src/pointwise.py#L67)?https://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/3Move obj.bincount and obj.unique into distributor and make them more efficient.2016-05-26T11:09:09ZTheo SteiningerMove obj.bincount and obj.unique into distributor and make them more efficient.For efficiency, use Allreduce instead of allgather in bincount.
Use `fast-summation` in obj.unique <http://materials.jeremybejarano.com/MPIwithPython/collectiveCom.html#fastsum>For efficiency, use Allreduce instead of allgather in bincount.
Use `fast-summation` in obj.unique <http://materials.jeremybejarano.com/MPIwithPython/collectiveCom.html#fastsum>Theo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/D2O/-/issues/2Add tensor-/outer-dot to d2o2016-05-26T11:09:02ZTheo SteiningerAdd tensor-/outer-dot to d2oTheo SteiningerTheo Steiningerhttps://gitlab.mpcdf.mpg.de/ift/resolve/-/issues/1Implement uniform weighting2021-06-30T17:12:22ZPhilipp Arrasparras@mpa-garching.mpg.deImplement uniform weightinghttps://gitlab.mpcdf.mpg.de/ift/resolve/-/issues/2Bug: calibrator flux is probably computed incorrectly (log10 vs ln vs log2)2021-09-08T11:14:27ZPhilipp Arrasparras@mpa-garching.mpg.deBug: calibrator flux is probably computed incorrectly (log10 vs ln vs log2)Connected to https://github.com/caracal-pipeline/caracal/issues/1354Connected to https://github.com/caracal-pipeline/caracal/issues/1354https://gitlab.mpcdf.mpg.de/ift/nifty/-/issues/338[New feature] Add tensorflow operator2021-10-29T15:38:45ZPhilipp Arrasparras@mpa-garching.mpg.de[New feature] Add tensorflow operatorhttps://gitlab.mpcdf.mpg.de/ift/deepreasoning/-/blob/master/operators/tensorflow_operator.pyhttps://gitlab.mpcdf.mpg.de/ift/deepreasoning/-/blob/master/operators/tensorflow_operator.py