On Mon, Oct 31, 2011 at 6:25 PM, Matthew Brett wrote:
> Oh, dear, I'm suffering now:
>
> In [11]: res = np.array((2**31,), dtype=np.float32)
>
> In [12]: res > 2**31-1
> Out[12]: array([False], dtype=bool)
>
> OK - that's what I was expecting from the above, but now:
>
> In [13]: res[0] > 2**31-1
Hi,
2011/10/31 Stéfan van der Walt :
> On Mon, Oct 31, 2011 at 11:23 AM, Matthew Brett
> wrote:
>> In [8]: np.float(2**63) == 2**63
>> Out[8]: True
>>
>> In [9]: np.float(2**63) > 2**63-1
>> Out[9]: True
>>
>> In [10]: np.float64(2**63) == 2**63
>> Out[10]: True
>>
>> In [11]: np.float64(2**63)
Hi Sandro
On Mon, Oct 31, 2011 at 12:02 PM, Sandro Tosi wrote:
> In order to do that, we'd like to use the C_API_VERSION and
> C_ABI_VERSION values; while for C_API_VERSION we can see it's a quite
> small value, with a clear history at
> ./numpy/core/code_generators/cversions.txt , we don't have
On Mon, Oct 31, 2011 at 11:23 AM, Matthew Brett wrote:
> In [8]: np.float(2**63) == 2**63
> Out[8]: True
>
> In [9]: np.float(2**63) > 2**63-1
> Out[9]: True
>
> In [10]: np.float64(2**63) == 2**63
> Out[10]: True
>
> In [11]: np.float64(2**63) > 2**63-1
> Out[11]: False
>
> In [16]: np.float64(2*
On Mon, Oct 31, 2011 at 11:28 AM, Zachary Pincus
wrote:
>> As an example, it'd be nice to have scipy.ndimage available without the GIL:
>> http://docs.scipy.org/doc/scipy/reference/ndimage.html
>>
>> Now, this *can* easily be done as the core is written in C++. I'm just
>> pointing out that some p
Hello,
in Debian we're trying to define a way to handle numpy transitions
more smoothly (you can read the proposal, if interested, at
http://bugs.debian.org/643873).
In order to do that, we'd like to use the C_API_VERSION and
C_ABI_VERSION values; while for C_API_VERSION we can see it's a quite
sm
> As an example, it'd be nice to have scipy.ndimage available without the GIL:
> http://docs.scipy.org/doc/scipy/reference/ndimage.html
>
> Now, this *can* easily be done as the core is written in C++. I'm just
> pointing out that some people may wish more for calling scipy.ndimage
> inside thei
Hi,
I just ran into this confusing difference between np.float and np.float64:
In [8]: np.float(2**63) == 2**63
Out[8]: True
In [9]: np.float(2**63) > 2**63-1
Out[9]: True
In [10]: np.float64(2**63) == 2**63
Out[10]: True
In [11]: np.float64(2**63) > 2**63-1
Out[11]: False
In [16]: np.float64
Pauli Virtanen iki.fi> writes:
>
> The problem here seems to be that argsort (or only the mergesort?) for
> datetime datatypes is not implemented.
>
> There's a faster code path that is triggered for small selection arrays,
> and that does not require argsort, and that's why the error occurs in
On 10/31/2011 08:31 AM, Olivier Delalleau wrote:
If you google around "einsum hang", it looks like this is a problem
with Intel compiler with the -O3 flag.
See this thread in particular:
http://comments.gmane.org/gmane.comp.python.numeric.general/43168
It looks like there may be more issues too
If you google around "einsum hang", it looks like this is a problem with
Intel compiler with the -O3 flag.
See this thread in particular:
http://comments.gmane.org/gmane.comp.python.numeric.general/43168
It looks like there may be more issues too...
-=- Olivier
2011/10/30 akshar bhosale
> hi,
>
On 10/31/2011 12:01 PM, Dag Sverre Seljebotn wrote:
> On 10/31/2011 11:48 AM, mark florisson wrote:
>> On 31 October 2011 10:03, Dag Sverre Seljebotn
>>wrote:
>>> Mark: I'm just wondering what you wanted to do with NumPy from Cython -- a
>>> stopgap solution for SIMD, iterator support, or somet
On 10/31/2011 11:48 AM, mark florisson wrote:
> On 31 October 2011 10:03, Dag Sverre Seljebotn
> wrote:
>> Mark: I'm just wondering what you wanted to do with NumPy from Cython -- a
>> stopgap solution for SIMD, iterator support, or something else?
>>
>> SIMD using NumPy really isn't the best ide
On 31 October 2011 09:50, Pauli Virtanen wrote:
> 31.10.2011 09:44, mark florisson kirjoitti:
> [clip]
>> Ah, that's too bad. Is it anywhere near ready, or was it abandoned for
>> ironclad? Could you point me to the code?
>
> It's quite ready and working, and as far as I understand, Enthought is
>
On 31 October 2011 10:03, Dag Sverre Seljebotn
wrote:
> Mark: I'm just wondering what you wanted to do with NumPy from Cython -- a
> stopgap solution for SIMD, iterator support, or something else?
>
> SIMD using NumPy really isn't the best idea long-term because of all the
> temporaries needed in
This comes out of a long discussion on the Cython list. Following Mark's
success with the shared memory parallelism, the question is: Where to
take Cython's capabilities for parallelism further?
One thing that's been up now and then is that we could basically use
something like:
- multiproce
Mark: I'm just wondering what you wanted to do with NumPy from Cython -- a
stopgap solution for SIMD, iterator support, or something else?
SIMD using NumPy really isn't the best idea long-term because of all the
temporaries needed in compound expressions, which is really bad on the memory
bus f
31.10.2011 09:44, mark florisson kirjoitti:
[clip]
> Ah, that's too bad. Is it anywhere near ready, or was it abandoned for
> ironclad? Could you point me to the code?
It's quite ready and working, and as far as I understand, Enthought is
shipping it. I haven't used it, though.
The code is here:
On 30 October 2011 21:01, Pauli Virtanen wrote:
> 30.10.2011 21:48, mark florisson kirjoitti:
>> First, I'd like to report a bug. It seems ndarray does not implement
>> tp_traverse or tp_clear, so if you have a reference cycle in an
>> ndarray with dtype object none of those objects will ever be
>
19 matches
Mail list logo
