Catching up with numpy 1.6
> 'No' means: I don't think it makes sense given the current behavior of numpy
> with respect to functions that are designed to return views
> (and copy memory only if there is no way to make a view)
>
> One objective of functions that create views is *not* to change th
On Thu, Apr 4, 2013 at 5:54 PM, Chris Barker - NOAA Federal
wrote:
> On Thu, Apr 4, 2013 at 11:26 AM, wrote:
>>> Before you answer that -- does anyone see a use case for the 'A' and
>>> 'K' flags that can't be reasonably easily accomplished with .view() or
>>> asarray() or ???
>>
>> What order d
On Thu, Apr 4, 2013 at 11:26 AM, wrote:
>> Before you answer that -- does anyone see a use case for the 'A' and
>> 'K' flags that can't be reasonably easily accomplished with .view() or
>> asarray() or ???
>
> What order does a[a>2] use to create the returned 1-D array?
...
> However, I never
Hi,
On Tue, Apr 2, 2013 at 4:32 AM, Nathaniel Smith wrote:
> Maybe we should go through and rename "order" to something more descriptive
> in each case, so we'd have
> a.reshape(..., index_order="C")
> a.copy(memory_order="F")
> etc.?
I'd like to propose this instead:
a.reshape(..., order=
Hi,
On Thu, Apr 4, 2013 at 1:53 PM, Sebastian Berg
wrote:
> On Thu, 2013-04-04 at 12:40 -0700, Matthew Brett wrote:
>> Hi,
>>
>
>>
>> So - to restate in other words - this :
>>
>> np.reshape(a, (3, 4), order='F')
>>
>> could reasonably mean one of two orthogonal things
>>
>> 1) Retrieve data fro
On Thu, 2013-04-04 at 12:40 -0700, Matthew Brett wrote:
> Hi,
>
>
> So - to restate in other words - this :
>
> np.reshape(a, (3, 4), order='F')
>
> could reasonably mean one of two orthogonal things
>
> 1) Retrieve data from the array using first-to-last indexing, return
> any memory layout
Hi,
On Thu, Apr 4, 2013 at 1:33 PM, wrote:
> On Thu, Apr 4, 2013 at 4:02 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Thu, Apr 4, 2013 at 12:54 PM, wrote:
>>> On Thu, Apr 4, 2013 at 3:40 PM, Matthew Brett
>>> wrote:
Hi,
On Thu, Apr 4, 2013 at 11:45 AM, Matthew Brett
wrote:
On Thu, Apr 4, 2013 at 4:02 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 4, 2013 at 12:54 PM, wrote:
>> On Thu, Apr 4, 2013 at 3:40 PM, Matthew Brett
>> wrote:
>>> Hi,
>>>
>>> On Thu, Apr 4, 2013 at 11:45 AM, Matthew Brett
>>> wrote:
Hi,
On Thu, Apr 4, 2013 at 9:21 AM, Chris
Hi,
On Thu, Apr 4, 2013 at 12:54 PM, wrote:
> On Thu, Apr 4, 2013 at 3:40 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Thu, Apr 4, 2013 at 11:45 AM, Matthew Brett
>> wrote:
>>> Hi,
>>>
>>> On Thu, Apr 4, 2013 at 9:21 AM, Chris Barker - NOAA Federal
>>> wrote:
On Wed, Apr 3, 2013 at 6:13 PM,
On Thu, Apr 4, 2013 at 3:40 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 4, 2013 at 11:45 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> On Thu, Apr 4, 2013 at 9:21 AM, Chris Barker - NOAA Federal
>> wrote:
>>> On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett
>>> wrote:
> We all agree that 'order
Hi,
On Thu, Apr 4, 2013 at 11:45 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 4, 2013 at 9:21 AM, Chris Barker - NOAA Federal
> wrote:
>> On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett
>> wrote:
We all agree that 'order' is used with two different and orthogonal
meanings in numpy.
>
On 4/4/13 8:56 PM, Chris Barker - NOAA Federal wrote:
> On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted wrote:
>
>> That makes a difference. This can be specially important for creating
>> user-defined time origins:
>>
>> In []: np.array(int(1.5e9), dtype='datetime64[s]') + np.array(1,
>> dtype='
On 03/04/2013 7: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
On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted wrote:
> That makes a difference. This can be specially important for creating
> user-defined time origins:
>
> In []: np.array(int(1.5e9), dtype='datetime64[s]') + np.array(1,
> dtype='timedelta64[ns]')
> Out[]: numpy.datetime64('2017-07-14T04:40:
Hi,
On Thu, Apr 4, 2013 at 9:21 AM, Chris Barker - NOAA Federal
wrote:
> On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett wrote:
>>> We all agree that 'order' is used with two different and orthogonal
>>> meanings in numpy.
>
> well, not entirely orthogonal -- they are the some concept, used in
> d
Hi,
On Thu, Apr 4, 2013 at 9:21 AM, Chris Barker - NOAA Federal
wrote:
> On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett wrote:
>>> We all agree that 'order' is used with two different and orthogonal
>>> meanings in numpy.
Brief thank you for your helpful and thoughtful discussion.
> well, not e
On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted wrote:
> On 4/4/13 7:01 PM, Chris Barker - NOAA Federal wrote:
>> I thought about that -- but if you have timedelta without datetime,
>> you really just have an integer -- we haven't bought anything.
>
> Well, it is not just an integer. It is an in
On Thu, Apr 4, 2013 at 12:21 PM, Chris Barker - NOAA Federal
wrote:
> On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett wrote:
>>> We all agree that 'order' is used with two different and orthogonal
>>> meanings in numpy.
>
> well, not entirely orthogonal -- they are the some concept, used in
> diffe
On 04/04/2013 05:03 AM, Daniele Nicolodi wrote:
> I'm not aware of any library that handles the conversion from UTC to
> TAI. I would like to know if there is one. Furthermore, UTC cannot be
> computed unambiguously for times in the future because the leap second
> insertion is not scheduled regula
On 4/4/13 7:01 PM, Chris Barker - NOAA Federal wrote:
> Francesc Alted wrote:
>> When Ivan and me were discussing that, I remember us deciding that such
>> a small units would be useful mainly for the timedelta datatype, which
>> is a relative, not absolute time. We did not want to make short for
On Thu, Apr 4, 2013 at 6:06 PM, Charles R Harris
wrote:
>
>
> On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
> wrote:
>>
>> On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
>> > One problem with trying to give technically correct answers for the
>> > UTC/Posix format is that it ca
On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
> > On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
>
> >> Probably also TAI and UTC/Posix.
> >>
> >> Converting from one format to the other is
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
> On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
>> Probably also TAI and UTC/Posix.
>>
>> Converting from one format to the other is problematic since
>> all of them (except TAI afaik) require looking things up in
>> regularly updated dat
On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett wrote:
>> We all agree that 'order' is used with two different and orthogonal
>> meanings in numpy.
well, not entirely orthogonal -- they are the some concept, used in
different contexts, so there is some benefit to their having
similarity. So I"d adv
On Thu, Apr 4, 2013 at 6:01 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
[...]
> Which is why I advocate interspersed posting.
>
> It comes down to: please take some thought to compose your post in a
> way that is suited to the thread and what you are writing, rather than
> simp
On Wed, Apr 3, 2013 at 11:53 PM, Dag Sverre Seljebotn
wrote:
> With top-posting I'm forced to write "With respect to what you write
> about the GIL issues, ...". Bleh. In fact, in deep technical threads
> it's very difficult for me to write top-posting at all, which is why I
> get so irritated whe
On 4/4/13 1:54 PM, Nathaniel Smith wrote:
> On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
> wrote:
>> 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 datetime6
On 4/4/13 1:52 AM, Chris Barker - NOAA Federal wrote:
> 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 di
I don't quite understand how einsum handles broadcasting. I get the
following error, but I don't understand why:
In [8]: import numpy as np
In [9]: A = np.arange(12).reshape((4,3))
In [10]: B = np.arange(6).reshape((3,2))
In [11]: np.einsum('ik,k...->i...', A, B)
--
On 04/04/2013 03:03 AM, Daniele Nicolodi wrote:
> I'm not aware of any library that handles the conversion from UTC to
> TAI. I would like to know if there is one.
The CDF library does, although that's rather a sledgehammer to drive a
thumbtack.
> I think that generally the issue is not relevant
On Thu, Apr 4, 2013 at 3:49 AM, Dave Hirschfeld
wrote:
> Charles R Harris gmail.com> writes:
>
>>
>> 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 curr
On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
wrote:
> 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 attosec
On 4 April 2013 11:03, Daniele Nicolodi wrote:
> I think that generally the issue is not relevant for any practical use
> of a timebase: there are not many applications requiring sub-second
> accuracy over many years periods.
I agree. I think the basic datetime object should ignore this issue
(
On 04/04/2013 03:02, Mark Wiebe wrote:
> I think it's most straightforward to leave it wrong for Posix-format
> datetimes, but add a TAI timezone where it will produce correct results.
Strictly speaking, TAI is not a timezone but a different time base.
Cheers,
Daniele
___
On 04/04/2013 01:27, Pauli Virtanen wrote:
>
> Probably also TAI and UTC/Posix.
>
> Converting from one format to the other is problematic since
> all of them (except TAI afaik) require looking things up in
> regularly updated databases. Not only restricted to conversions,
> but also arithmetic, `
Charles R Harris gmail.com> writes:
>
> 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
36 matches
Mail list logo
