Add notion of sampler

[luisfpereira]

Inspired by #9, this PR brings in the notion of sampler.

Notice this commit was initially done in luisfpereira@415cd8d.
Nevertheless, I believe this code is mature enough to merge (maybe after adding a notebook showing how this work?), whereas we still have a lot of work to do with #9.

Still need to address a couple of comments I've left in the code.

[gviga]

Hi @luisfpereira,
I was looking at and testing your implementation and I have some comments.

1. The major issue that I have is our choice to separate the notion of a Sampler and the NearestNeighbour Finder. I think we already discussed and if I remember correctly this is about the idea of a Continuous Sampler. However, I think that we need first to assume that a sampler is Discrete, and in this case, it is useful to have both vertices and indices as output, while separating the two can be expensive since a lot of methods naturally return both. I think a discussion on this needs to be made and maybe we will have a clearer idea after the implementation of other Samplers.

2. Particularly to this issues, i have wrote a notebook to explain the sampling and it is clear that with the code as it is now, we cannot have access to both vertices and indices without explicitly recover them.

Besides that, it seems that everything is working,

[luisfpereira]

Thank you for the comments and notebook @gviga.

1. The major issue that I have is our choice to separate the notion of a Sampler and the NearestNeighbour Finder. I think we already discussed and if I remember correctly this is about the idea of a Continuous Sampler. However, I think that we need first to assume that a sampler is Discrete, and in this case, it is useful to have both vertices and indices as output, while separating the two can be expensive since a lot of methods naturally return both. I think a discussion on this needs to be made and maybe we will have a clearer idea after the implementation of other Samplers.

Yes, the distinction is between continuous vs discrete.

So, I'm considering that doing mesh.vertices[indices] has a negligible cost (NB: maybe this is where we disagree; we may need to measure this). With this assumption, what would be the advantage of returning both indices and vertices?

My main goal is to have a compatible API for the DiscreteSampler and ContinuousSampler (think of those as abstract classes that we haven't added yet).
When we do .sample, both should return the point representation of a point belonging to a shape, i.e. i) if we are looking to a shape as a discrete object it will return indices (of vertices or faces, depending on the discrete object we're considering), ii) if we are looking to a shape as a continuous object, then it will return an array of vertices.

2. Particularly to this issues, i have wrote a notebook to explain the sampling and it is clear that with the code as it is now, we cannot have access to both vertices and indices without explicitly recover them.

What would be a use case of this feature in the notebook?

[gviga]

Yes, you are right,
now I understand.
We can say that each Continuos Sampler induces a Discrete sampler performing NNsearch in the discrete surface. In this sense, the NearestNeighbourIndexSamplerFunction would be defined only for continuous samplers. Maybe from this idea, we can find its new name.

I agree that calling vertices[indices] is not expensive and it's the way to go for now.

Thank you @luisfpereira

[gviga]

I ahve checked the code and it seems fine to be, at least the general structure, also recalling our old discussion. However, I believe that some notation can be changed (also why don't we introduce here the notions of continuous and discrete sampler?)

Moreover, it would make sense to add a farthest point sampling implementation without calling pyFM, I can do that in the future, but maybe @GiLonga has already some implementations

[gviga]

Please change this name

[gviga]

Just IndexSampler ?

[gviga]

Is this tested on the sampling meshes notebook?

[luisfpereira]

Thanks for the contributions and discussion @gviga and @GiLonga.

Latest updates before merging:

• NearestNeighborsIndexSampler -> VertexProjectionSampler: at the end this projects coordinates to the closest vertex

• FpSampler -> FarthestPointSampler

• PyfmFpSampler -> PyfmEuclideanFarthestVertexSampler: may be a mistake using Vertex instead of Point, but in my head this suggests we sample discretely and not continuously. Same for you? Wondering if we should change FarthestPointSampler to FarthestVertexSampler as well

• updated the notebook

The behavior is more and less unchanged.
Only design doubt is if we should pass shape at init or at sample, because some methods may have a high startup cost. The current design seems more natural for now.

Merging now. As usual, let's address any comment in a new PR.