On Fri, Jun 29, 2012 at 7:07 AM, Sturla Molden <
sturla...@yahoo.no> wrote:
> I like to point out that
>
> &input[0,0]
>
> is consistent with the standard way of casting C++ std::vector<T> to T*.
> The syntax &array[0] is seen in all C++ code needing to provide a data
> pointer from STL and Boost containers to C functions. So this syntax is
> not special to Cython at all. It means that Cython and C++ will call C
> in the same way.
Thanks -- another good reason. I do note that &input[0,0] does
generate a fair bit more code than input.data:
/* "multiply.pyx":34
* m, n = input.shape[0], input.shape[1]
*
* c_multiply (&input[0,0], value, m, n) # <<<<<<<<<<<<<<
*
* return None
*/
__pyx_t_3 = 0;
__pyx_t_4 = 0;
__pyx_t_5 = -1;
if (__pyx_t_3 < 0) {
__pyx_t_3 += __pyx_bshape_0_input;
if (unlikely(__pyx_t_3 < 0)) __pyx_t_5 = 0;
} else if (unlikely(__pyx_t_3 >= __pyx_bshape_0_input)) __pyx_t_5 = 0;
if (__pyx_t_4 < 0) {
__pyx_t_4 += __pyx_bshape_1_input;
if (unlikely(__pyx_t_4 < 0)) __pyx_t_5 = 1;
} else if (unlikely(__pyx_t_4 >= __pyx_bshape_1_input)) __pyx_t_5 = 1;
if (unlikely(__pyx_t_5 != -1)) {
__Pyx_RaiseBufferIndexError(__pyx_t_5);
{__pyx_filename = __pyx_f[0]; __pyx_lineno = 34; __pyx_clineno =
__LINE__; goto __pyx_L1_error;}
}
c_multiply((&(*__Pyx_BufPtrCContig2d(double *,
__pyx_bstruct_input.buf, __pyx_t_3, __pyx_bstride_0_input, __pyx_t_4,
__pyx_bstride_1_input))), __pyx_v_value, __pyx_v_m, __pyx_v_n);
vs.:
c_multiply(((double *)__pyx_v_input->data), __pyx_v_value, __pyx_v_m,
__pyx_v_n);
(i.e. no extra code)
I doubt it's a performance hit that matters, but it was interesting.
IF you turn boundcheck off, it gets a fair bit smaller:
__pyx_t_3 = 0;
__pyx_t_4 = 0;
if (__pyx_t_3 < 0) __pyx_t_3 += __pyx_bshape_0_input;
if (__pyx_t_4 < 0) __pyx_t_4 += __pyx_bshape_1_input;
c_multiply((&(*__Pyx_BufPtrCContig2d(double *,
__pyx_bstruct_input.buf, __pyx_t_3, __pyx_bstride_0_input, __pyx_t_4,
__pyx_bstride_1_input))), __pyx_v_value, __pyx_v_m, __pyx_v_n);
Though I"m a little confused by this code -- it appears to be setting
a couple values to 0, then checking if they are less than zero. --
with bound-check off, why is this still there?
Probably not worth special-casing, but in teh cse of a hard-coded
[0,0], wouldn't we always know that it's OK -- and there would never
be a need for any bound checking or offset computing of any sort?
-Thanks,
-Chris