Re: [Numpy-discussion] recfunctions

On February 25, 2014 at 01:26:51 , Charles R Harris (charlesr.har...@gmail.com) wrote: Hi All, Does anyone recall if it was a deliberate choice to not expose recfunctions in the lib package? This is apropos issue #4242. Yes. This job was a rip-off of John Hunter’s similar functions on matplo

Re: [Numpy-discussion] read-only or immutable masked array

On Jul 13, 2013, at 13:36 , Gregorio Bastardo wrote: > Hi Stéfan, > > Thanks for the suggestion, but it does not protect the array: Thinking about it, it can't: when `x` is a MaskedArray, `x.data` is just a view of the underlying array as a regular ndarray. As far as I understand, changing

Re: [Numpy-discussion] time to revisit NA/ma ideas

On Jun 15, 2013, at 20:38 , Benjamin Root wrote: > > On Fri, Jun 14, 2013 at 6:38 PM, Eric Firing wrote: > A nice summary of the discussions from a year ago is here: > > http://www.numpy.org/NA-overview.html > > It provides food for thought. > > Eric > > Perhaps a BoF session should be put

Re: [Numpy-discussion] saving 3d array

On Jun 15, 2013, at 17:35 , Matthew Brett wrote: > Hi, > > On Sat, Jun 15, 2013 at 2:51 PM, Sudheer Joseph > wrote: >> >> Thank you very much for this tip. >> Is there a typical way to save masked and the rest separately?. Not much >> familiar with array handling in numpy. > > I don't use m

Re: [Numpy-discussion] NA, and replacement or reimplimentation of np.ma

On Jun 14, 2013, at 20:23 , Eric Firing wrote: > On 2013/06/14 7:22 AM, Nathaniel Smith wrote: >> On Wed, Jun 12, 2013 at 7:43 PM, Eric Firing wrote: >>> On 2013/06/12 2:10 AM, Nathaniel Smith wrote: Personally I think that overloading np.empty is horribly ugly, will continue confusin

Re: [Numpy-discussion] numpy.filled, again

On June 12, 2013 at 17:56:33, Daπid (davidmen...@gmail.com) wrote: On 12 June 2013 17:29, wrote: > +2 on this. > I like a good name like `filled` for a function that I expect to use regularly. > it's short and descriptive. FTIW, I am for this one too. That is not only clear, but a name that one ma

Re: [Numpy-discussion] numpy.filled, again

--Pierre GMSent with AirmailOn June 12, 2013 at 14:10:27, Nathaniel Smith (n...@pobox.com) wrote: Hi all, It looks like we've gotten a bit confused and need to untangle something. There's a PR to add new functions 'np.filled' and 'np.filled_like': https://github.com/numpy/numpy/pull/2875 And there

[Numpy-discussion] Re: empty_like for masked arrays

On June 11, 2013 at 00:40:31, Pierre GM (pgmdevl...@gmail.com) wrote: On June 10, 2013 at 23:07:24 , Eric Firing (efir...@hawaii.edu) wrote: On 2013/06/10 10:17 AM, Aldcroft, Thomas wrote: > I use np.ma , and for me the most intuitive would be the > second option where the new array match

[Numpy-discussion] Re: empty_like for masked arrays

On June 10, 2013 at 23:07:24 , Eric Firing (efir...@hawaii.edu) wrote: On 2013/06/10 10:17 AM, Aldcroft, Thomas wrote: > I use np.ma , and for me the most intuitive would be the > second option where the new array matches the original array in shape > and dtype, but always has a

[Numpy-discussion] Re: genfromtxt() skips comments

On May 31, 2013 at 23:08:18 , Albert Kottke (albert.kot...@gmail.com) wrote: I noticed that genfromtxt() did not skip comments if the keyword names is not True. If names is True, then genfromtxt() would take the first line as the names. I am proposing a fix to genfromtxt that skips all of the com

Re: [Numpy-discussion] building numpy 1.6.2 on OSX 10.6 / Python2.7.3

directory, you'll just have to update your PYTHONPATH Good luck -- Pierre GM On Tuesday, August 7, 2012 at 08:15 , Andrew Nelson wrote: Dear list, I am trying to build numpy 1.6.2 from source but am running up against a few problems. Platform: OSX10.6.8 Python: 2.7.3 (compiled using gcc 4.

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

On Tuesday, July 17, 2012 at 17:47 , Nathaniel Smith wrote: I guess I still have a small preference for skip_header="comments" over skip_header=True, since the latter is more opaque for no purpose. Also it makes me slightly antsy since skip_header is normally an integer, and True is, in fact, j

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

