|
From: Sasha <nd...@ma...> - 2006-02-03 02:16:25
|
On 2/2/06, Travis Oliphant <oli...@ie...> wrote: > The changes you describe, however, require serious thought with C-level > explanations because you will be changing some fundamental assumptions > that are made throughout the code. > I agree, but I would like to discuss this at the conceptual level first and maybe hear from people not intimately familiar with the C code about what they would expect from a zero stride. > For example, currently there is no way you can construct new memory for > an array and have different strides assigned (that's why strides is > ignored if no buffer is given). You would have to change the behavior > of the C-level function PyArray_NewFromDescr. You need to propose how > exactly you would change that. > Sure. I've started working on a "proof of concept" patch and will post it = soon. > Checking for strides that won't cause later segfaults can be tricky > especially if you start allowing buffer-sizes to be different than array > dimensions. How do you propose to ensure that you won't walk outside > of allocated memory when somebody changes the strides later? > I think PyArray_CheckStrides would catch that, but I will have to test that once I have some code ready. > I'm concerned that your proposal has too many potential pitfalls. At > least you haven't addressed them sufficiently. My current inclination > is to simply disallow setting the strides attribute now that the > misaligned segments of code have been tested. That would be an unfortunate result of my post :-( I would suggest just to disallow zero strides in PyArray_CheckStrides until I can convince you that they are not that dangerous. |