Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vectorized functions #147

Merged
merged 12 commits into from
Jul 20, 2020
Merged

Vectorized functions #147

merged 12 commits into from
Jul 20, 2020

Conversation

ajfriend
Copy link
Contributor

@ajfriend ajfriend commented Jul 5, 2020

No description provided.

@codecov
Copy link

codecov bot commented Jul 5, 2020

Codecov Report

Merging #147 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##            master      #147   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines          203       203           
=========================================
  Hits           203       203           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dd08189...f2baf37. Read the comment docs.

@ajfriend
Copy link
Contributor Author

Remove the demo notebook and move it to the demo notebooks repo.

@ajfriend ajfriend marked this pull request as ready for review July 18, 2020 17:53
from cython cimport boundscheck, wraparound
from libc.math cimport sqrt, sin, cos, asin

cdef double haversineDistance(double th1, double ph1, double th2, double ph2) nogil:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this belong in this binding?

I don't think we provide haversine distance support in any of the other bindings?

Copy link
Contributor Author

@ajfriend ajfriend Jul 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm considering anything under h3.unstable as "not in the binding". There was a request for an optimized cell_haversine function, so I'm putting it in to make it easy for them to play with, and evaluate the speedups.

In the short term, this is hard to do anywhere except within the Cython bindings. In the future however, we could consider making it easy for folks to do this outside the Cython bindings, by letting them write their own Cython code which just does cimport h3 to get access to the C and Cython code in these bindings. Here's an issue around it: #152

I'd say that's probably the way to go in the future.

Copy link
Contributor

@kylebarron kylebarron Sep 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty easy to make a vectorized haversine in numpy only. So for the future if/when vectorized functions make it out of unstable, it might be ideal to only make h3_to_geo vectorized, then the end user can have a vectorized pipeline without touching cython themselves:

# a, b arrays of hex ids
a_geo = h3_to_geo(a)
b_geo = h3_to_geo(b)
dist = haversine(a_geo, b_geo)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will expose a haversine function when uber/h3#377 lands:

https://github.com/uber/h3/blob/930cb1be6efe88ef397fb443027a2a86c0616c88/src/h3lib/include/h3api.h.in#L265-L269

It would be easy to add that to the h3-py "vectorized" API, whenever we figure out the best way to do that. I'd be interesting to compare it to the "numpy-vectorized" version you have above!

@@ -48,9 +48,9 @@ cdef extern from "h3api.h":
LinkedGeoLoop *_data_last "last" # not needed in Cython bindings
LinkedGeoPolygon *next

H3Index geoToH3(const GeoCoord *g, int res)
H3Index geoToH3(const GeoCoord *g, int res) nogil
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you determine which functions get nogil? Is it just the ones you want to optimize right now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just added it to the functions I needed it for in this PR. We could probably add nogil to each of the functions in the API, as the nogil tag just promises that the function won't manipulate any Python objects, which is true for everything in the h3-c API.

I'll probably do a more thorough job of this when I tackle #140

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants