On Thu, Jun 11, 2009 at 15:33, Pierre GM wrote:
>
> On Jun 11, 2009, at 3:47 PM, Robert Kern wrote:
>
>> On Thu, Jun 11, 2009 at 14:37, Pierre GM wrote:
>>> Oh, just another question: why trying to put datetime and timedelta
>>> in
>>> the type ordering ? My understanding is that underneath, they'
On Jun 11, 2009, at 3:47 PM, Robert Kern wrote:
> On Thu, Jun 11, 2009 at 14:37, Pierre GM wrote:
>>
>> On Jun 11, 2009, at 3:07 PM, Travis Oliphant wrote:
>>
BTW, what is the metadata that is going to be added to the types?
What purpose does it serve?
>>>
>>> In the date-time case, it
On Thu, Jun 11, 2009 at 14:37, Pierre GM wrote:
>
> On Jun 11, 2009, at 3:07 PM, Travis Oliphant wrote:
>
>>> BTW, what is the metadata that is going to be added to the types?
>>> What purpose does it serve?
>>
>> In the date-time case, it holds what frequency the integer in the
>> data-
>> type re
On Jun 11, 2009, at 3:07 PM, Travis Oliphant wrote:
>> BTW, what is the metadata that is going to be added to the types?
>> What purpose does it serve?
>
> In the date-time case, it holds what frequency the integer in the
> data-
> type represents.There will only be 2 new static data-types.
On Thu, Jun 11, 2009 at 1:07 PM, Travis Oliphant wrote:
>
> In the date-time case, it holds what frequency the integer in the data-
> type represents.There will only be 2 new static data-types.
> "Datetime" and "Timedelta" that use 8 bytes each.
>
> What those 8 bytes represent will be dete
On Jun 11, 2009, at 1:18 PM, Robert Kern wrote:
> This line from generate_umath.py?
>
> all = '?bBhHiIlLqQtTfdgFDGO'
Oh, I don't think it's a good idea to use "T" and "t" for date-time.
In the struct module this mean "struct" and "bit" respectively.
I propose "M" and "m"
-Travis
On Thu, Jun 11, 2009 at 1:07 PM, Travis Oliphant wrote:
>
> On Jun 11, 2009, at 1:44 PM, Charles R Harris wrote:
>
> >
> > The implementation of PyArray_CanCastSafely illustrates two other
> > points that bother me.
> >
> > 1) The rules are encoded in the program logic. This makes them
> > diffic
On Jun 11, 2009, at 1:44 PM, Charles R Harris wrote:
>
> The implementation of PyArray_CanCastSafely illustrates two other
> points that bother me.
>
> 1) The rules are encoded in the program logic. This makes them
> difficult to find or to see what they are and requires editing the
> code
On Thu, Jun 11, 2009 at 13:44, Charles R
Harris wrote:
>
>
> On Thu, Jun 11, 2009 at 12:18 PM, Robert Kern wrote:
>>
>> On Thu, Jun 11, 2009 at 13:06, Charles R
>> Harris wrote:
>> >
>> >
>> > On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern
>> > wrote:
>> >>
>> >> On Thu, Jun 11, 2009 at 12:39, Cha
On Thu, Jun 11, 2009 at 12:18 PM, Robert Kern wrote:
> On Thu, Jun 11, 2009 at 13:06, Charles R
> Harris wrote:
> >
> >
> > On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern
> wrote:
> >>
> >> On Thu, Jun 11, 2009 at 12:39, Charles R
> >> Harris wrote:
> >> >
> >> >
> >> > On Thu, Jun 11, 2009 at 11
On Thu, Jun 11, 2009 at 13:06, Charles R
Harris wrote:
>
>
> On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern wrote:
>>
>> On Thu, Jun 11, 2009 at 12:39, Charles R
>> Harris wrote:
>> >
>> >
>> > On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern
>> > wrote:
>> >>
>> >> On Thu, Jun 11, 2009 at 12:29, Cha
On Thu, Jun 11, 2009 at 11:47 AM, Robert Kern wrote:
> On Thu, Jun 11, 2009 at 12:39, Charles R
> Harris wrote:
> >
> >
> > On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern
> wrote:
> >>
> >> On Thu, Jun 11, 2009 at 12:29, Charles R
> >> Harris wrote:
> >> > Oh, and slipping the new types in betwee
On Thu, Jun 11, 2009 at 12:39, Charles R
Harris wrote:
>
>
> On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern wrote:
>>
>> On Thu, Jun 11, 2009 at 12:29, Charles R
>> Harris wrote:
>> > Oh, and slipping the new types in between 64 bit integers and floats is
>> > a
>> > bit iffy.
>>
>> Where, specific
On Thu, Jun 11, 2009 at 11:34 AM, Robert Kern wrote:
> On Thu, Jun 11, 2009 at 12:29, Charles R
> Harris wrote:
> > Oh, and slipping the new types in between 64 bit integers and floats is a
> > bit iffy.
>
> Where, specifically? There are several linear orders of types in
> numpy. I tried to be c
On Thu, Jun 11, 2009 at 12:29, Charles R
Harris wrote:
> Oh, and slipping the new types in between 64 bit integers and floats is a
> bit iffy.
Where, specifically? There are several linear orders of types in
numpy. I tried to be careful to do the right thing in each. The enum
numbers are after NPY
On Thu, Jun 11, 2009 at 10:29 AM, Travis Oliphant wrote:
>
> On Jun 10, 2009, at 11:18 PM, Charles R Harris wrote:
>
> Hi Travis,
>
> I looked through the recent commits to the datetime branch and, as I'm
> working on cleaning up arraytypes I would appreciate it if you can merge up
> your changes
On Thu, Jun 11, 2009 at 10:29 AM, Travis Oliphant wrote:
>
> On Jun 10, 2009, at 11:18 PM, Charles R Harris wrote:
>
> Hi Travis,
>
> I looked through the recent commits to the datetime branch and, as I'm
> working on cleaning up arraytypes I would appreciate it if you can merge up
> your changes
On Jun 10, 2009, at 11:18 PM, Charles R Harris wrote:
Hi Travis,
I looked through the recent commits to the datetime branch and, as
I'm working on cleaning up arraytypes I would appreciate it if you
can merge up your changes there as soon as possible to minimize
conflicts. Also, this cha
On Wed, Jun 10, 2009 at 23:18, Charles R
Harris wrote:
> Hi Travis,
>
> I looked through the recent commits to the datetime branch and, as I'm
> working on cleaning up arraytypes I would appreciate it if you can merge up
> your changes there as soon as possible to minimize conflicts. Also, this
> c
Hi Travis,
I looked through the recent commits to the datetime branch and, as I'm
working on cleaning up arraytypes I would appreciate it if you can merge up
your changes there as soon as possible to minimize conflicts. Also, this
change looks like a reversion of current trunk to something older:
20 matches
Mail list logo
