compute neighbours within a discrete ring

[keewis]

• towards searching for neighbours in the nth-ring around the center cell #13
• extends 6c83b90

I've tried wrapping the four loops from 6c83b90 in a loop around rings, which mostly gives me the same results as my own implementation (minus the ordering within a ring, which I don't care about).

If this is something you'd be fine with merging, I'll need some help with updating the test.

I'm mostly python-based, so I wrote a wrapper package that allows me to compare results (I do plan on submitting that code to cds-healpix-python, but for now the separate package allows me to iterate faster). In the future, that package will be used for geo-specific extensions of healpix, like mapping ellipsoidal coordinates onto an authalic sphere, and to allow me to test new functions a bit faster.

[fxpineau]

@keewis,
Instead of changing the code of neighbours_in_kth_ring, would you add a method k_neighbours or kth_neighbours_matrix (or any other better name).
(I plan to test the new method pushing in a vec the result of neighbours_in_kth_ring for k in 0..=k, , and post-sorting it).

Also, I known the difference will be negligible, but to fit with the code style, and since: 1: I don't know the cost of pow(2) and 2: I am not sure the compiler replaces 2 * k by k << 1, would you replace:

(2 * (k  as usize) + 1).pow(2)

by

let k = k as usize;
( (k*(k + 1)) << 2 ) | 1 // = (2k+1)^2

[keewis]

Also, I known the difference will be negligible, but to fit with the code style

sure, I just would have been able to come up with that myself ^^

Instead of changing the code of neighbours_in_kth_ring, would you add a method k_neighbours or kth_neighbours_matrix (or any other better name).

While we're on the subject of naming, would it make sense to call the existing function neighbours_on_kth_ring to make it a bit more apparent that it only returns the pixels on the boundary? Or does the word "ring" already carry that meaning for you?

The new method would be an extension of the neighbours so we could also extend that, with a default of k=1 (but your choice, a new method like neighbours_within_kth_ring, kth_ring_neighbours or, following h3ronpy's terminology, neighbours_disk would be fine with me, as well).

I plan to test the new method pushing in a vec the result of neighbours_in_kth_ring for k in 0..=k, , and post-sorting it

feel free to push to this branch (if I remember correctly, you can do that by adding my fork as a new git remote and fetch it, after which you can check out the branch and push to the remote).

[keewis]

however, if I'm reusing the existing neighbours_in_kth_ring it will take up more memory than the current implementation. Would you mind if I moved the main logic of the method to a helper method? Something like the path_along_cell_side_internal method you already have.

Edit: the recent commits implement this, plus some documentation changes.