21 Jun 2012 10:59
[Cython] buffer shape incompatible with memoryview shape
Hi, I find this worth fixing for 0.17: http://trac.cython.org/cython_trac/ticket/780 Stefan
Hi, I find this worth fixing for 0.17: http://trac.cython.org/cython_trac/ticket/780 Stefan
On 21 June 2012 09:59, Stefan Behnel <stefan_ml@...> wrote: > Hi, > > I find this worth fixing for 0.17: > > http://trac.cython.org/cython_trac/ticket/780 > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel@... > http://mail.python.org/mailman/listinfo/cython-devel It seems that arrays are compared as pointer values, so it doesn't even compare sensibly anyway. You can easily work around it by writing (<object> memoryview).shape though. I think these shape/strides/suboffset arrays should have a special type and coerce to tuples when coercing to an object. Feel free to work on that, it wouldn't really require touching much or any of the memoryview code, it's not really on m priority list right now. BTW, Stefan, how do we start Jenkins on the sage server? It's been down for weeks now.
Stefan Behnel, 21.06.2012 13:00: > mark florisson, 21.06.2012 12:38: >> BTW, Stefan, how do we start Jenkins on the sage server? It's been >> down for weeks now. > > It seems like the sage.math server would be happy about a restart. I'll > trigger the ML. Jenkins is back up and building. Stefan
On 06/21/2012 10:59 AM, Stefan Behnel wrote: > Hi, > > I find this worth fixing for 0.17: > > http://trac.cython.org/cython_trac/ticket/780 > I'm not sure about the timeline here. The object<->memoryview semantics haven't even been hammered down yet; does "mview.customattr" trigger an AttributeError, SyntaxError or fall back to some underlying object (constructing it if necesarry). Until that happens, memoryviews are an experimental feature and present for development purposes mostly, so it's not like this is a big bug that would bite end-users. Thinking about those semantics is much more important... Dag
Dag Sverre Seljebotn, 21.06.2012 13:10: > On 06/21/2012 10:59 AM, Stefan Behnel wrote: >> I find this worth fixing for 0.17: >> >> http://trac.cython.org/cython_trac/ticket/780 > > I'm not sure about the timeline here. > > The object<->memoryview semantics haven't even been hammered down yet; does > "mview.customattr" trigger an AttributeError, SyntaxError or fall back to > some underlying object (constructing it if necesarry). > > Until that happens, memoryviews are an experimental feature and present for > development purposes mostly, so it's not like this is a big bug that would > bite end-users. Thinking about those semantics is much more important... Absolutely. I ran into this when I gave a Cython+NumPy course and this was the first thing that the attendants tried when I asked them to validate that two input arrays have the same size before adding them. It's the one obvious way to do it, and it fails miserably. I think it should be fixed, and I think it should be fixed soon because it feels really low-level and complicated, especially to new users. Stefan
On 06/21/2012 01:36 PM, Stefan Behnel wrote: > Dag Sverre Seljebotn, 21.06.2012 13:10: >> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>> I find this worth fixing for 0.17: >>> >>> http://trac.cython.org/cython_trac/ticket/780 >> >> I'm not sure about the timeline here. >> >> The object<->memoryview semantics haven't even been hammered down yet; does >> "mview.customattr" trigger an AttributeError, SyntaxError or fall back to >> some underlying object (constructing it if necesarry). >> >> Until that happens, memoryviews are an experimental feature and present for >> development purposes mostly, so it's not like this is a big bug that would >> bite end-users. Thinking about those semantics is much more important... > > Absolutely. > > I ran into this when I gave a Cython+NumPy course and this was the first > thing that the attendants tried when I asked them to validate that two > input arrays have the same size before adding them. It's the one obvious > way to do it, and it fails miserably. I think it should be fixed, and I > think it should be fixed soon because it feels really low-level and > complicated, especially to new users. Can you clarify a bit -- did you give this course using np.ndarray[double, ndim=2], or double[:, :]? They're really very separate under the hood and the fix is different.(Continue reading)
Dag Sverre Seljebotn, 21.06.2012 14:05: > On 06/21/2012 01:36 PM, Stefan Behnel wrote: >>> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>>> I find this worth fixing for 0.17: >>>> >>>> http://trac.cython.org/cython_trac/ticket/780 >>> >> I ran into this when I gave a Cython+NumPy course and this was the first >> thing that the attendants tried when I asked them to validate that two >> input arrays have the same size before adding them. It's the one obvious >> way to do it, and it fails miserably. I think it should be fixed, and I >> think it should be fixed soon because it feels really low-level and >> complicated, especially to new users. > > Can you clarify a bit -- did you give this course using np.ndarray[double, > ndim=2], or double[:, :]? They're really very separate under the hood and > the fix is different. > > Or, did you actually use object[double, ndim=2] like in the bug report? > (Did me and Mark get around to propose deprecating this one on the list?) IIRC, we used object[double, ndim=2] for both and I also tried it with a memory view as in the bug report. I thought that using "object" was the preferred way to do it? At least, it doesn't restrict the type of the buffer exporter, which I consider a good thing. Stefan
On 06/21/2012 02:59 PM, Stefan Behnel wrote: > Dag Sverre Seljebotn, 21.06.2012 14:05: >> On 06/21/2012 01:36 PM, Stefan Behnel wrote: >>>> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>>>> I find this worth fixing for 0.17: >>>>> >>>>> http://trac.cython.org/cython_trac/ticket/780 >>>> >>> I ran into this when I gave a Cython+NumPy course and this was the first >>> thing that the attendants tried when I asked them to validate that two >>> input arrays have the same size before adding them. It's the one obvious >>> way to do it, and it fails miserably. I think it should be fixed, and I >>> think it should be fixed soon because it feels really low-level and >>> complicated, especially to new users. >> >> Can you clarify a bit -- did you give this course using np.ndarray[double, >> ndim=2], or double[:, :]? They're really very separate under the hood and >> the fix is different. >> >> Or, did you actually use object[double, ndim=2] like in the bug report? >> (Did me and Mark get around to propose deprecating this one on the list?) > > IIRC, we used object[double, ndim=2] for both and I also tried it with a > memory view as in the bug report. I thought that using "object" was the > preferred way to do it? At least, it doesn't restrict the type of the > buffer exporter, which I consider a good thing. That's a very theoretical argument as NumPy arrays are in practice the only exporter.(Continue reading)
Dag Sverre Seljebotn, 21.06.2012 15:06: > On 06/21/2012 02:59 PM, Stefan Behnel wrote: >> Dag Sverre Seljebotn, 21.06.2012 14:05: >>> On 06/21/2012 01:36 PM, Stefan Behnel wrote: >>>>> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>>>>> I find this worth fixing for 0.17: >>>>>> >>>>>> http://trac.cython.org/cython_trac/ticket/780 >>>>> >>>> I ran into this when I gave a Cython+NumPy course and this was the first >>>> thing that the attendants tried when I asked them to validate that two >>>> input arrays have the same size before adding them. It's the one obvious >>>> way to do it, and it fails miserably. I think it should be fixed, and I >>>> think it should be fixed soon because it feels really low-level and >>>> complicated, especially to new users. >>> >>> Can you clarify a bit -- did you give this course using np.ndarray[double, >>> ndim=2], or double[:, :]? They're really very separate under the hood and >>> the fix is different. >>> >>> Or, did you actually use object[double, ndim=2] like in the bug report? >>> (Did me and Mark get around to propose deprecating this one on the list?) >> >> IIRC, we used object[double, ndim=2] for both and I also tried it with a >> memory view as in the bug report. I thought that using "object" was the >> preferred way to do it? At least, it doesn't restrict the type of the >> buffer exporter, which I consider a good thing. > > That's a very theoretical argument as NumPy arrays are in practice the only > exporter.(Continue reading)
On 21 June 2012 14:34, Stefan Behnel <stefan_ml@...> wrote: > Dag Sverre Seljebotn, 21.06.2012 15:06: >> On 06/21/2012 02:59 PM, Stefan Behnel wrote: >>> Dag Sverre Seljebotn, 21.06.2012 14:05: >>>> On 06/21/2012 01:36 PM, Stefan Behnel wrote: >>>>>> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>>>>>> I find this worth fixing for 0.17: >>>>>>> >>>>>>> http://trac.cython.org/cython_trac/ticket/780 >>>>>> >>>>> I ran into this when I gave a Cython+NumPy course and this was the first >>>>> thing that the attendants tried when I asked them to validate that two >>>>> input arrays have the same size before adding them. It's the one obvious >>>>> way to do it, and it fails miserably. I think it should be fixed, and I >>>>> think it should be fixed soon because it feels really low-level and >>>>> complicated, especially to new users. >>>> >>>> Can you clarify a bit -- did you give this course using np.ndarray[double, >>>> ndim=2], or double[:, :]? They're really very separate under the hood and >>>> the fix is different. >>>> >>>> Or, did you actually use object[double, ndim=2] like in the bug report? >>>> (Did me and Mark get around to propose deprecating this one on the list?) >>> >>> IIRC, we used object[double, ndim=2] for both and I also tried it with a >>> memory view as in the bug report. I thought that using "object" was the >>> preferred way to do it? At least, it doesn't restrict the type of the >>> buffer exporter, which I consider a good thing. >> >> That's a very theoretical argument as NumPy arrays are in practice the only(Continue reading)
On 21 June 2012 13:05, Dag Sverre Seljebotn <d.s.seljebotn@...> wrote: > On 06/21/2012 01:36 PM, Stefan Behnel wrote: >> >> Dag Sverre Seljebotn, 21.06.2012 13:10: >>> >>> On 06/21/2012 10:59 AM, Stefan Behnel wrote: >>>> >>>> I find this worth fixing for 0.17: >>>> >>>> http://trac.cython.org/cython_trac/ticket/780 >>> >>> >>> I'm not sure about the timeline here. >>> >>> The object<->memoryview semantics haven't even been hammered down yet; >>> does >>> "mview.customattr" trigger an AttributeError, SyntaxError or fall back to >>> some underlying object (constructing it if necesarry). >>> >>> Until that happens, memoryviews are an experimental feature and present >>> for >>> development purposes mostly, so it's not like this is a big bug that >>> would >>> bite end-users. Thinking about those semantics is much more important... >> >> >> Absolutely. >> >> I ran into this when I gave a Cython+NumPy course and this was the first(Continue reading)
RSS Feed