<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 1:51 AM, Chris Barker - NOAA Federal <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>FWIW,</div><div><br></div><div>You all may know this already, but a "long" is 64 bit on most 64 bit platforms, but 32 bit on Windows.</div>
</div></blockquote><div><br></div><div>The correct solution in this context is to use (s)size_t, intptr_t and ptrdiff_t depending on the use case, not hardcoding the bitwidth.</div><div><br></div><div>David</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div><br></div><div>Can we start using stdint.h and int32_t and friends?</div>
<div><br></div><div>-CHB<div><div class="h5"><br><br>On Sep 3, 2013, at 5:18 PM, Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br><br></div></div>
</div><div><div class="h5"><div></div><blockquote type="cite"><div><div dir="ltr">
<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 3, 2013 at 6:09 PM, Christoph Gohlke <span dir="ltr"><<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 9/3/2013 4:45 PM, Charles R Harris wrote:<br>
><br>
><br>
><br>
> On Tue, Sep 3, 2013 at 5:40 PM, Christoph Gohlke <<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a><br>
</div><div>> <mailto:<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a>>> wrote:<br>
><br>
> On 9/3/2013 2:51 PM, Charles R Harris wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Sep 3, 2013 at 3:23 PM, Christoph Gohlke <<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a> <mailto:<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a>><br>
</div><div>> > <mailto:<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a> <mailto:<a href="mailto:cgohlke@uci.edu" target="_blank">cgohlke@uci.edu</a>>>> wrote:<br>
> ><br>
> > On 9/1/2013 9:54 AM, Charles R Harris wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > I'm happy to announce the first beta release of Numpy 1.8.0.<br>
> > Please try<br>
> > this beta and report any issues on the numpy-dev mailing list.<br>
> ><br>
> > Source tarballs and release notes can be found at<br>
> ><a href="https://sourceforge.net/__projects/numpy/files/NumPy/1.__8.0b1/" target="_blank">https://sourceforge.net/__projects/numpy/files/NumPy/1.__8.0b1/</a><br>
> > <<a href="https://sourceforge.net/projects/numpy/files/NumPy/1.8.0b1/" target="_blank">https://sourceforge.net/projects/numpy/files/NumPy/1.8.0b1/</a>>.<br>
> > The Windows<br>
> > and OS X installers will follow when the infrastructure issues<br>
> > are dealt<br>
> > with.<br>
> ><br>
> > Chuck<br>
> ><br>
> ><br>
> > Hello,<br>
> ><br>
> > I tried numpy-1.8.0.dev-86a6e6c with msvc9 and MKL 11.1 on<br>
> > win-amd64-py2.7. It builds OK but there are 23 test errors and 6<br>
> > failures (attached).<br>
> ><br>
> > Some 3rd party packages (e.g. scipy, numexpr, pytables, bottleneck,<br>
> > pandas and matplotlib) that were built against numpy-MKL 1.7 fail<br>
> > tests when used with numpy-MKL 1.8. Other packages test OK (e.g.<br>
> > skimage, sklearn, statsmodels, mahotas, pygame). See<br>
> > <<a href="http://www.lfd.uci.edu/~__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7-__numpy-1.8.0.dev-86a6e6c/" target="_blank">http://www.lfd.uci.edu/~__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7-__numpy-1.8.0.dev-86a6e6c/</a><br>
</div>> <<a href="http://www.lfd.uci.edu/%7E__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7-__numpy-1.8.0.dev-86a6e6c/" target="_blank">http://www.lfd.uci.edu/%7E__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7-__numpy-1.8.0.dev-86a6e6c/</a>><br>
<div>> > <<a href="http://www.lfd.uci.edu/%7Egohlke/pythonlibs/tests/20130902-win-amd64-py2.7-numpy-1.8.0.dev-86a6e6c/" target="_blank">http://www.lfd.uci.edu/%7Egohlke/pythonlibs/tests/20130902-win-amd64-py2.7-numpy-1.8.0.dev-86a6e6c/</a>>><br>
> > compared to<br>
> > <<a href="http://www.lfd.uci.edu/~__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7/" target="_blank">http://www.lfd.uci.edu/~__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7/</a><br>
</div>> <<a href="http://www.lfd.uci.edu/%7E__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7/" target="_blank">http://www.lfd.uci.edu/%7E__gohlke/pythonlibs/tests/__20130902-win-amd64-py2.7/</a>><br>
<div>> > <<a href="http://www.lfd.uci.edu/%7Egohlke/pythonlibs/tests/20130902-win-amd64-py2.7/" target="_blank">http://www.lfd.uci.edu/%7Egohlke/pythonlibs/tests/20130902-win-amd64-py2.7/</a>>>.<br>
> ><br>
> ><br>
> > I have not looked in more detail or at other Python versions yet.<br>
> ><br>
> ><br>
> > Thanks Christoph,<br>
> ><br>
> > Looks like some work to do. I wonder what is different between windows<br>
> > and linux here?<br>
> ><br>
> > Chuck<br>
> ><br>
><br>
> Looks like the fundamental PyArray_PyIntAsIntp function is broken on 64<br>
> bit Windows. 64 bit PyLong values are intermediately stored in a 32 bit<br>
> C long variable. But maybe I am missing something...<br>
> <<a href="https://github.com/numpy/numpy/blob/maintenance/1.8.x/numpy/core/src/multiarray/conversion_utils.c#L729" target="_blank">https://github.com/numpy/numpy/blob/maintenance/1.8.x/numpy/core/src/multiarray/conversion_utils.c#L729</a>><br>
> <<a href="https://github.com/numpy/numpy/blob/maintenance/1.8.x/numpy/core/src/multiarray/conversion_utils.c#L767" target="_blank">https://github.com/numpy/numpy/blob/maintenance/1.8.x/numpy/core/src/multiarray/conversion_utils.c#L767</a>><br>
><br>
> My, that does look suspicious. That function is new in 1.8 I believe.<br>
> Looks like it needs fixing whatever else it fixes.<br>
><br>
> Chuck<br>
><br>
<br>
</div>In fact, using a npy_longlong instead of npy_long fixes all numpy test<br>
errors and failures. But it probably foils the recent optimizations.<br></blockquote><div><br></div><div>Great! I think the function is not used for numeric things so I'm not sure what optimizations could be affected. I'll put up a PR and backport it.<br>
<br></div><div>Chuck <br></div></div></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><div class="im"><br><span>NumPy-Discussion mailing list</span><br><span><a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a></span><br>
<span><a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a></span><br></div></div></blockquote></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div></div>