I don't really have any deep issue with `skip_header=True`, besides not really liking having an argument whose type can vary. But that's only a matter of personal taste. And yes, we could always check the type… > > Pierre, for a line "# A B C #1 #2 #3" the user gets six columns 'A', > 'B', 'C

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

ot;# A B C #1 #2 #3" How many columns in that case ? 6 ? 3 ? So, instead of using a `split`, maybe we should just check >>> index=first_line.index(comment) and take `first_line[:index]` (or `first_line[index+1:]` after depending on the case). But then again, it's a weird case.

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

Well, as `skip_header` is a number of lines, I don't really see anything particular magical about a `skip_header=-1`. Plus, range(-1) == [], while range("comments") raises a TypeError. And then you'd have to figure why the exception was raised. -- Pierre GM On Monday, Ju

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

To be ultra clear (since I want to code this), you are suggesting that 'first_commented_line' be a *new* accepted value for the kwarg 'names', to invoke the behaviour you suggest? Nope, I was just referring to some hypothetical variable name. I meant that: first_values = None try: while not

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

Hello, I'm siding w/ Tom, Nathaniel and Travis. I don't think the change as it is is advisable. It's a regression, and breaking=bad. Now, I can understand your frustration, so, what about a trade-off? The first line w/ a comment after the first 'skip_header' ones should be parsed for column titles

Re: [Numpy-discussion] Istalling Numpy and Scipy on preinstalled Python 2.6 on Mac

: just use `your_path_to_your_python_version setup install --user` Let me know how it goes -- Pierre GM On Friday, July 13, 2012 at 19:22 , Naser Nikandish wrote: > Hi, > > I need to install numpy and scipy on preinstalled Python 2.6 on my Mac Lion. > Is there anyway to do it? I am aware that Lio

[Numpy-discussion] masked and missing values, a historical perspective and some comments

All, I’ve been fairly quiet on the various missing/masked values proposals, sorry about that. I figured I would take the opportunity of Travis O.’s deadline of Wed. 16th to put some aspects of numpy.ma in a semi-historical, semi-personal perspective. Apologies in advance if I misrepresent some asp

Re: [Numpy-discussion] change masked array member values with conditional selection

Ciao Chao, That known quirk deserves to be better documented, I agree. There's a simple explanation for this behavior: Because `a` is a masked array, `(a < 5)` is also a masked array with dtype=np.bool, and whose mask is the same as `a`'s. In your example, that's: masked_array(data = [-- -- -- Tr

Re: [Numpy-discussion] Recovering from a STOP ?

Pauli, Chris, Thanks for your inputs. Pauli, I think that when f2py encounters a STOP statement, it just stops the execution of the process. Alas, it's the same process as the interpreter... So we need a trick not to interrupt the whole process. I eventually resorted to patching f2py as suggested

Re: [Numpy-discussion] Question on numpy.ma.masked_values

py.org/numpy/ticket/2082 > > > > On Thu, Mar 15, 2012 at 1:24 PM, Gökhan Sever wrote: > >> >> >> On Thu, Mar 15, 2012 at 1:12 PM, Pierre GM wrote: >> >>> Ciao Gökhan, >>> AFAIR, shrink is used only to force a collapse of a mask full of False, >

Re: [Numpy-discussion] Question on numpy.ma.masked_values

Ciao Gökhan, AFAIR, shrink is used only to force a collapse of a mask full of False, not to force the creation of such a mask. Now, it should work as you expected, meaning that it needs to be fixed. Could you open a ticket? And put me in copy, just in case. Anyhow: Your trick is a tad dangerous, as

[Numpy-discussion] Recovering from a STOP ?

THYC Dear all, I'm working with some large inherited F90 code that needs to be wrapped in Python. if the code base itself cannot be modified (it's a static archive), some additional F90 files were written to help the interaction with the code. Writing a python extension combining the archive and

Re: [Numpy-discussion] numpy 1.7.0 release?

On Dec 07, 2011, at 11:24 , Pierre Haessig wrote: > > Now for my personal use, I was not so frustrated by loading performance > but rather by NA support, so I wrote my own loadCsv function to get a > masked array. It was nor beautiful, neither very efficient, but it does > the job ! Ever trie

Re: [Numpy-discussion] Indexing a masked array with another masked array leads to unexpected results

On Nov 03, 2011, at 23:07 , Joe Kington wrote: > I'm not sure if this is exactly a bug, per se, but it's a very confusing > consequence of the current design of masked arrays… I would just add a "I think" between the "but" and "it's" before I could agree. > Consider the following example: > >

