On 07/07/2011 11:18 AM, Mark Wiebe wrote:
On Thu, Jul 7, 2011 at 11:11 AM, Bruce Southey <[email protected]
<mailto:[email protected]>> wrote:
On 07/07/2011 10:06 AM, Mark Wiebe wrote:
On Thu, Jul 7, 2011 at 9:56 AM, Bruce Southey <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Jul 6, 2011 at 1:56 PM, Christoph Gohlke
<[email protected] <mailto:[email protected]>> wrote:
>
>
> On 7/6/2011 10:57 AM, Russell E. Owen wrote:
>> In article
>>
<cabl7cqhnnjkzk9xnrlvdarsdknwrm4ev0mxdurjsaxq73eb...@mail.gmail.com
<mailto:cabl7cqhnnjkzk9xnrlvdarsdknwrm4ev0mxdurjsaxq73eb...@mail.gmail.com>>,
>> Ralf Gommers<[email protected]
<mailto:[email protected]>> wrote:
>>
>>> On Tue, Jul 5, 2011 at 11:41 PM, Russell E.
Owen<[email protected] <mailto:[email protected]>> wrote:
>>>
>>>> In
article<[email protected]
<mailto:[email protected]>>,
>>>> Ralf Gommers<[email protected]
<mailto:[email protected]>> wrote:
>>>>
>>>>>
https://sourceforge.net/projects/numpy/files/NumPy/1.6.1rc2/
>>>>
>>>> Will there be a Mac binary for 32-bit pythons (one that
is compatible
>>>> with older versions of MacOS X)? At present I only see a
64-bit
>>>> 10.6-only version.
>>>>
>>>>
>>>> Yes there will be for the final release (10.4-10.6
compatible). I can't
>>> create those on my own computer, so sometimes I don't
make them for RCs.
>>
>> I'm glad they will be present for the final release.
>>
>> FYI: I built my own 1.6.1rc2 against Python 2.7.2 (the
32-bit Mac
>> version from python.org <http://python.org>). I reproduced
a memory error that I've been
>> trying to narrow down. This is ticket 1896:
>> <http://projects.scipy.org/numpy/ticket/1896>
>> and the problem is also in 1.6.0.
>>
>> -- Russell
>>
>
>
> I can reproduce this error on Windows. It looks like a
serious regression.
>
> Christoph
> _______________________________________________
> NumPy-Discussion mailing list
> [email protected] <mailto:[email protected]>
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
I do get this error in the code without tinker on the first loop.
I did notice that the original array (dataArr) is float64 but the
second array (scaledArr) is only float32. The problem is
removed by
changing the dtype of scaledArr to float64. Thus, it would
appear some
memory allocation related error to squeeze a float64 result
into a
memory allocated for a float32 array.
Can you try it on your platform with the pull request I've made
which hopefully fixes it? Here's the link:
https://github.com/numpy/numpy/pull/103
Thanks,
Mark
I do not get the crash with Python2.7 on the users code. But I can
not compile this branch under Python3.1 or Python3.2. The last
error is below - I can look into this more if needed.
I suspect you have gotten the missingdata branch by accident instead
of the pull request's one. This is one thing I've found confusing/bad
about github, is that the URL they provide always gives you the
default branch. You need to switch to the crash1896 branch for the test.
It does look like I missed something when cleaning up some NumPy API
stuff, however. That build failure log is useful, thanks!
-Mark
Yes, your are correct as I just check if the fix was present rather than
ensuring I got the correct branch.
So the correct branch fixes the Python3.x build issue.
Bruce
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
