Re: [Numpy-discussion] Please stop bottom posting!!

On 04/04/2013 12:00 AM, Chris Barker - NOAA Federal wrote: > OK, OK, I know the fashion is to blast people with "please don't top > post" messages -- it seems to have invaded all the mailing lists I'm > on. > > But I don't get it. > > Most of us have threaded mail readers these days, so is it so ha

Re: [Numpy-discussion] timezones and datetime64

On 4/3/13, Benjamin Root wrote: > On Wed, Apr 3, 2013 at 7:52 PM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: > >> >> Personally, I never need finer resolution than seconds, nor more than >> a century, so it's no big deal to me, but just wondering >> >> > A use case for finer

Re: [Numpy-discussion] timezones and datetime64

On Wed, Apr 3, 2013 at 7:52 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > > Personally, I never need finer resolution than seconds, nor more than > a century, so it's no big deal to me, but just wondering > > A use case for finer resolution than seconds (in our field, no le

[Numpy-discussion] Moving linalg c code

Hi All, There is a PR that adds some blas and lapack functions to numpy. I'm thinking that if that PR is merged it would be good to move all of the blas and lapack functions, including the current ones in numpy/linalg into a single directory somewhere in

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Wed, Apr 3, 2013 at 9:13 PM, Matthew Brett wrote: > Hi, > > On Wed, Apr 3, 2013 at 11:44 AM, Matthew Brett > wrote: >> Hi, >> >> On Wed, Apr 3, 2013 at 8:52 AM, Chris Barker - NOAA Federal >> wrote: >>> On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg >>> wrote: > the context where it get

Re: [Numpy-discussion] Please stop bottom posting!!

On 04/03/2013 08:06 PM, Charles R Harris wrote: Nice editing! ;) Steve ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Hi, On Wed, Apr 3, 2013 at 11:44 AM, Matthew Brett wrote: > Hi, > > On Wed, Apr 3, 2013 at 8:52 AM, Chris Barker - NOAA Federal > wrote: >> On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg >> wrote: the context where it gets applied. So giving the same strategy two different names is si

Re: [Numpy-discussion] timezones and datetime64

On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote: > Mark Wiebe gmail.com> writes: > > It seems to me that adding a time zone to the datetime64 > > metadata might be a good idea, and then allowing it to be > > None to behave like the Python naive datetimes. > > Probably also TAI and UTC/Posix

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

On Wed, Apr 3, 2013 at 5:11 PM, huangkan...@gmail.com wrote: > Agree with the row-vector and column-vector thing. I notice that in > ndarray multiplication, the 1-d array is treated as a column-vector. But > in matrix multiplication, 1-d array is converted to a row-vector. So just > match the 1-d

Re: [Numpy-discussion] Please stop bottom posting!!

What's the problem? ;) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Please stop bottom posting!!

On Wed, Apr 3, 2013 at 4:28 PM, Doug Coleman wrote: > Also, gmail "bottom-posts" by default. It's transparent to gmail users. I'd > imagine they are some of the biggest offenders. Not with my configuration -- which I don't hink I changed -- it's top posting by default for me. however, gmail doe

Re: [Numpy-discussion] Please stop bottom posting!!

On Wed, Apr 3, 2013 at 7:28 PM, Doug Coleman wrote: > I swear by a mouse with an unlockable scroll wheel. Scroll to your heart's > content! > > http://www.amazon.com/Logitech-G500-Programmable-Gaming-Mouse/dp/B002J9GDXI > > > Also, gmail "bottom-posts" by default. It's transparent to gmail users.

Re: [Numpy-discussion] timezones and datetime64

Thanks all for taking an interest. I need to think a bot more about the options before commenting more, but: while we're at it: It seems very odd to me that datetime64 supports different units (right down to attosecond) but not different epochs. How can it possible be useful to use nanoseconds,

Re: [Numpy-discussion] Please stop bottom posting!!

I swear by a mouse with an unlockable scroll wheel. Scroll to your heart's content! http://www.amazon.com/Logitech-G500-Programmable-Gaming-Mouse/dp/B002J9GDXI Also, gmail "bottom-posts" by default. It's transparent to gmail users. I'd imagine they are some of the biggest offenders. Doug _

Re: [Numpy-discussion] timezones and datetime64