Re: [Numpy-discussion] Preventing an ndarray subclass from returning new subclass instances for std(), etc

> > Anyway, back on topic - I'm having similar problems as Keith. It seems like > there isn't consistency on how different built-in functions treat > array_wrap/finalize/etc, or maybe I'm still confused. Actually, that depends on the np function you need. Functions like np.std… first call the

Re: [Numpy-discussion] Preventing an ndarray subclass from returning new subclass instances for std(), etc

On Sep 18, 2011, at 21:25 , Stéfan van der Walt wrote: > On Sun, Sep 18, 2011 at 9:48 AM, Keith Hughitt > wrote: >> Interesting. It works as expected when called as a method: >> >> In [10]: x = np.ma.array([[1,2,3]]) >> In [11]: x.std() >> Out[11]: 0.81649658092772603 > > I'm guessing that np

Re: [Numpy-discussion] load from text files Pull Request Review

On Sep 13, 2011, at 01:38 , Christopher Jordan-Squire wrote: > I did some timings to see what the advantage would be, in the simplest > case possible, of taking multiple lines from the file to process at a > time. Assuming the dtype is already known. The code is attached. What > I found was I can

Re: [Numpy-discussion] A question about dtype syntax

On Aug 31, 2011, at 4:24 PM, Jean-Baptiste Marquette wrote: > > Hi Pierre, > >> >> On Aug 31, 2011, at 3:40 PM, Jean-Baptiste Marquette wrote: >>> Traceback (most recent call last): >>> File "/Users/marquett/workspace/Distort/src/StatsSep.py", line 44, in >>> >>>np.savetxt(Table, StatsA

Re: [Numpy-discussion] A question about dtype syntax

On Aug 31, 2011, at 3:40 PM, Jean-Baptiste Marquette wrote: > Traceback (most recent call last): > File "/Users/marquett/workspace/Distort/src/StatsSep.py", line 44, in > > np.savetxt(Table, StatsAll, delimiter=' ', fmt=['%15s %.5f %.5f %5d %.4f > %.4f']) > File > "/Library/Frameworks/

Re: [Numpy-discussion] A question about dtype syntax

On Aug 31, 2011, at 12:20 PM, Jean-Baptiste Marquette wrote: > > Hi Pierre, > > Thanks for the guess. Unfortunately, I got the same error: > > [('bs3000k.cat', 280.60341, -7.09118, 9480, 0.2057, 0.14)] > Traceback (most recent call last): > File "/Users/marquett/workspace/Distort/src/StatsSe

Re: [Numpy-discussion] A question about dtype syntax

On Aug 30, 2011, at 10:46 AM, Marquette Jean-Baptiste wrote: > Hi all, > > I have this piece of code: > > Stats = [CatBase, round(stats.mean(Data.Ra), 5), round(stats.mean(Data.Dec), > 5), len(Sep), round(stats.mean(Sep),4), round(stats.stdev(Sep),4)] > print Stats > if First: > StatsAll

Re: [Numpy-discussion] limit to number of fields in recarray

On Aug 2, 2011, at 1:20 AM, Craig Yoshioka wrote: > Is there a limit to the number of fields a numpy recarray can have? I was > getting a strange error about a duplicate column name, but it wasn't a > duplicate. And the error was… ? ___ NumPy-Discu

Re: [Numpy-discussion] boolean array indexing and broadcasting rules

On Jul 29, 2011, at 4:07 PM, Mark Wiebe wrote: > As part of supporting the NA mask, I've rewritten boolean indexing. Here's a > timing comparison of my version versus a previous version: > > In [2]: np.__version__ > Out[2]: '1.4.1' > In [3]: a = np.zeros((1000,1000)) > In [4]: mask = np.random.

Re: [Numpy-discussion] using the same vocabulary for missing value ideas

On Jul 7, 2011, at 8:46 AM, Eric Firing wrote: > On 07/06/2011 07:51 PM, Chris Barker wrote: >> On 7/6/11 11:57 AM, Mark Wiebe wrote: >>> On Wed, Jul 6, 2011 at 1:25 PM, Christopher Barker >> >>> Is this really true? if you use a bitpattern for IGNORE, haven't you >>> just lost the abili

Re: [Numpy-discussion] NA/Missing Data Conference Call Summary

On Jul 6, 2011, at 10:11 PM, Bruce Southey wrote: > On 07/06/2011 02:38 PM, Christopher Jordan-Squire wrote: >> >> >> On Wed, Jul 6, 2011 at 11:38 AM, Christopher Barker >> wrote: >> Christopher Jordan-Squire wrote: >> > If we follow those rules for IGNORE for all computations, we sometimes >

Re: [Numpy-discussion] using the same vocabulary for missing value ideas

Ah, semantics... On Jul 6, 2011, at 5:40 PM, Mark Wiebe wrote: > > NA (Not Available) > A placeholder for a value which is unknown to computations. That > value may be temporarily hidden with a mask, may have been lost > due to hard drive corruption, or gone for any number of reasons

Re: [Numpy-discussion] Moving lib.recfunctions?

On Jul 5, 2011, at 9:23 PM, Skipper Seabold wrote: > On Tue, Jul 5, 2011 at 2:46 PM, Pierre GM wrote: >>> >>> <...> >> >> Hello, >> The idea behin having a lib.recfunctions and not a rec.recfunctions or >> whatever was to illustrate that

Re: [Numpy-discussion] Moving lib.recfunctions?

On Jul 5, 2011, at 8:33 PM, Skipper Seabold wrote: > On Fri, Jul 1, 2011 at 2:32 PM, Skipper Seabold wrote: >> On Fri, Jul 1, 2011 at 2:22 PM, wrote: >>> On Fri, Jul 1, 2011 at 1:59 PM, Skipper Seabold wrote: lib.recfunctions has never been fully advertised. The two bugs I just disc

Re: [Numpy-discussion] An NA compromise idea -- many-NA

Mask an array with NAs? You should be able to, as IGNORE<>NA. Mask an array with a view? That's sharing the data with a different mask, you should be able to, too (np.ma works like that). Sharing mask? That'd be great if we could... That way, there'd be almost nothing left to do to adapt np.ma... O

Re: [Numpy-discussion] alterNEP - was: missing data discussion round 2

On Jul 1, 2011 7:14 PM, "Mark Wiebe" wrote: > > On Fri, Jul 1, 2011 at 10:15 AM, Nathaniel Smith wrote: >> >> On Fri, Jul 1, 2011 at 7:09 AM, Mark Wiebe wrote: >> > On Fri, Jul 1, 2011 at 6:58 AM, Matthew Brett >> > wrote: >> >> Do you see problems with the alterNEP proposal? >> > >> > Yes, I r

Re: [Numpy-discussion] alterNEP - was: missing data discussion round 2

On Jun 30, 2011, at 5:38 PM, Matthew Brett wrote: > Hi, > > On Thu, Jun 30, 2011 at 2:58 PM, Pierre GM wrote: >> >> On Jun 30, 2011, at 3:31 PM, Matthew Brett wrote: >>> ### >>> A altern

Re: [Numpy-discussion] alterNEP - was: missing data discussion round 2

On Jun 30, 2011, at 3:31 PM, Matthew Brett wrote: > ### > A alternative-NEP on masking and missing values > ### I like the idea of two different special values, np.NA for missing values, np.IGNORE for masked

Re: [Numpy-discussion] missing data discussion round 2

Matthew, Dag, +1. On Jun 29, 2011 4:35 PM, "Dag Sverre Seljebotn" wrote: > On 06/29/2011 03:45 PM, Matthew Brett wrote: >> Hi, >> >> On Wed, Jun 29, 2011 at 12:39 AM, Mark Wiebe wrote: >>> On Tue, Jun 28, 2011 at 5:20 PM, Matthew Brett >>> wrote: Hi, On Tue, Jun 28, 2011 at 4:0

Re: [Numpy-discussion] missing data discussion round 2

On Jun 29, 2011, at 1:39 AM, Mark Wiebe wrote: > On Tue, Jun 28, 2011 at 5:20 PM, Matthew Brett > wrote: > Hi, > > On Tue, Jun 28, 2011 at 4:06 PM, Nathaniel Smith wrote: > ... > > (You might think, what difference does it make if you *can* unmask an > > item? Us missing data folks could just

Re: [Numpy-discussion] missing data discussion round 2

On Jun 29, 2011, at 1:37 AM, Mark Wiebe wrote: > On Tue, Jun 28, 2011 at 3:45 PM, Pierre GM wrote: > ... > > I think that would really take care of the missing data part in a consistent > and non-ambiguous way. > However, I understand that if a choice would be made, this

Re: [Numpy-discussion] missing data discussion round 2

All, I'm not sure I understand some aspects of Mark's new proposal, sorry (blame the lack of sleep). I'm pretty excited with the idea of built-in NA like np.dtype(NA['float64']), provided we can come with some shortcuts like np.nafloat64. I think that would really take care of the missing data p

Re: [Numpy-discussion] missing data discussion round 2

On Jun 28, 2011, at 9:41 PM, Eric Firing wrote: > > One of the real frustrations of the present masked array is that there > is no savez/load support. I could roll my own by using a convention > like saving the mask of xxx as xxx__mask__, and then reversing the > process in a modified load; b

Re: [Numpy-discussion] missing data discussion round 2

On Jun 27, 2011, at 9:59 PM, josef.p...@gmail.com wrote: > > Just a question how things would work with the new model. > How can you implement the "use" keyword from R's cov (or cor), with > minimal data copying > > I think the basic masked array version would (or does) just assign 0 > to the mi

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

This thread is getting quite long, innit ? And I think it's getting a tad confusing, because we're mixing two different concepts: missing values and masks. There should be support for missing values in numpy.core, I think we all agree on that. * What's been suggested of adding new dtypes (naflo

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 24, 2011, at 4:44 PM, Robert Kern wrote: > On Fri, Jun 24, 2011 at 09:35, Robert Kern wrote: >> On Fri, Jun 24, 2011 at 09:24, Keith Goodman wrote: >>> On Fri, Jun 24, 2011 at 7:06 AM, Robert Kern wrote: >>> The alternative proposal would be to add a few new dtypes that are N

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 24, 2011, at 2:56 AM, Benjamin Root wrote: > > As a heavy masked_array user, I regret not being able to participate more in > this discussion as I am madly cranking out matplotlib code. I would like to > say that I have always seen masked arrays as being the "next step up" from > using

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 24, 2011, at 2:42 AM, Mark Wiebe wrote: > On Thu, Jun 23, 2011 at 7:28 PM, Pierre GM wrote: > Sorry y'all, I'm just commenting bits by bits: > > "One key problem is a lack of orthogonality with other features, for instance > creating a masked array wit

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 24, 2011, at 2:21 AM, Charles R Harris wrote: > > > On Thu, Jun 23, 2011 at 6:00 PM, Nathaniel Smith wrote: > On Thu, Jun 23, 2011 at 2:44 PM, Robert Kern wrote: > > On Thu, Jun 23, 2011 at 15:53, Mark Wiebe wrote: > >> Enthought has asked me to look into the "missing data" problem an

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

Sorry y'all, I'm just commenting bits by bits: "One key problem is a lack of orthogonality with other features, for instance creating a masked array with physical quantities can't be done because both are separate subclasses of ndarray. The only reasonable way to deal with this is to move the m

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 24, 2011, at 12:43 AM, Mark Wiebe wrote: > On Thu, Jun 23, 2011 at 5:24 PM, Pierre GM wrote: > ... > Mmh, after timeseries, now masked arrays... Mark, I start to see a pattern > here ;) > > I think it speaks to what's on Enthought's mind, in any case

Re: [Numpy-discussion] feedback request: proposal to add masks to the core ndarray

On Jun 23, 2011, at 11:55 PM, Mark Wiebe wrote: > On Thu, Jun 23, 2011 at 4:46 PM, Charles R Harris > wrote: > On Thu, Jun 23, 2011 at 2:53 PM, Mark Wiebe wrote: > Enthought has asked me to look into the "missing data" problem and how NumPy > could treat it better. I've considered the differe

Re: [Numpy-discussion] fixing up datetime

On Jun 11, 2011, at 1:03 AM, Mark Wiebe wrote: > > I don't think you would want to extend the datetime with more metadata, but > rather use it as a tool to create the timeseries with. You could create a > lightweight wrapper around datetime arrays which exposed a > timeseries-oriented interfac

Re: [Numpy-discussion] code review for datetime arange

On Jun 11, 2011, at 12:57 AM, Mark Wiebe wrote: > The other issue is how do you define the np.arange step argument since that > can be in different scales such as month, years, seconds? Can a user specific > days and get half-days (like 1.5 days) or must these be 'integer' days? > > The dateti

Re: [Numpy-discussion] fixing up datetime

> > The fact that it's a NumPy dtype probably is the biggest limiting factor > preventing parameters like 'start' and 'end' during conversion. Having a > datetime represent an instant in time neatly removes any ambiguity, so > converting between days and seconds as a unit is analogous to conver

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 9, 2011, at 2:22 AM, Mark Wiebe wrote: > > > >>> np.array(['2011-03-12T13', '2012'], dtype='M8') > > > array(['2011-03-12T13:00:00.00-0600', > > > '2011-12-31T18:00:00.00-0600'], dtype='datetime64[us]') > > > > Why is the second one not '2012-01-01T00:00:00-0600' ? > > > > This is

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 9, 2011, at 1:10 AM, Mark Wiebe wrote: > > > >>> np.timedelta64(10, 's') + 10 > > numpy.timedelta64(20,'s') > > Here, the unit is defined: 's' > > For the first operand, the inconsistency is with the second. Here's the > reasoning I didn't spell out: > We're adding a timedelta + int, s

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 8, 2011, at 11:05 PM, Mark Wiebe wrote: > The NEP and current implementation of the datetime specifies microseconds as > the default unit when constructing and converting to datetimes and timedeltas. AFAIU, the default is [us] when otherwise unspecified. > Here are some current behavior

Re: [Numpy-discussion] fixing up datetime

> > It supports .astype(), with a truncation policy. This is motivated partially > because that's how Pythons integer division works, and partially because if > you consider a full datetime '2011-03-14T13:22:16', it's natural to think of > the year as '2011', the date as '2011-03-14', etc, whic

Re: [Numpy-discussion] fixing up datetime

On Jun 8, 2011, at 1:16 AM, Mark Wiebe wrote: > Hi Dave, > > Thanks for all the feedback on the datetime, it's very useful to help > understand the timeseries ideas, in particular with the many examples you're > sprinkling in. > > One overall impression I have about timeseries in general is t

Re: [Numpy-discussion] fixing up datetime

es like A-SEP to represent a year starting in September, for example. It works, but it's really not elegant a solution. On Jun 7, 2011, at 6:53 PM, Christopher Barker wrote: > Pierre GM wrote: >> Using the ISO as reference, you have a good definition of months. > > Yes,

Re: [Numpy-discussion] fixing up datetime

On Jun 6, 2011, at 8:33 PM, Christopher Barker wrote: > Mark Wiebe wrote: >> I'm wondering if removing the business-day unit from datetime64, and >> adding a business-day API would be a good approach to support all the >> things that are needed? > > That sounds like a good idea to me -- and pe

Re: [Numpy-discussion] fixing up datetime

On Jun 2, 2011, at 6:57 PM, Christopher Barker wrote: > Mark Wiebe wrote: >> I'm following what I understand the NEP to mean for combining dates and >> deltas of different units. This means for timedeltas, the metadata >> becomes more precise, in particular it becomes the GCD of the input >> m

Re: [Numpy-discussion] fixing up datetime

On Jun 1, 2011, at 11:16 PM, Mark Wiebe wrote: > On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris > wrote: > > > Just a quick comment, as this really needs more thought, but time is a bag of > worms. > > Certainly a bag of worms, I agree. Oh yes... Keep in mind that the inclusion of time i

Re: [Numpy-discussion] Changing milestones on tickets

On May 31, 2011, at 9:06 PM, Ralf Gommers wrote: > > It is helpful to have this cleaned up, thanks Mark for taking the time for > this. Mind you, I do agree with y'all for the cleaning up. I just had a shock when I received the batch of what I thought were brand new bugs that turned up to have

Re: [Numpy-discussion] loadtxt ndmin option

On May 31, 2011, at 6:37 PM, Derek Homeier wrote: > On 31 May 2011, at 18:25, Pierre GM wrote: > >> On May 31, 2011, at 5:52 PM, Derek Homeier wrote: >>> >>> I think stuff like multiple delimiters should have been dealt with >>> before, as the righ

Re: [Numpy-discussion] loadtxt ndmin option

On May 31, 2011, at 5:52 PM, Derek Homeier wrote: > > I think stuff like multiple delimiters should have been dealt with > before, as the right place to insert the ndmin code (which includes > the decision to squeeze or not to squeeze as well as to add additional > dimensions, if required)

Re: [Numpy-discussion] Changing milestones on tickets

On May 31, 2011, at 6:06 PM, Bruce Southey wrote: > On 05/31/2011 10:33 AM, Mark Wiebe wrote: >> On Tue, May 31, 2011 at 10:09 AM, Pierre GM wrote: >> >> On May 31, 2011, at 4:25 PM, Mark Wiebe wrote: >> >> > It's so we can see what bugs are actually f

Re: [Numpy-discussion] loadtxt ndmin option

On May 31, 2011, at 4:53 PM, Derek Homeier wrote: > Hi Chris, > > On 31 May 2011, at 13:56, cgraves wrote: > >> I've downloaded the latest numpy (1.6.0) and loadtxt has the ndmin >> option, >> however neither genfromtxt nor recfromtxt, which use loadtxt, have it. >> Should they have inherited

Re: [Numpy-discussion] Changing milestones on tickets

On May 31, 2011, at 4:25 PM, Mark Wiebe wrote: > It's so we can see what bugs are actually fixed for 2.0 (as opposed to a > prior release), and a bug that's marked 'closed' but Unscheduled simply > doesn't make sense to me. I'm sorry, I'm still failing to see the logic. * You're not sure whet

[Numpy-discussion] Changing milestones on tickets

All, Could somebody tell me the advantage of changing the milestone of tickets that have been closed for more than 10 months ? I'm genuinely curious. P. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/

Re: [Numpy-discussion] Data standardizing

On Apr 12, 2011, at 8:48 PM, Climate Research wrote: > Hi > I am purely new to python and numpy.. I am using python for doing > statistical calculations to Climate data.. Check the scikits.timeseries and scikits.hydroclimpy as well, they have routines for that very purpose. _

Re: [Numpy-discussion] Remove deprecated skiprows

On Apr 6, 2011, at 12:16 AM, Alan G Isaac wrote: > On 4/5/2011 6:11 PM, Skipper Seabold wrote: >> To my mind, skip_headers is a bool Well, that's understandable... So, yet another change of name to skip_header_lines, skip_footer_lines, with the deprecation that goes with it ? More seriously, a

Re: [Numpy-discussion] Remove deprecated skiprows

On Apr 5, 2011, at 11:52 PM, Ralf Gommers wrote: > On Tue, Apr 5, 2011 at 11:45 PM, Skipper Seabold wrote: >> On Sun, Apr 3, 2011 at 8:20 PM, Charles R Harris >> wrote: >>> Should skiprows be removed? >>> >>> if skiprows: >>> warnings.warn(\ >>> "The use of `skiprows` i

Re: [Numpy-discussion] loadtxt/savetxt tickets

Y'all, Just a quick word before disappearing again: genfromtxt was designed to support files that don't have a well-defined structure (eg, the number and format of the column is unknown, some entries may be missing, and so forth). That was initially just an improved rec2csv from matplotlib back

Re: [Numpy-discussion] {zeros, empty, ...}_like functions behavior with subclasses

On Mar 1, 2011, at 1:05 AM, Bruce Southey wrote: > On Mon, Feb 28, 2011 at 4:52 PM, Wes McKinney wrote: >> I'm having some trouble with the zeros_like function via np.fix: >> >> def zeros_like(a): >>if isinstance(a, ndarray): >>res = ndarray.__new__(type(a), a.shape, a.dtype, order=

Re: [Numpy-discussion] bug in genfromtxt with missing values?

On Jan 25, 2011, at 9:06 PM, Bruce Southey wrote: > Your filling_values is zero so there is this line (1295?) in the code: > user_filling_values = filling_values or [] > > Which of cause presumes your filling_values is not something like 0 or [0]. That's the bug. I forgot that filling_values cou

Re: [Numpy-discussion] bug in genfromtxt with missing values?

On Jan 24, 2011, at 11:47 PM, Skipper Seabold wrote: > Am I misreading the docs or missing something? Consider the following > adapted from here: > http://docs.scipy.org/doc/numpy/user/basics.io.genfromtxt.html > > from StringIO import StringIO > import numpy as np > > data = "1, 2, 3\n4, ,5"

Re: [Numpy-discussion] mapping a function to a masked array

On Jan 12, 2011, at 12:45 PM, Ben Elliston wrote: > I have a masked array of values that I would like to transform through > a user-defined function. Naturally, I want to ignore any values that > are masked in the initial array. > > The user-defined function examines other points around the val

Re: [Numpy-discussion] Warning: invalid value encountered in subtract

On Nov 30, 2010, at 11:22 PM, Keith Goodman wrote: > On Tue, Nov 30, 2010 at 1:41 PM, Skipper Seabold wrote: >> On Tue, Nov 30, 2010 at 1:34 PM, Keith Goodman wrote: >>> After upgrading from numpy 1.4.1 to 1.5.1 I get warnings like >>> "Warning: invalid value encountered in subtract" when I run

Re: [Numpy-discussion] subdivide array

On Nov 30, 2010, at 5:40 PM, John wrote: > Hello, > > I have an array of data for a global grid at 1 degree resolution. It's > filled with 1s and 0s, and it is just a land sea mask (not only, but > as an example). I want to be able to regrid the data to higher or > lower resolutions (i.e. 0.5 or

Re: [Numpy-discussion] Test failures on 2.6

On Oct 5, 2008, at 10:53 PM, T J wrote: > Hi, > > I'm getting a couple of test failures with Python 2.6, Numpy 1.2.0, Nose > 0.10.4: Wow, 1.2.0 ? That's fairly ancient. I gather the bugs in numpy.ma have been corrected since (they don't really look familiar, though). And with a more recent n

Re: [Numpy-discussion] dtypes error in recfunctions

On Nov 15, 2010, at 11:43 PM, Benjamin Root wrote: > Hello, > > I was using append_fields() in numpy.lib.recfunctions when I discovered a > slight logic mistake in handling the dtypes argument. > > The code first checks to see if dtypes is None. If so, it then guesses the > dtype info from t

Re: [Numpy-discussion] numpy.genfromtxt converters issue

On Nov 15, 2010, at 1:07 PM, Lluís wrote: > Pierre GM writes: > >> On Nov 14, 2010, at 9:30 PM, Lluís wrote: > >>> This will work as long as 'first_values' is assured to always contain >>> valid data and as long as its indexes are equivalent to thos

Re: [Numpy-discussion] numpy.genfromtxt converters issue

On Nov 14, 2010, at 9:30 PM, Lluís wrote: > This will work as long as 'first_values' is assured to always contain > valid data and as long as its indexes are equivalent to those in > converters (which I simply haven't checked). I beat you to it, actually ;) Check the git push I committed earlier

Re: [Numpy-discussion] numpy.genfromtxt converters issue

On Nov 11, 2010, at 8:31 PM, Lluís wrote: > Pierre GM writes: > >> In practice, that's exactly what happens below the hood when >> genfromtxt tries to guess the output type of the converter. It tries a >> single value ('1'), fails, and decides that the

Re: [Numpy-discussion] numpy.genfromtxt converters issue

All, Sorry for the delayed answer. I had a bit of time and examined the issue in more details: As you've seen, the output of your converter is not detected as a float, but as an object. That's an unfortunate side effect of using a lambda function such as yours: what if your input string has onl

Re: [Numpy-discussion] numpy.genfromtxt converters issue

On Nov 6, 2010, at 2:22 PM, Damien Moore wrote: > Hi List, > > I'm trying to import csv data as a numpy array using genfromtxt. The csv file > contains mixed data, some floating point, others string codes and dates that > I want to convert to floating point. The strange thing is that when I us

Re: [Numpy-discussion] np.ma.masked_invalid and precision

On Oct 31, 2010, at 9:28 PM, bevan jenkins wrote: > Hello, > > I am not sure if the following is a bug or not. I recently tried to set the > print precision in numpy but it didn't seem to make a difference. It seems > that the use of np.ma.masked_invalid results in arrays printing precision of

Re: [Numpy-discussion] ndarray __getattr__ to perform __getitem__

On Oct 29, 2010, at 3:58 PM, Ian Stokes-Rees wrote: > >> Note that there are various extant projects that I think attempt to >> provide similar functionality to what you're wanting (unless I badly >> misread your original email, in which case apologies): >> http://projects.scipy.org/numpy/wi

Re: [Numpy-discussion] genfromtxt behaviour

On Oct 29, 2010, at 2:59 PM, Matt Studley wrote: > > >>> How can I do my nice 2d slicing on the latter? >>> >>> array([('a', 2, 3), ('b', 5, 6), ('c', 8, 9)], >>> dtype=[('f0', '|S1'), ('f1', ' >> Select a column by its name: >> yourarray['f0'] > > Super! > > So I would need to get the

Re: [Numpy-discussion] genfromtxt behaviour

On Oct 29, 2010, at 2:35 PM, Matt Studley wrote: > Hi all > > first, please forgive me for my ignorance - I am taking my first > stumbling steps with numpy and scipy. No problem, it;s educational > I am having some difficulty with the behaviour of genfromtxt. > > s = SIO.StringIO("""1, 2, 3 >

Re: [Numpy-discussion] Awaiting confirmation before closing tickets

On Oct 15, 2010, at 12:47 AM, Friedrich Romstedt wrote: > 2010/10/11 Pierre GM : >> All, >> The following tickets could be closed if somebody confirmed everything works >> OK: >> * 1586: fixed in r8714 >> * 1593: fixed in r8715 >> * 1591: fixed in r8713

Re: [Numpy-discussion] Development workflow

On Oct 12, 2010, at 5:38 PM, David Cournapeau wrote: > On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote: >> >> git push >> The files created by setup.py develop are marked as not added but pollute >> some of the reports (diff, eg). > > I am still not f

  1   2   3   4   5   6   7   8   >