Re: [Numpy-discussion] numpy.random.poisson docs missing Returns
Sat, 26 Jun 2010 17:37:22 -0700, David Goldsmith wrote: On Sat, Jun 26, 2010 at 3:22 PM, josef.p...@gmail.com wrote: [clip] Is there a chance that some changes got lost? (Almost) anything's possible... :-( There's practically no change of edits getting lost. There's a change of them being hidden if things are moved around in the source code, causing duplicate work, but that's not the case here. Well, here's what happened in the particular case of numpy's pareto: The promotion to Needs review took place - interestingly - 2008-06-26 (yes, two years ago today), despite the lack of a Returns section; the initial check-in of HOWTO_DOCUMENT.txt - which does specify that a Returns section be included (when applicable) - was one week before, 2008-06-19. So, it's not that surprising that this slipped through the cracks. Pauli (or anyone): is there a way to search the Wiki, e.g., using a SQL-like query, for docstrings that saw a change in status before a date, or between two dates? No. The review status is not versioned, so the necessary information is not there. The only chance would be to search for docstrings that haven't been edited after a certain date. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] issue #1431 accessing multiple fields in a recarray
Hello
A while ago there was a discussion about field order when accessing recarrays.
eg:
x = np.array([(1.5,2.5,(1.0,2.0)),(3.,4.,(4.,5.)),(1.,3.,(2.,6.))],
dtype=[('x','f4'),('y',np.float32),('value','f4',(2,2))])
x[['x','y']]
array([(1.5, 2.5), (3.0, 4.0), (1.0, 3.0)],
dtype=[('x', 'f4'), ('y', 'f4')])
x[['y','x']]
array([(1.5, 2.5), (3.0, 4.0), (1.0, 3.0)],
dtype=[('x', 'f4'), ('y', 'f4')])
http://thread.gmane.org/gmane.comp.python.numeric.general/36933
There is a bug at http://projects.scipy.org/numpy/ticket/1431
The fix is very simple, but there was some worry that some existing code may
require the broken behavior. eg some code may ask for:
x[['y','x']]
and expect the result to have 'x' as the first column in the result.
I suspect that code like this is rare (it could be easily changed to
x[['x','y']] if thats what is really wanted).
I think the correct way to proceed is probably to raise a DeprecationWarning
for code that it requiring the broken behavior. The bug has a patch to
implement this. Then in a future version the patch to fix it could be applied.
Thanks
Sam
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Is numpy ignoring CFLAGS?
On some 64-bit platforms, which include, but is not limited to: * Some version of OS X (I don't know what versions or processors) * Solaris on SPARC processors. * Solaris on x86 processors. * OpenSolaris on SPARC processors. * OpenSolaris on x86 processors. * HP-UX on PA-RISC processors. the default is to build 32-bit objects, but 64-bit objects can be created if needed. This is usually done via adding the -m64 flag when compiling with GCC or SunStudio, though the flag will be different with HP's compiler. Numpy is used as part of Sage, but it would appear that adding -m64 to CFLAGS will not work. A comment in the script used to build numpy shows: # numpy's distutils is buggy and runs a conftest without # taking CFLAGS into account. With 64 bit OSX this results # in *boom* it then goes on to copy a file called gcc_fake, which is basically a script which gets renamed to gcc, but includes the -m64 flag. We are using numpy-1.3.0. Is this a known bug? If not, can I submit it to a bug database? Better still, does anyone have a patch to resolve it - I hate the idea of making I've now changed the build method in Sage so it does not only work on OS X, and does not hard-code the path to gcc. I have: if [ x$SAGE64 = xyes ]; then echo Building a 64-bit version of numpy # HACK ALERT # HACK ALERT # HACK ALERT echo HACK ALERT - HACK ALERT - HACK ALERT echo HACK ALERT - HACK ALERT - HACK ALERT echo HACK ALERT - HACK ALERT - HACK ALERT echo Creating a sort of fake gcc, which has the -m64 flag echo #!/usr/bin/env bash $SAGE_LOCAL/bin/gcc echo `command -v gcc` -m64 \$@ $SAGE_LOCAL/bin/gcc chmod 755 $SAGE_LOCAL/bin/gcc fi This this file $SAGE_LOCAL/bin/gcc is used to build just numpy. After that, we can remove it if [ x$SAGE64 = xyes ]; then echo deleting fake gcc rm $SAGE_LOCAL/bin/gcc fi and let the normal gcc program be used with an appropriate setting of CFLAGS to make other packages build 64-bit. I know this issue has been known in Sage for a long time (years) but I don't know if it was ever reported to the Numpy mailing list or added to any bug database Dave ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Solving a NLLSQ Problem by Pieces?
Thanks for the info. Where do I find hugin? The paper I'm looking is from 1987. It is not clear what actual method he used. Probably something popular of those times. Things have changed. :-) Yes, scipy might be a better place to post this, and I will. Hmmm, I think I have had problems finding a connection to a scipy mail list. Astropy is lightly traveled, but I'll give it a shot. On 6/26/2010 10:32 AM, Anne Archibald wrote: The basic problem with nonlinear least squares fitting, as with other nonlinear minimization problems, is that the standard algorithms find only a local minimum. It's easy to miss the global minimum and instead settle on a local minimum that is in fact a horrible fit. To deal with this, there are global optimization techniques - simulated annealing, genetic algorithms, and what have you (including the simplest, explore the whole space with a dense enough grid then fine-tune the best one with a local optimizer) - but they're computationally very expensive and not always reliable. So when it's possible to use domain-specific knowledge to make sure what you're settling on is the real minimum, this is a better solution. In this specific case, as in many optimization problems, the problem can be viewed as a series of nested approximations. The crudest approximation might even be linear in some cases; but the point is, you solve the first approximation first because it has fewer parameters and a solution space you understand better (e.g. maybe you can be sure it only has one local minimum). Then because your approximations are by assumption nested, adding more parameters complicates the space you're solving over, but you can be reasonably confident that you're close to the right solution already. (If your approximations are orthogonal in the right sense, you can even fix the parameters from previous stages and optimize only the new ones; be careful with this, though.) This approach is a very good way to incorporate domain-specific knowledge into your code, but you need to parameterize your problem as a series of nested approximations, and if it turns out the corrections are not small you can still get yourself into trouble. (Or, for that matter, if the initial solution space is complex enough you can still get yourself in trouble. Or if you're not careful your solver can take your sensible initial guess at some stage and zip off into never-never land instead of exploring nearby.) If you're interested in how other people solve this particular problem, you could take a look at the open-source panorama stitcher hugin, which fits for a potentially very large number of parameters, including a camera model. To bring this back nearer to on-topic, you will naturally not find domain-specific knowledge built into scipy or numpy, but you will find various local and global optimizers, some of which are specialized for the case of least-squares. So if you wanted to implement this sort of thing with scipy, you could write the domain-specific code yourself and simply call into one of scipy's optimizers. You could also look at OpenOpt, a scikit containing a number of global optimizers. Anne P.S. This question would be better suited to scipy-user or astropy than numpy-discussion. -A On 26 June 2010 13:12, Wayne Watsonsierra_mtnv...@sbcglobal.net wrote: The context here is astronomy and optics. The real point is in the last paragraph. I'm looking at a paper that deals with 5 NL (nonlinear) equations and 8 unknown parameters. A. a=a0+arctan((y-y0)/(x-x0) B. z=V*r+S*e**(D*r) r=sqrt((x-x0)**2+(y-y0)**2) and C. cos(z)=cos(u)*cos(z)-sin(u)*sin(ep)*cos(b) sin(a-E) = sin(b)*sin(u)/sin(z) He's trying to estimate parameters of a fisheye lens which has taken star images on a photo plate. For example, x0,y0 is the offset of the center of projection from the zenith (camera not pointing straight up in the sky.) Eq. 2 expresses some nonlinearity in the lens. a0, xo, y0, V, S, D, ep, and E are the parameters. It looks like he uses gradient descent (NLLSQ is nonlinear least squares in Subject.), and takes each equation in turn using the parameter values from the preceding one in the next, B. He provides reasonable initial estimates. A final step uses all eight parameters. He re-examines ep and E, and assigns new estimates. For all (star positions) on the photo plate, he minimizes SUM (Fi**2*Gi) using values from the step for A and B, except for x0,y0. He then does some more dithering, which I'll skip. What I've presented is probably a bit difficult to understand without a good optics understanding, but my question is something like is this commonly done to solve a system of NLLSQ? It looks a bit wild. I guess if one knows his subject well, then bringing some extra knowledge to the process helps. As I understand it, he solves parameters in A, then uses them in B, and so on. I guess that's a reasonable way to do it.
Re: [Numpy-discussion] Solving a NLLSQ Problem by Pieces?
Found hugin (google), but I think it's a bit too general for my current interests. You might enjoy an optimization video course from Stanford Univ on the web. http://see.stanford.edu/see/lecturelist.aspx?coll=17005383-19c6-49ed-9497-2ba8bfcfe5f6 -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Air travel safety Plus Three/Minus 8 rule. Eighty % of crashes take place in the first 3 minutes and last 8 minutes. Survival chances are good in you're paying attention. No hard drinks prior to those periods. No sleeping pills either. Sit within 5 rows of an exit door. --The Survivors Club, Ben Sherwood Web Page:www.speckledwithstars.net/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser
warren.weckes...@enthought.com wrote:
Kurt Smith wrote:
I'd really like arr.copy(order='F') to work -- is it supposed to as
its docstring says, or is it supposed to raise a TypeError as it does
now?
It works for me if I don't use the keyword. That is,
b = a.copy('F')
Great! At least the functionality is there.
But I get the same error if I use order='F', so there is a either a bug
in the docstring or a bug in the code.
I certainly hope it's a docstring bug and not otherwise.
Any pointers on submitting documentation bugs?
Kurt
Warren
This is on numpy 1.4
import numpy as np
a = np.arange(10).reshape(5,2)
a
array([[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]])
print a.copy.__doc__
a.copy(order='C')
Return a copy of the array.
Parameters
--
order : {'C', 'F', 'A'}, optional
By default, the result is stored in C-contiguous (row-major) order in
memory. If `order` is `F`, the result has 'Fortran' (column-major)
order. If order is 'A' ('Any'), then the result has the same order
as the input.
Examples
x = np.array([[1,2,3],[4,5,6]], order='F')
y = x.copy()
x.fill(0)
x
array([[0, 0, 0],
[0, 0, 0]])
y
array([[1, 2, 3],
[4, 5, 6]])
y.flags['C_CONTIGUOUS']
True
a.copy(order='C')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
a.copy(order='F')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
___
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Strange behavior of np.sinc
On Sat, Jun 26, 2010 at 10:00 PM, David Goldsmith d.l.goldsm...@gmail.comwrote: On Sat, Jun 26, 2010 at 9:39 PM, Robert Kern robert.k...@gmail.comwrote: On Sat, Jun 26, 2010 at 23:33, David Goldsmith d.l.goldsm...@gmail.com wrote: Hi! The docstring for numpy.lib.function_base.sinc indicates that the parameter has to be an ndarray, and that it will return the limiting value 1 for sinc(0). Checking to see if it should actually say array_like, I found the following (Python 2.6): np.sinc(np.array((0,0.5))) array([ 1., 0.63661977]) np.sinc((0,0.5)) array([NaN, 0.63661977]) np.sinc([0,0.5]) array([NaN, 0.63661977]) np.version.version '1.4.1' So, it doesn't choke on non-array sequences, and appears to return values consistent w/ array input, except at 0. Bug in code (failure at 0 if in a sequence) and in the doc (ndarray should be array_like)? Bug in both code and docs. There should be an x = np.asanyarray(x) before the rest of the code. Thanks Robert; I'll file a ticket and fix the docstring. DG All done (patched this morning and Pauli's checked it in already - nice when they're easy). DG -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
On Sun, Jun 27, 2010 at 10:38 AM, Kurt Smith kwmsm...@gmail.com wrote:
On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser
warren.weckes...@enthought.com wrote:
Kurt Smith wrote:
I'd really like arr.copy(order='F') to work -- is it supposed to as
its docstring says, or is it supposed to raise a TypeError as it does
now?
It works for me if I don't use the keyword. That is,
b = a.copy('F')
Great! At least the functionality is there.
But I get the same error if I use order='F', so there is a either a bug
in the docstring or a bug in the code.
I certainly hope it's a docstring bug and not otherwise.
Any pointers on submitting documentation bugs?
Kurt
Same as filing a code bug: file a ticket at projects.scipy.org/numpy, But
the policy is to document desired behavior, not actual behavior (if the code
isn't behaving as advertised but it should, obviously that's a code bug), so
you can do one of two things: a) wait 'til someone replies here clarifying
which it is, or b) file a ticket which describes the inconsistency and let
the issue be worked out over there (preferred IMO 'cause it gets the ticket
filed while the issue is fresh in your mind, and any discussion of what kind
of bug it is gets recorded as part of the ticket history). Thanks for
reporting/filing!
DG
Warren
This is on numpy 1.4
import numpy as np
a = np.arange(10).reshape(5,2)
a
array([[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]])
print a.copy.__doc__
a.copy(order='C')
Return a copy of the array.
Parameters
--
order : {'C', 'F', 'A'}, optional
By default, the result is stored in C-contiguous (row-major)
order in
memory. If `order` is `F`, the result has 'Fortran'
(column-major)
order. If order is 'A' ('Any'), then the result has the same
order
as the input.
Examples
x = np.array([[1,2,3],[4,5,6]], order='F')
y = x.copy()
x.fill(0)
x
array([[0, 0, 0],
[0, 0, 0]])
y
array([[1, 2, 3],
[4, 5, 6]])
y.flags['C_CONTIGUOUS']
True
a.copy(order='C')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
a.copy(order='F')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
___
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide. (As interpreted
by Robert Graves)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.random.poisson docs missing Returns
On Sun, Jun 27, 2010 at 3:44 AM, Pauli Virtanen p...@iki.fi wrote: Sat, 26 Jun 2010 17:37:22 -0700, David Goldsmith wrote: On Sat, Jun 26, 2010 at 3:22 PM, josef.p...@gmail.com wrote: [clip] Is there a chance that some changes got lost? (Almost) anything's possible... :-( There's practically no change of edits getting lost. But there is a chance of edits not being saved (due to operator error, e.g., inadvertently clicking cancel): happened to me just yesterday while making edits to gumbel; reminded me -the hard way- of another reason to make extensive edits on one's own machine, then cut/paste them into the edit window in the Wiki when done. There's a change of them being hidden if things are moved around in the source code, causing duplicate work, but that's not the case here. Well, here's what happened in the particular case of numpy's pareto: The promotion to Needs review took place - interestingly - 2008-06-26 (yes, two years ago today), despite the lack of a Returns section; the initial check-in of HOWTO_DOCUMENT.txt - which does specify that a Returns section be included (when applicable) - was one week before, 2008-06-19. So, it's not that surprising that this slipped through the cracks. Pauli (or anyone): is there a way to search the Wiki, e.g., using a SQL-like query, for docstrings that saw a change in status before a date, or between two dates? Thanks Pauli. Anyway, I figured out another way: I'm using the stats page, and checking anything that was Needs review or better before 2008-06-19 and up to a month after - after that, we'll just have to trust that the review process will detect it. FWIW, the only docs I've found so far w/ that particular error are the ones that Vincent found -you did say you found three, right Vincent?- but I've found other problems w/ other docstrings (some of which have since advanced past the state they were in back then, i.e., the errors went undetected even though someone has ostensibly reviewed them.) DG DG No. The review status is not versioned, so the necessary information is not there. The only chance would be to search for docstrings that haven't been edited after a certain date. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
On Sun, Jun 27, 2010 at 1:03 PM, David Goldsmith
d.l.goldsm...@gmail.com wrote:
On Sun, Jun 27, 2010 at 10:38 AM, Kurt Smith kwmsm...@gmail.com wrote:
On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser
warren.weckes...@enthought.com wrote:
Kurt Smith wrote:
I'd really like arr.copy(order='F') to work -- is it supposed to as
its docstring says, or is it supposed to raise a TypeError as it does
now?
It works for me if I don't use the keyword. That is,
b = a.copy('F')
Great! At least the functionality is there.
But I get the same error if I use order='F', so there is a either a bug
in the docstring or a bug in the code.
I certainly hope it's a docstring bug and not otherwise.
Any pointers on submitting documentation bugs?
Kurt
Same as filing a code bug: file a ticket at projects.scipy.org/numpy, But
the policy is to document desired behavior, not actual behavior (if the code
isn't behaving as advertised but it should, obviously that's a code bug), so
you can do one of two things: a) wait 'til someone replies here clarifying
which it is, or b) file a ticket which describes the inconsistency and let
the issue be worked out over there (preferred IMO 'cause it gets the ticket
filed while the issue is fresh in your mind, and any discussion of what kind
of bug it is gets recorded as part of the ticket history). Thanks for
reporting/filing!
I misspoke (mistyped...). So long as it has the 'F' behavior I'm
happy, and I'll gladly file a bug report patch to get the code to
match the docs, assuming that's the intended behavior.
Who do I contact about getting a trac account?
Thanks,
Kurt
DG
Warren
This is on numpy 1.4
import numpy as np
a = np.arange(10).reshape(5,2)
a
array([[0, 1],
[2, 3],
[4, 5],
[6, 7],
[8, 9]])
print a.copy.__doc__
a.copy(order='C')
Return a copy of the array.
Parameters
--
order : {'C', 'F', 'A'}, optional
By default, the result is stored in C-contiguous (row-major)
order in
memory. If `order` is `F`, the result has 'Fortran'
(column-major)
order. If order is 'A' ('Any'), then the result has the same
order
as the input.
Examples
x = np.array([[1,2,3],[4,5,6]], order='F')
y = x.copy()
x.fill(0)
x
array([[0, 0, 0],
[0, 0, 0]])
y
array([[1, 2, 3],
[4, 5, 6]])
y.flags['C_CONTIGUOUS']
True
a.copy(order='C')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
a.copy(order='F')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: copy() takes no keyword arguments
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?
Sun, 27 Jun 2010 13:41:23 -0500, Kurt Smith wrote: [clip] I misspoke (mistyped...). So long as it has the 'F' behavior I'm happy, and I'll gladly file a bug report patch to get the code to match the docs, assuming that's the intended behavior. The problem is probably that the function is using PyArg_ParseTuple instead of PyArg_ParseTupleAndKeywords Who do I contact about getting a trac account? Go to http://projects.scipy.org/numpy/ and select Register. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] printing of array and leading white space ?
I don't know precisely how the decision is made, but in general one needs the pad spaces for printing arrays with 1 row. Friedrich 2010/6/26 Vincent Davis vinc...@vincentdavis.net: This is a little strange and I am not sure what is going on. Look at the number of spaced before the first number in the array. x = np.array([629.54440098249688162, 26186.5470310494529258 ]) x array([ 629.54440098249688162, 26186.5470310494529258 ]) 3 spaces before 629.544... x = np.array([629.54440098249688162, 2634186.5470310494529258 ]) x array([ 6.29544400982496882e+02, 2.63418654703104962e+06]) 2 spaces There are many different ways experiment, and I assume that the spaces are there to help the printed array look better. The 3 spaces are not there is the second digit is shorter. The thing is I can't think of an example where the 3 spaces are needed. Is there an example? Vincent ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] issue #1431 accessing multiple fields in a recarray
On Sun, Jun 27, 2010 at 8:26 AM, sam tygier samtyg...@yahoo.co.uk wrote:
Hello
A while ago there was a discussion about field order when accessing
recarrays. eg:
x = np.array([(1.5,2.5,(1.0,2.0)),(3.,4.,(4.,5.)),(1.,3.,(2.,6.))],
dtype=[('x','f4'),('y',np.float32),('value','f4',(2,2))])
x[['x','y']]
array([(1.5, 2.5), (3.0, 4.0), (1.0, 3.0)],
dtype=[('x', 'f4'), ('y', 'f4')])
x[['y','x']]
array([(1.5, 2.5), (3.0, 4.0), (1.0, 3.0)],
dtype=[('x', 'f4'), ('y', 'f4')])
http://thread.gmane.org/gmane.comp.python.numeric.general/36933
There is a bug at http://projects.scipy.org/numpy/ticket/1431
The fix is very simple, but there was some worry that some existing code may
require the broken behavior. eg some code may ask for:
x[['y','x']]
and expect the result to have 'x' as the first column in the result.
I suspect that code like this is rare (it could be easily changed to
x[['x','y']] if thats what is really wanted).
I think the correct way to proceed is probably to raise a DeprecationWarning
for code that it requiring the broken behavior. The bug has a patch to
implement this. Then in a future version the patch to fix it could be applied.
+1 to applying the DeprecationWarning patch.
Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
