Add metrics for meshes

[luisfpereira]

Inspired by #9, this PR brings in the first metrics for meshes (very preliminary design!).

Why? tldr: modularization!

An important step of scalable FMaps (Magnet, 2023) consists of approximating the Laplace-Beltrami eigenbasis.

An important step for approximating the Laplace-Beltrami eigenbasis is the construction of local basis functions (Nasikun, 2018).

An important step for the construction of local basis functions is the computation of distances between sampling points and the original mesh.

There's multiple ways of computing distances given a mesh.
I'm providing a common interface to compute those distances.
For now, I've implemented the EuclideanMetric and the SingleSourceDijkstra. Variants of the second are low hanging fruits. (Magnet, 2023) implements a variant of SingleSourceDijkstra.

I hope this thread helps understanding a bit better the modularization steps I've started taking on scalable refactoring (luisfpereira@51f6f50).

Of course I'm justifying this PR with scalable because it is the implementation we're pursuing at the moment requiring this, but needlessly to say these metrics will find a lot of applicability (e.g. the distance-based samplers we're discussing yesterday).

Other goals this PR will lead to: implementation of (Nasikun, 2018).

Still a draft because I need to think a bit more about the design and add other metrics.
Looking for your feedback @GiLonga, @gviga.

[luisfpereira]

edge_graph instead? maybe not, to keep code within class flexible.

[gviga]

Can we implement it?

[gviga]

I don't remember at what point we were with this code, however, this is of primary importance, because we need an evaluation module for the maps and so a distance computation. @luisfpereira @GiLonga are you on this?

[gviga]

I don't really like the naming of this functions.
Why dist is the distance from a single point (maybe we can call it dist _from,
_dist_no_target_single can be _distance matrix? since in the end is a matrix.
@luisfpereira can you elaborate more on these choices?

[gviga]

Me and @GiLonga are going to finish this pull request, do you agree?
@luisfpereira

[gviga]

Hi @luisfpereira ,
I've made some comments about this PR. In particular:

1. I've implemented the _edges function, avoiding to call pyfm
   2)I'vee implemented dist_matrix() functions. These functions are usefull in functional maps to store the full distance matrix of shapes that can be useful when evaluating correspondences.
2. I've implemented the euclidean metric without a target.

Now I understand the logic behind this code. However, I was wondering: the code tofinde geodesic distances is quite slow if we are considering a lot of source points since we are looping over each source point,.Do you know if there is a way to implement a faster version? Should we create another metric class in order to do so?

However, for the moment we have all the code needed to evaluate the correspondences.

[gviga]

Hi @luisfpereira ,
After our discussion last week, I've changed the name of SingleSourceDijkstra, creating a single Dijkstra class that can compute both single souce distances or distance matrix in an efficient way. As you can see, this function uses Adjecency list and Scipy shortest path solver to compute the distance matrix. Let me know if you have any comment on this implementation

[luisfpereira]

@gviga, a couple of comments regarding latest commits:

1. FinitePointSetMetric: a metric on a finite set. has dist_matrix and dist_from_source. I believe these methods do not make sense if the set is not finite, hence the name

2. dist always requires point_a and point_b. moved point_b=None to dist_from_source.

3. EuclideanMetric -> VertexEuclideanMetric: before was not representing what we've implemented

4. Dijkstra -> GraphShortestPathMetric (and KClosestGraphShortestPathMetric)

5. dist_matrix of GraphShortestPathMetric is using nx instead of scipy. this implementation is extremely slow, but scipy one does not seem consistent with distances given by dist. we need to verify this, as this method is currently useless.

We may want to make a GraphShortestPathMetric only using scipy?

I'm merging now so we can move on with other PRs. But I'll be coming back to this soon to at least add tests and a notebook. Again, feel free to disagree and please open a PR/issue with suggestions if the case.