kodonnell
kodonnell
Faster tuning means: - faster testing/development - easier to consider a larger search space - happy users Some ideas: ### Timeout For example, while tuning xgemm, the fastest kernels run...
### Missing feature The pretrained model, or documentation about it. ### Justification It'd be useful to have the pretrained model detecting people (as in the image in the readme). -...
Does anyone else see a similar latency to below? I've tested on two machines, and this was the faster. ``` $ time docker run --rm -it --pid host jess/htop echo...
On my env (fast laptop but WSL - which doesn't play nice with git) the current `prompt_git` was taking around 100ms, which was noticeable. Parsing `git status` is kinda nasty,...
Would this be in scope for this project? Hardware issues aside, I imagine straightforward configurations (e.g. 2x2 screens of the same size) would be pretty trivial to code. Of course,...
I won't write too much here as there's a bunch in the readme.md and you should be able run the demo code easily to see what it's talking about. But...
As discussed starting [here](https://github.com/graphhopper/map-matching/pull/87#issuecomment-272345734), we may want to allow users to be prevent all filtering (and hence include all input points in the map match result). A second possible use...
As discussed [here](https://github.com/graphhopper/map-matching/pull/83#issuecomment-266190993) it'd be good to have a way of testing how 'good' our map matching is by comparing it with known results. (I.e. our map-matching on a GPX...
Currently, our transition probability is higher for transitions which are close to a straight line. I see a few problems with this: - it's possible that the the wrong transition...
See [here](https://github.com/graphhopper/map-matching/pull/87#pullrequestreview-12396714). To summarize, finding candidates on the fly (i.e. at each step of the viterbi sequence) would be beneficial as - it's probably cleaner - when first reading the...