Mark Wiebe gmail.com> writes: > It seems to me that adding a time zone to the datetime64 > metadata might be a good idea, and then allowing it to be > None to behave like the Python naive datetimes. Probably also TAI and UTC/Posix. Converting from one format to the other is problematic since all

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

Agree with the row-vector and column-vector thing. I notice that in ndarraymultiplication, the 1-d array is treated as a column-vector. But in matrix multiplication, 1-d array is converted to a row-vector. So just match the 1-d array to a column-vector, the behavior of ndarray and matrix will be co

Re: [Numpy-discussion] Please stop bottom posting!!

On Wed, Apr 3, 2013 at 3:21 PM, Nathaniel Smith wrote: > On Wed, Apr 3, 2013 at 11:00 PM, Chris Barker - NOAA Federal > wrote: >> Best of all is intelligent editing of the thread so far ... > Traditionally this is what the phrase "bottom posting" meant, as a > term of art, and is the key reason w

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

On Wed, Apr 3, 2013 at 1:03 PM, Alan G Isaac wrote: > On 4/3/2013 3:18 PM, huangkan...@gmail.com wrote: > In my view, the result should be a 1d array, > the same as I.A.dot(x). > > But the maintainers wanted operations with matrices to > return matrices whenever possible. So instead of > returni

Re: [Numpy-discussion] Please stop bottom posting!!

On Wed, Apr 3, 2013 at 11:00 PM, Chris Barker - NOAA Federal wrote: > Best of all is intelligent editing of the thread so far -- edit it > down to the key points you are commenting on, and intersperse your > comments. That way your email stands on its own as meaningful, but > there is not a big pi

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

On Wed, 2013-04-03 at 16:03 -0400, Alan G Isaac wrote: > On 4/3/2013 3:18 PM, huangkan...@gmail.com wrote: > > A 5*5 matrix multiplies another matrix, we expect answer to be error or a > > 5*? matrix, not a 1*5 matrix. > > > That is what happens. > But you are post"multiplying" a matrix by a one

[Numpy-discussion] Please stop bottom posting!!

OK, OK, I know the fashion is to blast people with "please don't top post" messages -- it seems to have invaded all the mailing lists I'm on. But I don't get it. Most of us have threaded mail readers these days, so is it so hard to follow a thread? Maybe I'm a weirdo, but it is FAR more common f

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Wed, Apr 3, 2013 at 11:52 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > On Wed, Apr 3, 2013 at 11:39 AM, Matthew Brett > wrote: > > It was not enough for me or the three others who will publicly admit > > to the shame of finding it confusing without further thought. > > I w

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Wed, Apr 3, 2013 at 11:39 AM, Matthew Brett wrote: > It was not enough for me or the three others who will publicly admit > to the shame of finding it confusing without further thought. I would submit that some of the confusion came from the fact that with ravel(), and the 'A' and 'K' flags, y

Re: [Numpy-discussion] timezones and datetime64

On Wed, Apr 3, 2013 at 9:33 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > wrote: > > I found no reasonable way around it other than bypassing the numpy > conversion entirely > > Exactly - we have come to the same conclusion. By the way, it's also > consistent -- an ISO string

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

On 4/3/2013 3:18 PM, huangkan...@gmail.com wrote: > A 5*5 matrix multiplies another matrix, we expect answer to be error or a 5*? > matrix, not a 1*5 matrix. That is what happens. But you are post"multiplying" a matrix by a one-dimensional list. What should happen then? That is the question. O

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

I know matrix will call the dot function of ndarray. However, that will not give the answer we expect. A 5*5 matrix multiplies another matrix, we expect answer to be error or a 5*? matrix, not a 1*5 matrix. As ticket 2649 said, I * I * x or I.dot(I.dot(x)) should be as same as I * x. But it will r

Re: [Numpy-discussion] timezones and datetime64

Travis Oliphant continuum.io> writes: > > > Mark Wiebe and I are both still tracking NumPy development and can provide context and even help when needed.    Apologies if we've left a different impression.   We have to be prudent about the time we spend as we have other projects we are pursui

Re: [Numpy-discussion] try to solve issue #2649 and revisit #473

