Before we do a release, would anyone be opposed to a 'chunksize' keyword argument to prange()? That may have significant performance impacts.
On 29 October 2011 12:41, mark florisson <markflorisso...@gmail.com> wrote: > Hm ok I'll disable them then. Pointers and some other dtypes are also > not supported yet. As for the documentation, have you guys reviewed > the documentation for fused types and memoryviews? For instance this > is the introduction for memoryviews: > > " > Typed memoryviews can be used for efficient access to buffers. It is > similar to the current buffer support, but has more features and > cleaner syntax. A memoryview can be used in any context (function > parameters, module-level, cdef class attribute, etc) and can be > obtained from any object that exposes the PEP 3118 buffer interface. > " > > but I'm not sure this new functionality won't confuse users of the old > buffer support. > > For fused types, cython.numeric only includes long, double and double > complex. I think that should be changed to short, int, long, float, > double, float complex and double complex. I was deliberately avoiding > long long and long double as they (if not used as a base type) would > be preferred over the others and may be a lot slower. But then, such > usage wouldn't be very useful. Should I include them then? > > On 29 October 2011 10:30, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> Re b), it would be better to disable object dtypes (or emit a warning about >> the possible bug when using them) than to delay the release. Object >> memoryviews are rare in the first place, and those who contain themselves >> should be very rare. >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> Robert Bradshaw <rober...@math.washington.edu> wrote: >>> >>> On Fri, Oct 28, 2011 at 1:59 PM, mark florisson >>> <markflorisso...@gmail.com> wrote: > On 28 October 2011 21:55, Robert >>> Bradshaw <rober...@math.washington.edu> wrote: >> With Mark's fused types >>> and memory views going in, I think it's about >> time for a new release. >>> Thoughts? Anyone want to volunteer to take up >> the process? >> >> - Robert >>> >> >>> ________________________________ >>> >> cython-devel mailing list >> cython-devel@python.org >> >>> >> http://mail.python.org/mailman/listinfo/cython-devel >> > > That'd be >>> >> cool. >>> >> However there are a few outstanding issues: > a) the compiler is >>> >> somewhat >>> >> slower (possible solution: lazy utility codes) Yeah, I forgot about that. >>> >> This should get resolved. Lazy utility codes (perhaps breaking them up) >>> >> would probably got us most of the way there. Long term, I really like the >>> >> "declaration caching" idea which could be used for users .pxd files as >>> >> well >>> >> as internally. > b) there's a potential memory leak problem for >>> >> memoryviews with > object dtype that contain themselves, this still needs >>> >> investigation. I think this could be mentioned as a caviat rather than >>> >> being >>> >> a blocker. > As for a), Stefan mentioned code spending a lot of time in >>> >> sub. >>> >> > Stefan, could you post the code for this that made Cython compile very >>> >> > > >>> >> slowly? > >>> ________________________________ >>> > cython-devel mailing list > cython-devel@python.org > >>> > http://mail.python.org/mailman/listinfo/cython-devel > >>> ________________________________ >>> cython-devel mailing list cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> >> _______________________________________________ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> >> > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
