Re: [Python-Dev] graphics maths types in python core?
Nick Coghlan wrote: Actually *finishing* parts 2 and 3 of PEP 3118 would be a good precursor to having some kind of multi-dimensional mathematics in the standard library though. Even if they only work on the existing one-dimensional sequence types, elementwise operations would still be useful to have. And if they work through the new buffer protocol, they'll be ready for multi-dimensional types if and when such types appear. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Nick Coghlan ncoghlan at gmail.com writes: Parts 2 and 3, being the memoryview API and support for the new protocol in the builtin types are the parts that are currently restricted to simple linear memory views. That's largely because parts 2 and 3 are somewhat use case challenged: the key motivation behind PEP 3118 was so that libraries like NumPy, PIL and the like would have a common standard for data interchange. If I understand correctly, one of the motivations behind memoryview() is to replace buffer() as a way to get cheap slicing without memory copies (it's used e.g. in the C IO library). I don't know whether the third-party types mentioned above could also benefit from that. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Antoine Pitrou wrote: Nick Coghlan ncoghlan at gmail.com writes: Parts 2 and 3, being the memoryview API and support for the new protocol in the builtin types are the parts that are currently restricted to simple linear memory views. That's largely because parts 2 and 3 are somewhat use case challenged: the key motivation behind PEP 3118 was so that libraries like NumPy, PIL and the like would have a common standard for data interchange. If I understand correctly, one of the motivations behind memoryview() is to replace buffer() as a way to get cheap slicing without memory copies (it's used e.g. in the C IO library). I don't know whether the third-party types mentioned above could also benefit from that. Yep, once memoryview supports all of the PEP 3118 semantics it should be usable with sufficiently recent versions of NumPy arrays and the like. It's implementation has unfortunately lagged because those with the most relevant expertise don't need it (they access the objects they care about through the C API), and there are some interesting semantics to get right which are hard to judge without that expertise. Still, as both you and Greg have pointed out, even in its current form memoryview is already useful as a replacement for buffer that doesn't share buffer's problems - it's only if they try to use it with the more sophisticated aspects of the PEP 3118 API that people may be disappointed by its capabilities. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
2009/4/5 Antoine Pitrou solip...@pitrou.net: Nick Coghlan ncoghlan at gmail.com writes: That's largely because parts 2 and 3 are somewhat use case challenged: the key motivation behind PEP 3118 was so that libraries like NumPy, PIL and the like would have a common standard for data interchange. If I understand correctly, one of the motivations behind memoryview() is to replace buffer() as a way to get cheap slicing without memory copies (it's used e.g. in the C IO library). I don't know whether the third-party types mentioned above could also benefit from that. Well, PEP 3118 is useful because it would be nice having e.g. the possibility of opening an image with PIL, manipulate it directly with NumPy and saving it to file with PIL. Right now this is possible only if the PIL image is first converted (and copied) to a new NumPy array and then the array is converted back to an image. BTW, while PEP 3118 provides a common C API for this, the related PEP 368 proposes a standard image protocol on the Python side that should be compatible with the image classes of PIL, wxPython and pygame, and (mostly) with NumPy arrays. I started an implementation of PEP 368 at: http://code.google.com/p/pyimage/ Both the PEP and the implementation need updates (pyimage already includes an IEEE 754r compatible half-precision floating point type, aka float16, that's not yet in the PEP), but if someone is interested and willing to help I may start again working on them. Also note that the subjects vec2, vec3, quaternion, etc (PEP 3141) and multi-dimensional arrays (PEP 3118) are mostly unrelated. -- Lino Mastrodomenico ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Nick Coghlan wrote: Still, as both you and Greg have pointed out, even in its current form memoryview is already useful as a replacement for buffer that doesn't share buffer's problems That may be so, but I was more pointing out that the elementwise functions I'm talking about would be useful even without memoryview at all. Mostly you would just use them directly on array.array or other sequence types. rant subject=terminology Why is it that whenever the word buffer is mentioned, some people seem to think it has something to do with memoryview? There is no such thing as a buffer. There is the buffer interface, and there are objects which support the buffer interface, of which memoryview is one among many. /rant -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Greg Ewing wrote: rant subject=terminology Why is it that whenever the word buffer is mentioned, some people seem to think it has something to do with memoryview? There is no such thing as a buffer. There is the buffer interface, and there are objects which support the buffer interface, of which memoryview is one among many. /rant Probably because memoryview *is* the Python API for the C-level buffer interface. While I can understand that point of view, I don't agree with it, which is why I consider it important to point out that memoryview's limitations aren't shared by the underlying API when the topic comes up. /tangent from the vector math thread (hopefully) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Greg Ewing greg.ewing at canterbury.ac.nz writes: Why is it that whenever the word buffer is mentioned, some people seem to think it has something to do with memoryview? There is no such thing as a buffer. There is a Py_buffer struct. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] graphics maths types in python core?
Hi all, we're having a discussion over on the GSoC mailing list about basic math types, and I was wondering if there is any history that we should be aware of in python-dev. Has this been brought up before and rejected? Should the interested projects work towards a consensus and maybe write up a PEP? (The proximal issue is whether or not this is of direct relevance to the python core and hence should be given priority.) tnx, -titus Rene Dudfield wrote: - there's seven graphics math type proposals which would be a good project - for the graphics python using projects -- especially if they can get - into python. - - It would be great if one of these proposals was accepted to work towards - getting these simple types into python. - - Otherwise we'll be doomed to have each project implement vec2, vec3, - vec4, matrix3/4, quaternion (which has already happened many times) - - and continue to have interoperability issues. - - The reason why just these basic types, and not full blown numpy is that - numpy is never planned to get into python. Numpy doesn't want to tie - it's development into pythons development cycle. Whereas a small set of - types can be implemented and stabalised for python more easily. - - Also, it's not image, or 3d format types -- since those are also a way - larger project. -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
C. Titus Brown ctb at msu.edu writes: we're having a discussion over on the GSoC mailing list about basic math types [...] - - Otherwise we'll be doomed to have each project implement vec2, vec3, - vec4, matrix3/4, quaternion (which has already happened many times) - - and continue to have interoperability issues. This interoperability problem is the very reason the new buffer API and memoryview object were devised by Travis Oliphant (who is, AFAIK, a numpy contributor). Unfortunately, Travis disappeared and left us with an unfinished implementation which doesn't support anything else than linear byte buffers. So, rather than trying to stuff new specialized datatypes into Python, I suggest maths types proponents contribute the missing bits of the new buffer API and memoryview object :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
I'm not even sure what you mean by basic math types (it would probably depend on which math curriculum you are using :-) but if you're not already aware of PEP 3141, that's where to start. --Guido On Sat, Apr 4, 2009 at 8:09 AM, Antoine Pitrou solip...@pitrou.net wrote: C. Titus Brown ctb at msu.edu writes: we're having a discussion over on the GSoC mailing list about basic math types [...] - - Otherwise we'll be doomed to have each project implement vec2, vec3, - vec4, matrix3/4, quaternion (which has already happened many times) - - and continue to have interoperability issues. This interoperability problem is the very reason the new buffer API and memoryview object were devised by Travis Oliphant (who is, AFAIK, a numpy contributor). Unfortunately, Travis disappeared and left us with an unfinished implementation which doesn't support anything else than linear byte buffers. So, rather than trying to stuff new specialized datatypes into Python, I suggest maths types proponents contribute the missing bits of the new buffer API and memoryview object :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
C. Titus Brown wrote: we're having a discussion over on the GSoC mailing list about basic math types, and I was wondering if there is any history that we should be aware of in python-dev. Something I've suggested before is to provide a set of functions for doing elementwise arithmetic operations on objects that support the new buffer protocol. Together with a multidimensional version of the standard array.array type, this would provide a kind of numpy lite that you could use to build reasonably efficient vector and matrix types with no external dependencies. By making these functions that operate through the buffer protocol rather than special types, they would be much more flexible and interoperate with other libraries very well. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Greg Ewing greg.ewing at canterbury.ac.nz writes: Something I've suggested before is to provide a set of functions for doing elementwise arithmetic operations on objects that support the new buffer protocol. Together with a multidimensional version of the standard array.array type, this would provide a kind of numpy lite that you could use to build reasonably efficient vector and matrix types with no external dependencies. Again, I don't want to spoil the party, but multidimensional buffers are not implemented, and neither are buffers of anything other than single-byte data. Interested people should start with this, before jumping to the higher-level stuff. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Antoine Pitrou wrote: Again, I don't want to spoil the party, but multidimensional buffers are not implemented, and neither are buffers of anything other than single-byte data. When you say buffer here, are you talking about the buffer interface itself, or the memoryview object? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
2009/4/4 Greg Ewing greg.ew...@canterbury.ac.nz: Antoine Pitrou wrote: Both. Well, taking a buffer or memoryview to non-bytes data is supported, but since it's basically unused, some things are likely missing or broken So you're saying the buffer interface *has* been fully implemented, it just hasn't been tested very well? No, only simple linear bytes are supported. If so, writing some things that attempt to use it in non-trivial ways would be a useful thing to do. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Greg Ewing greg.ewing at canterbury.ac.nz writes: Again, I don't want to spoil the party, but multidimensional buffers are not implemented, and neither are buffers of anything other than single-byte data. When you say buffer here, are you talking about the buffer interface itself, or the memoryview object? Both. Well, taking a buffer or memoryview to non-bytes data is supported, but since it's basically unused, some things are likely missing or broken (e.g. memoryview.tolist()). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Antoine Pitrou wrote: Both. Well, taking a buffer or memoryview to non-bytes data is supported, but since it's basically unused, some things are likely missing or broken So you're saying the buffer interface *has* been fully implemented, it just hasn't been tested very well? If so, writing some things that attempt to use it in non-trivial ways would be a useful thing to do. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] graphics maths types in python core?
Greg Ewing greg.ewing at canterbury.ac.nz writes: So you're saying the buffer interface *has* been fully implemented, it just hasn't been tested very well? No, it hasn't been implemented for multi-dimensional types, and it hasn't been really tested for anything other than plain linear collections of bytes. (I have added tests for arrays in test_memoryview, but that's all. And that's only in py3k since array.array in 2.x only supports the old buffer interface) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
