Closed gliderkite closed 2 weeks ago
Oh and if you could contrive a test that fails using the old algorithm but passes now, that would be useful…
Oh and if you could contrive a test that fails using the old algorithm but passes now, that would be useful…
That would be tricky to do, because we would need to generate a huge route, store it somewhere so that it can be accessed locally and on CI to run tests. If you have suggestions or prior examples on how to do this as part of this repo (not sure if you already use git lfs, or have other tests that read from test resources, eg include_str
, etc), I will be happy to add this.
Oh and if you could contrive a test that fails using the old algorithm but passes now, that would be useful…
That would be tricky to do, because we would need to generate a huge route, store it somewhere so that it can be accessed locally and on CI to run tests. If you have suggestions or prior examples on how to do this as part of this repo (not sure if you already use git lfs, or have other tests that read from test resources, eg
include_str
, etc), I will be happy to add this.
Ah, in that case probably not worth the hassle.
Ah, in that case probably not worth the hassle.
I can create a deterministic test where we generate two very big LineString
stored in memory to then compute the Frechet distance. We are not interested in the result, just that the test completes without panicking. This test will fail with the current implementation (but pass with the new one). If this sounds good to you I can add it as part of this PR.
If this sounds good to you I can add it as part of this PR.
If you have time / capacity, that would be great.
[x] I added an entry to
CHANGES.md
if knowledge of this change could be valuable to users.This PR is due to the fact that when using the
frechet_distance
methods on our tools with long routes (200km+) we were not able to run it due tofatal runtime error: stack overflow
.This patch includes a new linear implementation (inspired from here) that removes recursion and allows to avoid the stack overflow fatal errors, while improving overall performances (~70% faster when testing 1000 10km-long routes).