Mailman 3 October 2009 - NumPy-Discussion

Deprecate chararray [was [SciPy-dev] Plea for help]
by David Goldsmith 02 Oct '09

02 Oct '09

--- On Thu, 8/20/09, Christopher Hanley <chanley(a)stsci.edu> wrote: > I'd like to respectfully request that we move any > discussion of what > to do with the numpy.char module to the numpy list. NP, done. > I'm a little concerned about some of the assumptions that > are being > made about the number of users of the module. I would > also like to > better understand the reasons for wanting to dump it. I think Ralf did a pretty good job of synopsizing the reasons for deprecation, but since we're moving the thread, I'll reprint them here: 0) "it gets very little use" (an assumption you presumably dispute); 1) "is pretty much undocumented" (less true than a week ago, but still true for several of the attributes, with another handful or so falling into the category of "poorly documented"); 2) "probably more buggy than most other parts of NumPy" ("probably" being a euphemism, IMO); 3) "there is not a really good use-case for it" (a conjecture, but one that has yet to be challenged by counter-example); 4) it's not the first time its presence in NumPy has been questioned ("as Stefan pointed out when asking this same question last year") 5) NumPy already has a (perhaps superior) alternative ("object arrays would do nicely if one needs this functionality"); to which I'll add: 6) it is, on its face, "counter to the spirit" of NumPy. So far, IIRC, the only reason in favor of its continued inclusion is inertia. > Let me be > clear. I'm not opposed to change. However > breaking other people's > code just for the sake of change seems like a poor reason So, I don't think we're proposing this "just for the sake of change" > and a mean > thing to do to our customers. Apologies, but it is not proposed maliciously. The only other things I would add by way of "review" from the scipy-dev thread: a compromise proposal (made by Ralf): "Put clearly in the docs that this module exists for backwards compatibility reasons, and is not recommended for new development" and a clarification of deprecation process (provided by Robert): "[asked by the present author] How has deprecation in Numpy worked in the past - by dictum, vote, or consensus? [Robert's answer] Consensus or dictum without major objection. Voting is pointless except to inform one of those." Thanks for your time and consideration. David Goldsmith > Thank you for your time and help, > Chris > > > -- > Christopher Hanley > Senior Systems Software Engineer > Space Telescope Science Institute > 3700 San Martin Drive > Baltimore MD, 21218 > (410) 338-4338 > > On Aug 20, 2009, at 1:35 AM, Robert Kern wrote: > > > On Wed, Aug 19, 2009 at 20:03, David > > Goldsmith<d_l_goldsmith(a)yahoo.com> > wrote: > >> I'm going to take it a step further: "breakage" is > always the > >> deterrent to change, and yet "change we must" > (i.e., "adapt or > >> die"). It's certainly not without precedent > - even within Numpy, I > >> believe - for things (though perhaps not whole > namespaces) to be > >> deemed "to-be-deprecated," have a warning to this > effect > >> established in one x.[even #].0 release, and then > be removed by the > >> x.[even # + 2 or + 4].0 release. How has > deprecation in Numpy > >> worked in the past - by dictum, vote, or > consensus? > > > > Consensus or dictum without major objection. Voting is > pointless > > except to inform one of those. > > > > -- > > 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 > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev(a)scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev(a)scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev >

11 31

Weird behaviour of scipy.signal.sepfir2d
by Nadav Horesh 01 Oct '09

01 Oct '09

This function function often result in incorrect output when the cpu is very loaded. I do not know how to trace the bug since every "single shot" use, or step by step trace gives the correct answer, also when running scripts under "ipython -pdb" solves the problem. System: >>> numpy.__version__ '1.4.0.dev7400' >>> scipy.__version__ '0.8.0.dev5922' Python 2.6.2 (64 bits) numpy/scipy are built with atlas support. OS: Gentoo linux (I use two independent (not a clone of each other) machines). Sorry for posting it on the numpy list, but anyway this is not the first cross-lists post. Nadav

1 0

repr and object arrays
by Charles R Harris 01 Oct '09

01 Oct '09

Hi All, It seems that repr applied do an object array does not provide the info needed to recreate it: In [22]: y = array([Decimal(1)]*2) In [23]: repr(y) Out[23]: 'array([1, 1], dtype=object)' And of course, there is going to be a problem with arrays of more than one dimension anyway. But I wonder if this should be fixed? Chuck

2 2