> It's baffling that so many people insist this is not happening, or that it's too computationally expensive.
If i am not mistaken - this paper seems to look at explicit "Smart Speaker interactions" - not passive background listening which is what I believe you are alluding to.
Not arguing that I am saying that latter does/doesn't happen - but just that this paper is not proof of it. And there is a big difference.
H3 doesn't guarantee a child hexagon at level N+1 strictly belongs to 1 parent at level N. S2 is built on this exactly this primitive, but then struggles with cell-size variability across latitude.
This lack of strict hierarchy seeming negates alot of practical benefits (e.g tree data-structure that maps well to sharding and aggregation). Whilst I haven't dug into H3 that much from a practical sense - but I have build several Geospatial systems with S2 that exploit this strict hierarchy - I can't imagine this isn't a huge pain-point with H3.
Would be interested to hear of how these approximate cases are handled at Uber or in any practical setting.
I typically only rely on the logical parent/child relationship between cells, and containment there is strict even if geometric containment is only approximate. The logical relationship is useful, for example, in providing a compact representation when you have a large collection of cells: https://h3geo.org/docs/highlights/indexing
I'll use the approximate geometric containment mostly just to get a rough idea of where cells are. For example, in the plots of cells covering California in the link above, plotting the "compacted" cells is still visually useful, even if you aren't seeing the exact boundaries of the uncompacted set it represents.
How do you typically leverage exact geometric containment with S2 in your applications? I'm curious because I work on H3 and h3-py (https://uber.github.io/h3-py), and maybe there's something we can build (or it already exists) that would fit your use case.
One example I am trying to wrap my head around is if you have two adjacent polygons (say California and Oregon) and perform an interior cover of both with variable hex sizes.
It seems possible that a child hex might actually slip outside the boundary - since the 7 children don't fit squarely inside the parent (no pun intended).
In S2 it guaranteed that any child cell of the S2CellUnion representing that cover is strictly inside the polygon bounds.
This doesn't seem to be guaranteed in H3. I could have a location that is in Oregon, that depending on the child resolution could slip into to Oregon instead of California - or vice versa?
Now imagine an business application where a user must be mapped to one of 2 physically exclusive regions, (for say pricing, legal, compliance reasons) it seems like exact containment is preferred.
Perhaps there is another way to employ H3 that would mitigate this?
I tried to use this a few years ago but found the tooling inadequate for my use case. It wasn’t supported well enough across the various libraries involved in ingestion, storage and web client rendering. I’d love to hear from anyone using Hierarchical Triangular Mesh in the wild to learn more about how they made it work.
Fractals are super efficient (a binary tree is a fractal used for search) so I feel like I prefer S2 in this case. How are fractals being used in H3, and could other cell geometry be more efficient than the space-filling curve fractal used in S2?
Snap Inc | Distributed Systems + Recommendation Systems | Mountain View, LA, Seattle ONSITE | https://snap.com/en-US/jobs
My team is currently building out Snaps' ML Recommendation systems which powers Snap's power Growth, Content and Ads recommendation/ranking. Our services serve billions of requests a day evaluating trillions of ML predictions.
We have several roles open across multiple sub-teams
- Backend + Distributed systems - Scalable infrastructure for services that handle billions of requests per day
- Information Retrieval - search and retrieval over several 100M+ corpus
- Performance - C++, Go, Java expertise to optimize latency and compute cost of our services (tens of millions dollars, hundreds of thousands compute cores)
Feel free to reach to me directly at samir.ahmed@snapchat.com (or via linkedin link in profile) if you are interested!
Snap Inc | Distributed Systems + Recommendation Systems | Mountain View, LA, Seattle ONSITE | https://snap.com/en-US/jobs
My team is currently building out Snaps' ML Recommendation systems which powers Snap's power Growth, Content and Ads recommendation/ranking. Our services serve billions of requests a day evaluating trillions of documents and predictions.
We have several roles open across multiple sub-teams
- Backend + Distributed systems - Scalable infrastructure for services that handle billions of requests per day
- Information Retrieval - search and retrieval over several 100M+ corpus
- Performance - C++, Go, Java expertise to optimize latency and compute cost of our services (tens of millions dollars, hundreds of thousands compute cores)
Feel free to reach to me directly at samir.ahmed@snapchat.com (or via linkedin link in profile) if you are interested!
I have used Numi for several years - and versus Alfred/Google variants i have found Numi to be incredibly helpful for most back of the hand calculations.
I have yet to find an alternative that is more convenient
1) Configurable keyboard shortcut to bring this up
2) Good units/percentages/bytes support
3) Variable assignments / custom functions
4) Long History
Snap Inc ML Infrastructure | ML Infrastructure Engineer | Mountain View, LA, Seattle ONSITE | https://snap.com/en-US/jobs
My team is currently building out Snaps' ML Platform which powers Snap's power Growth, Content and Ads recommendation/ranking. The platform handles the training of thousands of ML Models - evaluating trillions of predictions per day.
We have several roles open
- Performance engineers with C++/CUDA performance expertise to optimize and scale our inference
- Distributed systems infrastructure expertise to scale our 'feature store'
- Recommendation system infrastructure experience to power our retrieval and ranking services for Ads, Content and Growth objectives
Feel free to reach to me directly at samir.ahmed@snapchat.com (or via linkedin link in profile) if you are interested
Snap Inc ML Platform | ML Infrastructure Engineer | Mountain View, LA, Seattle ONSITE | https://snap.com/en-US/jobs
My team is currently building out Snaps' ML Platform - handling the training of thousands of ML Models and evaluating trillions of predictions per day.
In particular we are looking for engineers with C++/CUDA performance and/or distributed systems expertise to optimize and scale our ML inference services and feature store.
Feel free to reach to me directly at samir.ahmed@snapchat.com
(or via linkedin link in profile) if you are interested
Contrasting to Github PR its a better process but really only a marginal impact on developer productivity.
When i was there - Codeflow had the following feature
- Multiple reviewer states ... accepted/reviewing/awaiting changes/decline to review/reject change.
- Multiple comment states ... pending, won't fix, fixed etc.
- Iterations based code review flow - after you review - you come back easily view the next iteration (relative diff) - you can really compare back and forth and track comments through iterations - github tends to loose comments through commits
- Support for bots to comment like stylecop etc
Codeflow workflow felt like an MS-Office application like Word or Outlook compared to Github
- Heavy UI based workflow with no API/commandline counterpart sometimes
- Desktop app - not website
- Lots of knobs/states
- Very easy to work back and forth in the UX
I agree with an earlier comment however - the UX was pretty ugly - the workflow account for lots of states Github doesn't but there is a nice linear flow to the progression of a github conversion that (at least at the time i was there) . IIRC it was a managed .NET - WPF application which are kindy clunky - not as nice as a website with clear links etc.
At least as of November 2018 (when I left), everything you said was still true. However!
CodeFlow was also integrated into VSTS, whose review tooling is very much inspired by CodeFlow. Reviewers could use their web browser or the client app, and it all fed into the same system.
Most of the features that set it apart from Github initially have been copied by now - comment threads with resolutions, individual reviewer states, etc, have all been recently introduced; the gap between CF and GH has shrunk substantially.
That said, CF still does a better job of retaining comment threads and associating them with lines of code. Maybe it's just different UX decisions by the product teams, but it makes a difference when reviewing complicated patches.
from my understanding, H3 doesn't guarantee that a child cell falls strictly inside the geographical region of its parent (since is a hexagon cannot be perfectly comprised of smaller hexagons).
While the hexagon has less distortion - we loose some of the nice child <> parent guarantees that S2 offers in my experience.
Hexagons are all equidistant from their neighbors and all share the same size edge with all neighbors. This allows you to do cool stuff like k-rings. These properties are useful for all sorts of reasons.
With S2 cells there are two different distances to neighbors at the corners vs the sides and the neighbors at the sites have long borders and neighbors at the corners have vertice borders.
Both S3 and H3 are useful, but for different reasons. It's worth knowing the benefits and tradeoffs of both and choosing the solution that fits your particular problem.
H3 uses Buckminster Fuller's Dymaxion project and puts the 20 pentagonal vertices all in the ocean. I'm not sure the impact of this for maritime usage and I'm not sure if there is yet a different orientation that puts all vertices on land, so you can use it for maritime usage without having to concern yourself with these vertices.
> Hexagons are all equidistant from their neighbors and all share the same size edge with all neighbors.
Technically, in spherical geometry this isn't true. It's actually not possible to tile the sphere with regular hexagons (even after including those 12 pentagons). Unlike a planar tiling, some hexagons end up bigger or smaller than others, the internal angles aren't all equal to each other, and the internal angles sum to more than 360 degrees.
If i am not mistaken - this paper seems to look at explicit "Smart Speaker interactions" - not passive background listening which is what I believe you are alluding to.
Not arguing that I am saying that latter does/doesn't happen - but just that this paper is not proof of it. And there is a big difference.