fugw

fugw copied to clipboard

After a few iterations of the dense/sparse barycenter solver, NaNs appear in the computation of the barycenter features. This is due to zero div error in the line: ``` acc...

pbarbarant

Hi, I think something may be wrong when computing the mapped result after getting matrix pi. please see the [transform code](https://github.com/alexisthual/fugw/blob/main/src/fugw/mappings/dense.py#L338) from line 338 to 342 in fugw/src/fugw/mappings/dense.py ```python pi.T...

TuDou-PK

[FEAT] Add coarse-to-fine barycenter estimation

7

Implements coarse-to-fine estimation of barycenters with sparse transport plans. - [x] Docstrings - [x] Unit tests

pbarbarant

[BUG] Remove res["pi"].detach().cpu()

6

In ``fugw.mapping`` : ``` # Store variables of interest in model self.pi = res["pi"].detach().cpu() ``` Causes problems when dealing with barycenters as the transport plans get detached before the next...

pbarbarant

As discussed with @bthirion, the cost matrix should be factored via Nystroem approximation for dense mappings as it is the case with the sparse solvers. This should greatly improve time/memory...

pbarbarant

Following #50, examples that contain the dense mapping now longer compile as they pipe in the whole cost matrix instead of the factored embedding. Examples include: ``` 01_brain_alignment/plot_1_aligning_brain_dense.py 00_basics/plot_1_dense.py 02_miscellaneous/plot_3_memory_usage_callback.py...

pbarbarant

[FEAT] Factor cost matrix in dense case

2

Solves #49 . Dense mappings now use Nystroem approximation by default for the cost matrix. - [x] Fixed dense solver/mapping - [x] Adapted coarse-to-fine procedure - [ ] Adapt examples...

pbarbarant

Add examples of: - Dense barycenters on `fsaverage3` - Sparse barycenters on `fsaverage5` Probably on Haxby/Oasis datasets.

pbarbarant

I agree, this concatenation of parameters is difficult to understand. It is somewhat consistent across solvers, but I think we should flatten these variables. Once again, I think this would...

bthirion

I agree, most functions in `solvers/utils.py` are not meant to be public (because they are called through `fugw.mappings` instances, which themselves call `fugw.solvers` instances). I added a docstring, and suggest...

bthirion