On 4/3/2013 2:44 PM, huangkan...@gmail.com wrote: > I suggest add function dot to matrix >>> import numpy as np; x = np.arange(5); I = np.asmatrix(np.identity(5)); >>> I.dot(x) matrix([[ 0., 1., 2., 3., 4.]]) Alan Isaac ___ NumPy-Discussion mail

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Hi, On Wed, Apr 3, 2013 at 8:52 AM, Chris Barker - NOAA Federal wrote: > On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg > wrote: >>> the context where it gets applied. So giving the same strategy two >>> different names is silly; if anything it's the contexts that should >>> have different names

[Numpy-discussion] try to solve issue #2649 and revisit #473

Hello, all I try to solve issue 2649 which is related to 473 on multiplication of a matrix and an array. As 2649 shows import numpy as np x = np.arange(5) I = np.asmatrix(np.identity(5)) print np.dot(I, x).shape # -> (1, 5) First of all I assume we expect that I.dot(x) and I * x b

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Hi, On Wed, Apr 3, 2013 at 5:19 AM, wrote: > On Tue, Apr 2, 2013 at 9:09 PM, Matthew Brett wrote: >> Hi, >> >> On Tue, Apr 2, 2013 at 7:09 PM, wrote: >>> On Tue, Apr 2, 2013 at 5:52 PM, Nathaniel Smith wrote: On Tue, Apr 2, 2013 at 10:21 PM, Matthew Brett wrote: >> This is li

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Wed, 2013-04-03 at 08:52 -0700, Chris Barker - NOAA Federal wrote: > On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg > wrote: > >> the context where it gets applied. So giving the same strategy two > >> different names is silly; if anything it's the contexts that should > >> have different names

Re: [Numpy-discussion] timezones and datetime64

Mark Wiebe and I are both still tracking NumPy development and can provide context and even help when needed.Apologies if we've left a different impression. We have to be prudent about the time we spend as we have other projects we are pursuing as well, but we help clients with NumPy issues a

Re: [Numpy-discussion] timezones and datetime64

wrote: > I found no reasonable way around it other than bypassing the numpy > conversion entirely Exactly - we have come to the same conclusion. By the way, it's also consistent -- an ISO string without a TZ is interpreted as a to mean "use the locale", but a datetime object without a TZ is int

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg wrote: >> the context where it gets applied. So giving the same strategy two >> different names is silly; if anything it's the contexts that should >> have different names. >> > > Yup, thats how I think about it too... me too... > But I would really

Re: [Numpy-discussion] timezones and datetime64

Nathaniel Smith pobox.com> writes: > > On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld > gmail.com> wrote: > > > > This isn't acceptable for my use case (in a multinational company) and I found > > no reasonable way around it other than bypassing the numpy conversion entirely > > by setting t

Re: [Numpy-discussion] timezones and datetime64

On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld wrote: > Andreas Hilboll hilboll.de> writes: >> > I think your point about using current timezone in interpreting user >> > input being dangerous is probably correct --- perhaps UTC all the way >> > would be a safer (and simpler) choice? >> >> +1 >>

Re: [Numpy-discussion] timezones and datetime64

Andreas Hilboll hilboll.de> writes: > > > > > I think your point about using current timezone in interpreting user > > input being dangerous is probably correct --- perhaps UTC all the way > > would be a safer (and simpler) choice? > > +1 > +10 from me! I've recently come across a bug due t

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Tue, 2013-04-02 at 22:52 +0100, Nathaniel Smith wrote: > On Tue, Apr 2, 2013 at 10:21 PM, Matthew Brett > wrote: > >> This is like observing that if I say "go North" then it's ambiguous > >> about whether I want you to drive or walk, and concluding that we need > >> new words for the direction

Re: [Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

On Tue, Apr 2, 2013 at 9:09 PM, Matthew Brett wrote: > Hi, > > On Tue, Apr 2, 2013 at 7:09 PM, wrote: >> On Tue, Apr 2, 2013 at 5:52 PM, Nathaniel Smith wrote: >>> On Tue, Apr 2, 2013 at 10:21 PM, Matthew Brett >>> wrote: > This is like observing that if I say "go North" then it's ambiguo

Re: [Numpy-discussion] timezones and datetime64

Chris Barker - NOAA Federal noaa.gov> writes: [clip] > actually, I think datetime64 is naive -- the problem is entirely the I/O It's a counter from unix epoch, but as it's just an integer you can probably redefine the epoch and pretend your local time is UTC (as long as you don't care about DST e