NIFTy merge requestshttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests2024-01-18T16:02:13Zhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/875Draft: Static Newton CG2024-01-18T16:02:13ZGordian EdenhoferDraft: Static Newton CGGordian EdenhoferGordian Edenhoferhttps://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/909Draft: Experimental Updates to MF plotting branch2024-01-25T21:04:26ZLukas PlatzDraft: Experimental Updates to MF plotting branchhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/868Cfm demo sliders2024-01-12T18:36:19ZDavid GorbunovCfm demo slidersiPython Notebook visualizing how the typical CFM parameters impact one drawn examplary sample. @gedenhofiPython Notebook visualizing how the typical CFM parameters impact one drawn examplary sample. @gedenhofhttps://gitlab.mpcdf.mpg.de/ift/nifty/-/merge_requests/854Gauss markov processes2024-02-06T13:06:50ZVincent EberleGauss 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/847Draft: Multi-Frequency and `HPSpace` Plotting refactor2024-01-23T11:40:31ZLukas 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/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 padder2024-01-23T11:34:15ZLukas 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 hierarchy