NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2023-06-07T13:56:41Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/855add hashing for MPI equality check for fields in optimize_kl2023-06-07T13:56:41ZJakob Knollmuelleradd hashing for MPI equality check for fields in optimize_klchecking MPI equality of large fields explicitly can crash and lead to segmentation faults, that's why we introduced the possibility to just compare hashes. We didn't add it to the check in the `_single_value_sample_list` in optimize_kl....checking MPI equality of large fields explicitly can crash and lead to segmentation faults, that's why we introduced the possibility to just compare hashes. We didn't add it to the check in the `_single_value_sample_list` in optimize_kl.py and I run into an issue there.https://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/854Draft: Gauss markov processes2023-05-24T10:22:18ZVincent EberleDraft: Gauss markov processes@pfrank I also added the IWPProcess from Resolve and added P.Arras as author.
The interface is not the same, but I tried to extend it a bit to be able to use it for the spectral models.
If you have time for a short review, that would be...@pfrank I also added the IWPProcess from Resolve and added P.Arras as author.
The interface is not the same, but I tried to extend it a bit to be able to use it for the spectral models.
If you have time for a short review, that would be great.
PS: There is no rush to merge this soon.Vincent EberleVincent Eberlehttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/852Extract values form field at given indices2023-05-25T09:14:48ZJakob RothExtract values form field at given indicesExtracts values from a field at given indices and puts them into an unstructured field. Useful when some indices appear twice (e.g. several measurements at the same location).Extracts values from a field at given indices and puts them into an unstructured field. Useful when some indices appear twice (e.g. several measurements at the same location).Philipp FrankPhilipp Frankhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/851Rethink NIFTy.re.Field (Field -> Vector)2023-05-19T15:21:38ZGordian EdenhoferRethink NIFTy.re.Field (Field -> Vector)Gordian EdenhoferGordian Edenhoferhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/850Rethink sampling2023-05-02T14:02:49ZGordian EdenhoferRethink samplingGive more control over how to map the drawing of samples to the user. In doing so restructure the way minimization works.Give more control over how to map the drawing of samples to the user. In doing so restructure the way minimization works.Gordian EdenhoferGordian Edenhoferhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/847Draft: Multi-Frequency and `HPSpace` Plotting refactor2023-05-09T16:38:04ZLukas PlatzDraft: Multi-Frequency and `HPSpace` Plotting refactorHi @pfrank @mtr @wmarg @veberle,
since I promised Margret to make the multifrequency plotting routine improvements created for the Fermi paper available for general usage, I took two days to refactor the multifrequency plotting routines...Hi @pfrank @mtr @wmarg @veberle,
since I promised Margret to make the multifrequency plotting routine improvements created for the Fermi paper available for general usage, I took two days to refactor the multifrequency plotting routines of NIFTy.
Following the philosophy of "`nifty.Plot()` is only a rough helper, not supposed to be all-powerful", I extracted the multifrequency-to-RGB conversion into a separate class and polished its interfaces, such that people can use it in their own plotting routines.
As Philipp Arras and Vincent Eberle had created a helper to also support Hammer projections (alongside Mollweide) a while ago, I took the sphere-to-2d projection functionality out of `nifty.Plot()` into a separate function, that now supports both Mollweide and Hammer projection. It is now also usable in external plotting scripts.
I have added docstrings and a few tests for new functionality.
Also, I think I discoverd a bug in the multifrequency color mapping - a corresponding merge request into this branch follows in a second.
@mtr: As I belive you to be the original author of the mf to rgb mapping, could you maybe/please have a look if I made any stupid mistakes?Philipp FrankPhilipp Frankhttps://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/774merge formatted NIFTy source2022-05-30T14:41:34ZLukas Platzmerge formatted NIFTy sourcehttps://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/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/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/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/595Draft: Fft interpolator2021-02-26T16:24:26ZPhilipp Arrasparras@mpa-garching.mpg.deDraft: Fft interpolatorhttps://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/444WIP: [GU] Demonstrate new class hierarchy2020-04-09T11:38:12ZMartin ReineckeWIP: [GU] Demonstrate new class hierarchyhttps://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?