Installation

[krober10nd]

Just making a new issue for easy searching in the future.

For installation, I had to export the include path for numpy headers in order for the program to build with cython correctly.

Like this:

python
import numpy 
numpy.get_include()

and then I copied that last path and put it here:

export CFLAGS="-I /Users/Keith/firedrake/lib/python3.7/site-packages/numpy/core/include $CFLAGS"

After that things appear to work and are registering 150x speed ups over matlplotlib.path.contains 🥇

[krober10nd]

But generally pip install -U -e . is a good way to install a package like this. If you call the setup.py directly it can be hard to uninstall. `

[dengwirda]

Okay, hopefully I've addressed this --- setup.py is now done a little differently so that the numpy headers are auto-imported. There's a bunch of urls in setup.py that talk about the various issues that need to be worked-around...

Nonetheless, for me, python setup.py build_ext --inplace will now run out-of-the-box on my Win machine, which doesn't have cython installed at all. Let me know if this works for you on macOS.

In terms of pip install --- yes, this is the best way for users to install inpoly without having to actually build it. Calling setup.py directly is the -dev route, for updating the cython output and etc.

I believe it's possible to somehow build "binary wheels" and whatnot for pip (so that downstream users don't have to build the binaries at all) but I need to learn how this works across different machines / architectures / compilers / etc...

I'll make the repo public at this stage too, since I think this is almost there now.

[krober10nd]

Yep. Everything is working great with the installation on my mac. I ran all the instructions on the README and also tried via pip and didn't need to export any flags to the LD path.

My auto formatter is just telling me that the variable ymin( lower case) is unused.

The other small thing is should ftol and lbar be declared as double in the function signature?

Otherwise, everything looks great! If you're really pushing the limits for a big problem it may be possible to use thread based parallelism using prange instead of range.

https://cython.readthedocs.io/en/latest/src/userguide/parallelism.html

[krober10nd]

Did you think about patenting this algorithm? The numpy community may have interests in building this algorithm into their default library since it appears there is no existing algorithm with better complexity bounds.

[dengwirda]

Alright --- I think there's now the full workflow up and running: inpoly is on PyPi with both sdist and bdist_wheel files available for Python 3.5 => 3.8 on linux, macOS and windows. If you do pip install inpoly you should now get the pre-built binaries installed automagically, a'la numpy, etc...

As you saw earlier, I've used travis + cibuildwheel to build all of the binaries and upload them to PyPi. This process involved many tears; but ultimately (I guess) tears of joy! I think all should be in place now to maintain going forward --- travis will run on any commit to the inpoly-python repo, but will only upload new bdist_wheel's to PyPi for tagged releases (that build successfully). I should probably add unit tests for travis to run too, but that can happen another day.

I'll reopen #1 to discuss a few of the other performance-type things.

[krober10nd]

Wow that's awesome! I have never seen the CI system used for that purpose but it makes sense. I guess there was some boiler plate code to figure out for the .ci/config file (there almost always is).