[Numpy-discussion] Blurring an Array
Hello, I'm working on a program that will draw me a metallic 3D texture. I successfully made a Perlin noise implementation and found that when the result is blurred in one direction, the result actually looks somewhat like brushed aluminum. The plan is to do this for every n*m*3 layer (2D texture) in the 3D texture. My solution to this anisotropic blurring looks like: soften = layerarray.copy() total = 1 for bluriter in xrange(1,5,1): soften[:,bluriter:] += layerarray[:,:-bluriter] soften[:,:-bluriter] += layerarray[:,bluriter:] total += 2 soften /= total Where layerarray is a n*m*3 array, and soften is the array that will be converted into an image with the other 2D images and saved. This code successfully blurs the array in the y-direction. However, it does not do so the way I would like. The blur is accomplished by a simple shift, making the arrays not line up. This leaves space at the edges. When the final soften array is divided by total, those areas are especially dark. Visually, this is unacceptable, and leads to banding, which is especially evident if the texture is repeated. As you can see in this image, which shows about 6 repeats of the texture, http://img13.imageshack.us/img13/5789/image1wgq.png, the dark edges are annoying. I made sure, of course, that the Perlin noise implementation is tileable. The solution to my problem is to make the shifted array wrap around so that its overhang fills in the hole the shift caused it to leave behind. For example, to simulate shifting the texture 8 units up with wrap, the first 8 rows should be removed from the top and added to the bottom. Likewise for columns if the blur goes in that direction. I already tried a couple of times at this, and it's not working. I need a way to blur soften by column and by row. Thanks, Ian ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Blurring an Array
On Sun, Jun 21, 2009 at 02:04, Ian Mallett geometr...@gmail.com wrote: Hello, I'm working on a program that will draw me a metallic 3D texture. I successfully made a Perlin noise implementation and found that when the result is blurred in one direction, the result actually looks somewhat like brushed aluminum. The plan is to do this for every n*m*3 layer (2D texture) in the 3D texture. My solution to this anisotropic blurring looks like: soften = layerarray.copy() total = 1 for bluriter in xrange(1,5,1): soften[:,bluriter:] += layerarray[:,:-bluriter] soften[:,:-bluriter] += layerarray[:,bluriter:] total += 2 soften /= total Use scipy.ndimage.convolve() and an appropriate convolution kernel. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Blurring an Array
Sounds like it would work, but unfortunately numpy was one of my dependency constraints. I should have mentioned that. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Blurring an Array
On Sun, Jun 21, 2009 at 03:31, Ian Mallett geometr...@gmail.com wrote: Sounds like it would work, but unfortunately numpy was one of my dependency constraints. I should have mentioned that. In that case, use numpy.roll() instead of slicing to get wraparound. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
(Continuing the discussion initiated in the neighborhood iterator thread) Hi, I would like to gather people's opinion on what to target for numpy 1.4.0. - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). - Even if not many new features have been implemented since 1.3.0, there were several changes which would be quite useful (using npy_math from numpy for scipy.special, neighborhood iterator for scipy.signal). So releasing 1.4.0 soon would be useful so that scipy 0.8.0 could depend on it. - Fixing crashes on windows 64 bits: I have not made any progress on this. I am out of ideas on how to debug the problem, to be honest. Are there any other features people would like to put into numpy for 1.4.0 ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Blurring an Array
This works perfectly! Is there likewise a similar call for Numeric? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 5:01 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: (Continuing the discussion initiated in the neighborhood iterator thread) Hi, I would like to gather people's opinion on what to target for numpy 1.4.0. - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). - Even if not many new features have been implemented since 1.3.0, there were several changes which would be quite useful (using npy_math from numpy for scipy.special, neighborhood iterator for scipy.signal). So releasing 1.4.0 soon would be useful so that scipy 0.8.0 could depend on it. - Fixing crashes on windows 64 bits: I have not made any progress on this. I am out of ideas on how to debug the problem, to be honest. Are there any other features people would like to put into numpy for 1.4.0 ? I've been trying to engage the numpy developers on a proposal to enhance the array wrapping mechanism in ufuncs. The goal is to enable suclasses of ndarray like MaskedArray and Quantity to work with the built-in ufuncs instead of having to reimplement them. Here is the thread: http://www.nabble.com/suggestion-for-generalizing-numpy-functions-tt22413628.html#a22413628 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.ukwrote: David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. Will requiring python-2.6 help the developers port numpy to python-3? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 11:55 PM, Darren Daledsdal...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. Will requiring python-2.6 help the developers port numpy to python-3? It will help, but it is unclear whether it will be a significant help. From what I have seen, very few non trivial C extensions have been ported so far, and it is not even clear to me whether it will be possible to support both python 2.x and python 3.x at the same time (without a huge amount of work, that is). David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 8:55 AM, Darren Daledsdal...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. Will requiring python-2.6 help the developers port numpy to python-3? Can't really say at this point, but it is the suggested path to python-3. I raised the point to start a discussion. My thoughts are that we need to make the move at some point next year. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 9:42 AM, Charles R Harrischarlesr.har...@gmail.com wrote: On Sun, Jun 21, 2009 at 8:55 AM, Darren Daledsdal...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. Will requiring python-2.6 help the developers port numpy to python-3? Can't really say at this point, but it is the suggested path to python-3. I raised the point to start a discussion. My thoughts are that we need to make the move at some point next year. Before that move we should have a version of numpy that doesn't need many fixes and that supports developments in scipy so that folks can get good functionality sticking to that release for a while without upgrading. But we do need to think a bit about what that entails. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Mon, Jun 22, 2009 at 12:42 AM, Charles R Harrischarlesr.har...@gmail.com wrote: On Sun, Jun 21, 2009 at 8:55 AM, Darren Daledsdal...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:38 AM, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. Will requiring python-2.6 help the developers port numpy to python-3? Can't really say at this point, but it is the suggested path to python-3. OTOH, I don't find the python 3 official transition story very convincing. I have tried to gather all the information I could find, both on the python wiki and from transitions stories. To support both python 2 and 3, the suggestion is to use the 2to3 script, but it is painfully slow for big packages like numpy. And there ave very few stories for porting python 3 C extensions. Another suggestion is to avoid breaking the API when transitioning for python 3. But that seems quite unrealistic. How do we deal with the removing of string/long APIs ? This will impact the numpy API as well, so how do we deal with it ? Also, there does not seem to be any advantages for python 3 for scientific people ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Mon, Jun 22, 2009 at 12:59 AM, David Cournapeaucourn...@gmail.com wrote: Another suggestion is to avoid breaking the API when transitioning for python 3. But that seems quite unrealistic. How do we deal with the removing of string/long APIs ? ^ This should be int, of course, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
I'm still using 2.4, but I plan to go to 2.5 when the project we're doing now reaches a stable point later this year. Not sure after that. I know it's real work to keep several versions going, but I sense there are a lot of people in the 2.4 - 2.5 window. I guess 2.6 is a mini step toward 3.0. The problem with each step is that all the libraries we rely on have to be ugraded to that step or we might lose the functionality of that library. For me that's a killer. I have to take a good look at all of them before the upgrade or a big project will take a fatal hit. -- Lou Pecora, my views are my own. --- On Sun, 6/21/09, John Reid j.r...@mail.cryst.bbk.ac.uk wrote: From: John Reid j.r...@mail.cryst.bbk.ac.uk Subject: Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0 To: numpy-discussion@scipy.org Date: Sunday, June 21, 2009, 10:38 AM David Cournapeau wrote: (Continuing the discussion initiated in the neighborhood iterator thread) - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). I vote against dropping support for python 2.5. Personally I have no incentive to upgrade to 2.6 and am very happy with 2.5. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
Lou Pecora wrote: I'm still using 2.4, but I plan to go to 2.5 when the project we're doing now reaches a stable point later this year. Not sure after that. I know it's real work to keep several versions going, but I sense there are a lot of people in the 2.4 - 2.5 window. I guess 2.6 is a mini step toward 3.0. The problem with each step is that all the libraries we rely on have to be ugraded to that step or we might lose the functionality of that library. For me that's a killer. I have to take a good look at all of them before the upgrade or a big project will take a fatal hit. +1 I'd like even support for Python 2.3. Many basic libraries still support 2.3 . Recently I wanted to download the latest numpy for 2.3 which I need for some projects and :-( . Just since 2008-08-01 they dropped both 2.3 and 2.4. Is there a serious reason? And numpy is a very basic library. And what is in numpy (scipy) that requires advanced language syntax? Its just about numbers and slices. A few ifdef's for new concepts like new base classes. It needs nothing of the real news of advanced Pythons. A thing like numpy/scipy is most simple regarding code structure. It should be easy to offer it for old Pythons - at least 2.3 which is the inofficial Python 2 baseline for library producers. Even a complex GUI app like Pythonwin (where it is very tempting to use advanced sugar) is still supported for even 2.2 Regarding Python 2 - 3 Migration. Look at e.g. Cython - it produces C code with a few #ifdef's and macros and which compiles both in Py2 (2.3+) and Py3. Its quite simple to maintain. Also Python code can be written so, that it can be auto-transposed from 2 - 3 for long time: by 2to3 + pyXpy comment transposition language like print x #$3 print(x) #$3 only_py3_func() only_py2_func() #$3 It would be drastic to force the basis for numpy to Py3 so early - unless a back direction is offered. And numpy should/could in my opinion be one of the last libraries which cuts off support for old Pythons. - One of the itching problems when using numpy with smaller apps, scripts, web and with freezers is, that import is very slow, and it rams almost the whole numpy into the memory. Many fat dlls like _dotblas, etc. And there are strange (unnecessary) dependencies between the branches and files. See thread minimal numpy?. That all threatens usabilty of numpy in a many areas. Its designed like loading numpy/scipe in the lab in the morning and exiting in the evening. That is too sloopy for a basic library which adds a efficient key array class to Python. numpy should be usable in a much lighter way. If import numpy shall by default still import most of numpy - ok, but there should perhaps be at least an easy mechanism to stop this all-in-one behavior and dependencies with an easy switch. Or with import numpy.base Or in my opinion the reverse behavior would be more decent for a library: import numpy imports only the minimum (like in that other thread) and import numpy.anth[ology] as np or so may draw the whole mess as before. inter-DLL-imports like multiarray.pyd - umath.pyd should use relative imports (like the py modules next to them). Such cleanup of the code organization and improving usability etc I think is more important than playing a role as leading py3 enforcer Robert ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
I don't remember dropping support for 2.4. When did that happen? Sent from my iPhone On Jun 21, 2009, at 12:17 PM, Robert kxrobe...@googlemail.com wrote: Lou Pecora wrote: I'm still using 2.4, but I plan to go to 2.5 when the project we're doing now reaches a stable point later this year. Not sure after that. I know it's real work to keep several versions going, but I sense there are a lot of people in the 2.4 - 2.5 window. I guess 2.6 is a mini step toward 3.0. The problem with each step is that all the libraries we rely on have to be ugraded to that step or we might lose the functionality of that library. For me that's a killer. I have to take a good look at all of them before the upgrade or a big project will take a fatal hit. +1 I'd like even support for Python 2.3. Many basic libraries still support 2.3 . Recently I wanted to download the latest numpy for 2.3 which I need for some projects and :-( . Just since 2008-08-01 they dropped both 2.3 and 2.4. Is there a serious reason? And numpy is a very basic library. And what is in numpy (scipy) that requires advanced language syntax? Its just about numbers and slices. A few ifdef's for new concepts like new base classes. It needs nothing of the real news of advanced Pythons. A thing like numpy/scipy is most simple regarding code structure. It should be easy to offer it for old Pythons - at least 2.3 which is the inofficial Python 2 baseline for library producers. Even a complex GUI app like Pythonwin (where it is very tempting to use advanced sugar) is still supported for even 2.2 Regarding Python 2 - 3 Migration. Look at e.g. Cython - it produces C code with a few #ifdef's and macros and which compiles both in Py2 (2.3+) and Py3. Its quite simple to maintain. Also Python code can be written so, that it can be auto-transposed from 2 - 3 for long time: by 2to3 + pyXpy comment transposition language like print x #$3 print(x) #$3 only_py3_func() only_py2_func() #$3 It would be drastic to force the basis for numpy to Py3 so early - unless a back direction is offered. And numpy should/could in my opinion be one of the last libraries which cuts off support for old Pythons. - One of the itching problems when using numpy with smaller apps, scripts, web and with freezers is, that import is very slow, and it rams almost the whole numpy into the memory. Many fat dlls like _dotblas, etc. And there are strange (unnecessary) dependencies between the branches and files. See thread minimal numpy?. That all threatens usabilty of numpy in a many areas. Its designed like loading numpy/scipe in the lab in the morning and exiting in the evening. That is too sloopy for a basic library which adds a efficient key array class to Python. numpy should be usable in a much lighter way. If import numpy shall by default still import most of numpy - ok, but there should perhaps be at least an easy mechanism to stop this all-in-one behavior and dependencies with an easy switch. Or with import numpy.base Or in my opinion the reverse behavior would be more decent for a library: import numpy imports only the minimum (like in that other thread) and import numpy.anth[ology] as np or so may draw the whole mess as before. inter-DLL-imports like multiarray.pyd - umath.pyd should use relative imports (like the py modules next to them). Such cleanup of the code organization and improving usability etc I think is more important than playing a role as leading py3 enforcer Robert ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 4:04 PM, Travis Oliphantoliph...@enthought.com wrote: I don't remember dropping support for 2.4. When did that happen? It didn't, numpy should still run with 2.4. If there is a problem I haven't heard about it. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Sun, Jun 21, 2009 at 4:01 AM, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: (Continuing the discussion initiated in the neighborhood iterator thread) Hi, I would like to gather people's opinion on what to target for numpy 1.4.0. - Chuck suggested to drop python 2.6 support from now on. I am against it without a very strong and detailed rationale, because many OS still don't have python 2.6 (RHEL, Ubuntu LTS). - Even if not many new features have been implemented since 1.3.0, there were several changes which would be quite useful (using npy_math from numpy for scipy.special, neighborhood iterator for scipy.signal). So releasing 1.4.0 soon would be useful so that scipy 0.8.0 could depend on it. - Fixing crashes on windows 64 bits: I have not made any progress on this. I am out of ideas on how to debug the problem, to be honest. I think this is an essential requirement for numpy. I am prepared to attempt to try to help as I now have a 64-bit windows system I can use. Just that I do not like the windows environment for programming one bit. So I would appreciate any pointers to get the necessary functional system for 64-bit windows. Probably the other item I would suggest is resolving the Matrix issues and having the best solution implemented. Bruce ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Mon, Jun 22, 2009 at 7:04 AM, Travis Oliphantoliph...@enthought.com wrote: I don't remember dropping support for 2.4. When did that happen? It does work on 2.4, I regularly test numpy and scipy on RHEL 5 with 64 bits python 2.4. We dropped 2.3 support since 1.2 IIRC. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Memmap + resize
hello, is it possible to resize in place a memmap array? thanks in advice Luigi -- ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Io sono lo sbaglio, il momento di confusione, l'inopportuno Non sono niente. Non sarò mai niente. Non posso volere d'essere niente. A parte questo, ho in me tutti i sogni del mondo. F. Pessoa ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Plans for Numpy 1.4.0 and scipy 0.8.0
On Mon, Jun 22, 2009 at 2:17 AM, Robertkxrobe...@googlemail.com wrote: I'd like even support for Python 2.3. Many basic libraries still support 2.3 and many don't :) In my experience, the limit is often python 2.4 (which we still support). And numpy is a very basic library. And what is in numpy (scipy) that requires advanced language syntax? Its just about numbers and slices. A few ifdef's for new concepts like new base classes. It needs nothing of the real news of advanced Pythons. A thing like numpy/scipy is most simple regarding code structure. It is certainly not easy - it depends on some quite obscure features of the C API. The problem is not that numpy is supposedly just about numbers and slices, but the number of C API calls to python which change between versions. A lot changed between python 2 and python 3. To give you an idea: numpy is ~ 80 000 LOC of C, 55000 LOC of python. There is as much C code in numpy than in the object implementation in python (float, int, object, list, dict, tuples, etc...). Effectively, porting numpy is like porting the core objects of python. We certainly don't have as many resources as python. It would be drastic to force the basis for numpy to Py3 so early - unless a back direction is offered. Agreed - that's why nobody suggested it. One of the itching problems when using numpy with smaller apps, scripts, web and with freezers is, that import is very slow very slow is a stretch - it is around 100 ms on a recent computer on decent OS. It is difficult to be much faster without breaking compatibility. And there are strange (unnecessary) dependencies between the branches and files. Yes, there are some strange dependencies of say numpy.core on other subpackages. I agree this should change (this causes me a lot of headache when debugging on windows, for example, and that's the major problem while building numpy statically into python interpreter). But it is not always easy without breaking someone else's code. If import numpy shall by default still import most of numpy - ok, but there should perhaps be at least an easy mechanism to stop this all-in-one behavior and dependencies with an easy switch. this has been suggested before. We can't break the current behavior, because so many people depend on it, but having two modes of import is not good either. It means doubling the amount of configurations to test, for once. That's not maintainable. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Blurring an Array
On Sun, Jun 21, 2009 at 05:48, Ian Mallett geometr...@gmail.com wrote: This works perfectly! Is there likewise a similar call for Numeric? If Numeric.roll() exists, then yes. Otherwise, you may have to look at the numpy.roll() sources to replicate what it does. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
