NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2020-04-09T11:38:12Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/444WIP: [GU] Demonstrate new class hierarchy2020-04-09T11:38:12ZMartin ReineckeWIP: [GU] Demonstrate new class hierarchyhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/595Draft: Fft interpolator2021-02-26T16:24:26ZPhilipp Arrasparras@mpa-garching.mpg.deDraft: Fft interpolatorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/613WIP: The definitive "more derivatives" merge2021-05-19T09:14:29ZMartin ReineckeWIP: The definitive "more derivatives" mergeI propose to keep this MR, remove the other two derivatives-related MRs, and remove the "more_derivatives" branch.
@parras, @pfrank, OK?I propose to keep this MR, remove the other two derivatives-related MRs, and remove the "more_derivatives" branch.
@parras, @pfrank, OK?https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/640Draft: More restrictive scaling operator2021-06-11T16:18:00ZPhilipp Arrasparras@mpa-garching.mpg.deDraft: More restrictive scaling operatorhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/551WIP: Add HMC implementation2021-07-08T10:26:58ZPhilipp Arrasparras@mpa-garching.mpg.deWIP: Add HMC implementationhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/671Draft: Fix gradients of `clip` and `unitstep`, add `softclip` and `leakyclip`2021-08-16T15:13:34ZLukas PlatzDraft: Fix gradients of `clip` and `unitstep`, add `softclip` and `leakyclip`See #328 for context.
This MR adds test for full coverage of `src/pointwise.py`.See #328 for context.
This MR adds test for full coverage of `src/pointwise.py`.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/651WIP: Generalized matrix product and a fix in endomorphic MatrixProductOperator2021-08-16T17:53:00ZNeel ShahWIP: Generalized matrix product and a fix in endomorphic MatrixProductOperatorI added a linear matrix multiplication operator that generalizes the endomorphic MatrixProductOperator. The output matches that of the endomorphic operator in case of an endomorphic application.
The target domain/domain tuple of the val...I added a linear matrix multiplication operator that generalizes the endomorphic MatrixProductOperator. The output matches that of the endomorphic operator in case of an endomorphic application.
The target domain/domain tuple of the valid shape should be specified by the user, but I kept a standard RGSpace of the valid shape as the default.\
Below is an example of an application.
dtuple = DomainTuple.make(((RGSpace(10),RGSpace(20),RGSpace(30),RGSpace(40)))\
spaces = (1,3) (apply only to 2nd and 4th spaces of domain)\
matrix = np.ones(shape=(5,15,25,20,40))\
matop = GeneralMatrixProduct(dtuple,matrix,spaces,target=None)
According to the operator's convention,\
target_shape = (10,5,30,15,25)\
(since dtuple.shape = (10,20,30,40), the 20,40 axes are summed over, and to comply with the endomorphic MatrixProductOperator the 10,30 axes retain their positions and remaining axes of the matrix are filled in order)\
matop.target = DomainTuple.make(RGSpace(shape = target_shape, distances = default, harmonic = False))\
(unless a domain or DomainTuple with shape = target_shape is passed as the target)\
returns Field.from_raw(matop.target, np,tensordot of matrix and field summed over appropriate axes)
I tested the operator's working on the example above, and that it coincides with the endomorphic MatrixProductOperator when the latter is applicable. Would this be a useful operator, and what else in it can be tested or changed?
The second change is in the endomorphic MatrixProductOperator, I fixed its functionality for application to a >1 dimensional domain (say an RGSpace(shape=(5,15,25))). The previous version uses np.dot instead of np.tensordot, so due to default axis convention in np.dot it doesn't work when more than one axes are to be summed over. I don't think this was intentional because the operator doesn't throw an error until it is applied to a field over such a domain.
There is one last change in the docstring of the matrix product operator. It has a line saying `If DomainTuple it is assumed to have only one entry`, which I think is misleading because I can apply it to a domain tuple with many subspaces like the example above. I changed the line to `If Domain it is assumed to have only one subspace`, which is what I observed.
@gedenhof , can you have a look at this?https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/698Draft: Add code formatter2022-05-30T13:30:02ZPhilipp Arrasparras@mpa-garching.mpg.deDraft: Add code formatterOpen questions:
- Which order makes most sense for CI?
- formatting check -> tests -> demos
- tests -> formatting check -> demos (I think I prefer this one)
- tests -> demos -> formatting checkOpen questions:
- Which order makes most sense for CI?
- formatting check -> tests -> demos
- tests -> formatting check -> demos (I think I prefer this one)
- tests -> demos -> formatting checkhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/774merge formatted NIFTy source2022-05-30T14:41:34ZLukas Platzmerge formatted NIFTy sourcehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/612More flexible and efficient field zero padder2022-09-16T12:10:00ZLukas PlatzMore flexible and efficient field zero padderUpdate on !528Update on !528https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/786Draft: Improve demos2022-11-07T10:36:58ZPhilipp Arrasparras@mpa-garching.mpg.deDraft: Improve demos@veberle @jroth @gedenhof@veberle @jroth @gedenhofPhilipp Arrasparras@mpa-garching.mpg.dePhilipp Arrasparras@mpa-garching.mpg.dehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/820Fix `ift.Field.vdot` breaking with np.uint32 and other integer types2022-12-09T21:42:50ZLukas PlatzFix `ift.Field.vdot` breaking with np.uint32 and other integer typesHi Martin,
I just stumbled over `ducc0.misc.vdot` not multiplying doubles and integers, which is required in the `PoissonianEnergy`. It seems Philipp Arras did so, too, a while ago, but unfortunately his mitigation was incomplete, as it...Hi Martin,
I just stumbled over `ducc0.misc.vdot` not multiplying doubles and integers, which is required in the `PoissonianEnergy`. It seems Philipp Arras did so, too, a while ago, but unfortunately his mitigation was incomplete, as it did only catch `np.int64`s.
Is there a `double*integer` `vdot` in `ducc0` that we could call instead of the conversion?
While at it: I noticed [`ift.PoissonianEnergy`](https://ift.pages.mpcdf.de/nifty/_modules/nifty8/operators/energy_operators.html#PoissonianEnergy) enforces integer-typed data fields (sensible for Poisson counts), but then passes them directly to `vdot`, triggering an `int->double` conversion in each application. Should we cast the data field to `double` in the initialization of `PoissonianEnergy` after the integer check to avoid this?
Cheers,
LukasMartin ReineckeMartin Reinecke