Test cellsToLinkedMultiPolygon for children of pentagon

[ajfriend]

Adds a test that catches a current bug when computing the cellsToLinkedMultiPolygon of a set of children of a pentagon cell.

Parent pentagon: 80ebfffffffffff
Children: 81ea3ffffffffff, 81eabffffffffff, 81eafffffffffff, 81eb3ffffffffff, 81eb7ffffffffff, 81ebbffffffffff

[coveralls]

coverage: 98.825%. remained the same
when pulling 61fc849 on aj/loop_bug
into 9cc20fd on master.

[isaacbrodsky]

does this happen for any set of res 1 children of a res 0 pentagon?

[ajfriend]

See the notebook here: https://gist.github.com/ajfriend/5594157463b88eb8d4cae35705657d8d

At res 1, it only happens for 80ebfffffffffff. (but it also happens for res 2... let me get a list)

[ajfriend]

At res 2, exactly two pentagons of the 12 do not work: 8009fffffffffff and 80c3fffffffffff

[heshpdx]

In case it helps, I ran make test with this branch on two aarch64 Ampere machines running linux, and everything passed including testCellsToLinkedMultiPolygon_test95. I tried on Altra and AmpereOne.

[isaacbrodsky]

I suspect this has to do with

h3/src/h3lib/lib/vertexGraph.c

Line 76 in b355c9d

return (uint32_t)fmod(fabs((vertex->lat + vertex->lng) * pow(10, 15 - res)),

For example, changing it from

    return (uint32_t)fmod(fabs((vertex->lat + vertex->lng) * pow(10, 15 - res)),
                          numBuckets);

to

    //                                                               ||
    //                                                               vv
    return (uint32_t)fmod(fabs((vertex->lat + vertex->lng) * pow(10, 16 - res)),
                          numBuckets);

seems to resolve this particular error case. I think we had considered using vertex indexes for this algorithm before, but hadn't done so. If I recall right the performance wasn't much different (wasn't better anyways). I think @nrabinowitz did those tests so I'll let him chime in. Do we still have that on a branch we could resurrect?

[nrabinowitz]

I think we had considered using vertex indexes for this algorithm before, but hadn't done so. If I recall right the performance wasn't much different (wasn't better anyways). I think @nrabinowitz did those tests so I'll let him chime in. Do we still have that on a branch we could resurrect?

I'm... not sure, I'll need to check. It is possible my WIP branch (now several years old) went away with an old work laptop :/.

[nrabinowitz]

I think we had considered using vertex indexes for this algorithm before, but hadn't done so. If I recall right the performance wasn't much different (wasn't better anyways). I think @nrabinowitz did those tests so I'll let him chime in. Do we still have that on a branch we could resurrect?

I'm... not sure, I'll need to check. It is possible my WIP branch (now several years old) went away with an old work laptop :/.

Does not seem to be in my remote GH branches. I think it's unlikely I can access the code any more, sorry about that.

[grim7reaper]

Not sure if it could help to implement it in C, but the h3o implementation is based on Vertex indexes.

IIRC, it wasn't too complicated to adapt the algorithm, the only tricky part being the "distortions" vertices that needs to be added and cannot be represented by the vertex indexes, which only encode topological vertices. I got sth working at the end of the day, but not very satisfied of the approach so there may be room for improvements.