<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 17, 2017 at 12:55 AM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> How would the process look like if NumPY is distributed as a<br>
> precompiled binary?<br><br>
<br>
</span>Well, numpy is BSD, and the official binaries will be BSD, someone else<br>
could do less free binaries of course. </blockquote><div><br></div><div>Indeed, if you want it to be distributed as a binary with numpy, then the license needs to be compatible -- do you have a substantial objection to BSD? The BSD family is pretty much the standard for Python -- Python (and numpy) are very broadly used in proprietary software.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I doubt we can have a hard<br>
dependency unless it is part of the numpy source</blockquote><div><br></div><div>and no reason to -- if it is a hard dependency, it HAS to be compatible licensed, and it's a lot easier to keep the source together.</div><div><br></div><div>However, it _could_ be a soft dependency, like LAPACK/BLAS -- I've honestly lost track, but numpy used come with a lapack-lite (or some such), so that it could be compiled and work with no external LAPACK implementation -- you wouldn't get the best performance, but it would work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I doubt including the source<br>
itself is going to happen quickly since we would first have to decide<br>
to actually use a modern C++ compiler (I have no idea if that is<br>
problematic or not).<br></blockquote><div><br></div><div>could it be there as a conditional compilation? There is a lot of push to support C++11 elsewhere, so a compiled-with-a-modern-compiler numpy is not SO far off..</div><div><br></div><div>(for py3 anyway...)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Use TCL if you need faster einsum(like) operations<br>
</blockquote><div><br></div><div>That is, of course, the other option -- distribute it on its own or maybe in scipy, and then users can use it as an optimization for those few core functions where speed matters to them -- honestly, it's a pretty small fraction of numpy code.</div><div><br></div><div>But it sure would be nice if it could be built in, and then folks would get better performance without even thinkning about it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just a few thoughts, did not think about details really. But yes, it is<br>
sounds reasonable to me to re-add support for optional dependencies<br>
such as fftw or your TCL. But packagers have to make use of that or I<br>
fear it is actually less available than a standalone python module.<br></blockquote><div><br></div><div>true -- though I expect Anaconda / conda forge at least would be likely to pick it up if it works well.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>