On Fri, Sep 11, 2009 at 1:56 PM, Robert Bradshaw
<rober...@math.washington.edu> wrote:
> On Sep 11, 2009, at 8:00 AM, Lisandro Dalcin wrote:
>
>
> Well, it could be more expensive to construct the new object if all
> we want to do is extract out the long value.
But this path will fe followed only if
Py_TYPE(x)->tp_as_number->nb_{int|long} did not return an exact
int/long... in Python terms (taking into accout only PyInt for the
sake of keeping it simple):
def PyNumber_Int(x):
if type(x) is int:
return x
res = x.__int__()
if type(res) is int:
return res
return int.__new__(int, x)
So the line is executed in the (unlikely?) case an "int" subclass
returns a "int" subclass when calling __int__()... (perhaps this is
the case for NumPy scalars??)
> Also, I'm worried that
> Pyx_PyNumber_Int checks for PyInt/PyLong, even if it's only called on
> non PyInt/PyLong values. Given that this whole thing gets inlined all
> over the place, we also need to be concerned about code size (not for
> the .so size, but it can make a difference for instruction caches).
Very good point...
>
> Note that I pushed your #333, though we can continue working on top
> of it.
>
Perhaps we can move right now to use a chain
"likely(PyInt_ChecExact(x) || PyIntCheck(x))" for making it more or
less fast in Py 2.5 and below ? ...
Still, IIRC numpy scalars are/were broken with the Py2.6 fast subclass
check.. In such case, it would be nice to to implement PyNumber_Int in
a way that does not suffer from that issues...
>>
>>
>> On Wed, Sep 9, 2009 at 5:58 AM, Robert Bradshaw
>> <rober...@math.washington.edu> wrote:
>>> On Jun 19, 2009, at 9:44 AM, Lisandro Dalcin wrote:
>>>
>>>> I've finally managed to write a more or less working patch...
>>>> Look at
>>>> the test, I've tried to cover many corner cases...
>>>>
>>>> 1) Dag & Kurt: I bet you will be happy.
>>>>
>>>>
>>>> 2) Robert: your eyeballs needed, please comment on this:
>>>>
>>>> a) Look at the changes outside PyrexTypes.pyx, I believe they make
>>>> sense, though I would like you to confirm that.
>>>>
>>>> b) In the past, you raised some concerns about __int32 from ILP64
>>>> model... A possible (and suboptimal, no overflow-safe) way of
>>>> handling
>>>> that is there, though "#if 0" disabled. I've tried to take advantage
>>>> of "_PyLong_{As/From}ByteArray()", but that (in particular, the "As"
>>>> one) is somewhat harder to use, as we should pass a PyLongObject
>>>> type.
>>>
>>> Sorry I've taken so long to get back on this. I have read all the
>>> code, and it looks good. I've posted some comments on trac. http://
>>> trac.cython.org/cython_trac/ticket/333
>>>
>>> - Robert
>>>
>>> _______________________________________________
>>> Cython-dev mailing list
>>> Cython-dev@codespeak.net
>>> http://codespeak.net/mailman/listinfo/cython-dev
>>>
>>
>>
>>
>> --
>> Lisandro Dalcín
>> ---------------
>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>> Tel/Fax: +54-(0)342-451.1594
>> _______________________________________________
>> Cython-dev mailing list
>> Cython-dev@codespeak.net
>> http://codespeak.net/mailman/listinfo/cython-dev
>
> _______________________________________________
> Cython-dev mailing list
> Cython-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev
>
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
