Add the dice metric to UMAP

[beckernick]

This PR:

• Adds support for metric="dice" to UMAP
• When using this metric, UMAP expects Boolean inputs

Closes #5129

[cjnolet]

We can see if CI passes on this but I don't believe our dense pairwise distance API is currently able to compute Dice distance. This is a really trivial computation to do w/ any primitive that's capable of computing euclidean, though. It just requires the dot product and l1 norms:

value_t q_r_union = q_norm + r_norm;
value_t dice      = (2 * dot) / q_r_union;
bool both_empty   = q_r_union == 0;
return 1 - ((!both_empty * dice) + both_empty);

Let me know if this is something we should prioritize.

[beckernick]

This test passed for me locally before I put this PR up, but your point is well taken as the dense pairwise distance API doesn't support this currently. The existing machinery seems to handle some but not all of the behavior.

#5129 (comment)

[cjnolet]

I'm honestly still scratching my head at how this could be working w/ dense inputs, which is making me wonder if we're getting a false positive in the passing test. The FAISS brute-force API, which we're still using at the present time for non-L2 (and non-haversine) distances, doesn't support dice distance at all.

[beckernick]

Sounds like we should table this PR until we better understand what's happening. Unless others disagree, will close this PR.

[csadorf]

@cjnolet I suggest we schedule this for 23.04.

[bdice]

@dantegd @beckernick Can we close this in favor of #5943?