h, and
> probably won't be for a while, if at all. As it turns out, I have a
> hard time concentrating on the intricacies of apis. >_<
>
> --Josh (jesusabdullah :E )
>
>
> On Fri, Oct 1, 2010 at 11:10 AM, Fernando Perez wrote:
>> On Thu, Sep 30, 2010 at 9:41 AM, R
x27;s not straightforward enough for a simple pull
request.
-- Rob
On Thu, Sep 30, 2010 at 12:22 PM, Lluís wrote:
> Rob Speer writes:
>
>> However, I notice that all the new development on datarray is
>> happening on Fernando Perez's branch, which mine diverged from long
There's some DataArray code that I've had for a while, but I just
finished it up and tested it today. Most notably, it includes a new
__str__ for DataArrays that does some nice layout and includes ticks:
In [9]: print d_arr
country year
- -
To explain:
A has shape (2,1), meaning it's a 2-D array with 2 rows and 1 column.
The transpose of A has shape (1,2): it's a 2-D array with 1 row and 2
columns. That's not the same as what you want, which is an array with
shape (2,): a 1-D array with 2 entries.
When you take A[:,0], you're pullin
I agree with the idea that axis labels must be strings.
Yes, this is the opposite of my position on tick labels ("names"), but
there's a reason: ticks are often defined by whatever data you happen
to be working with, but axis labels will in the vast majority of
situations be defined by the program
> Not really. 1-D structured arrays can and do work well for the very
> common case where one has unlabeled rows and labeled columns. They are
> also a little bit more flexible in that the columns can be
> heterogeneous in dtype, as columns are wont to do.
>
> May I politely suggest that, just as s
t there is
really not much point in comparing them any further.
-- Rob
On Mon, Jul 12, 2010 at 6:01 PM, Neil Crighton wrote:
> Rob Speer MIT.EDU> writes:
>
>> It's not just about the rows: a 2-D datarray can also index by
>> columns, an operation that has no equivalent in
d on the
Divisi one. I have to make it support datatypes besides floats,
however.)
-- Rob
On Sun, Jul 11, 2010 at 2:09 PM, Neil Crighton wrote:
> Robert Kern gmail.com> writes:
>
>>
>> On Sun, Jul 11, 2010 at 11:36, Rob Speer mit.edu> wrote:
>> >> But the utilit
> But the utility of named indices is not so clear
> to me. As I understand it, these new arrays will still only be
> able to have a single type of data (one of float, str, int and so
> on). This seems to be pretty limiting.
This just shows that people use NumPy for lots of different things. I
mys
Keith Goodman wrote:
> I ran into a few more questions while playing with datarrays, so I started a
> list:
> http://github.com/kwgoodman/datarrayQ
I have quick answers to some of the questions.
> Can I have ticks without labels?
Ideally, yes, but good catch: the current code disallows that for
# the default
option -- works in any case
arr[ arr.aix.country.named['Netherlands'].year[-1] ] # the "stuple" option
arr.country.named['Netherlands'].year[-1] # the
"magical" option
arr.country_named['Netherlands'].year_index[-1]# the &qu
http://github.com/rspeer/datarray represents my best guess at the
SciPy BOF consensus. I recently switched the method of accessing named
ticks from .named() to .named[] based on further discussion here.
My implementation is still missing the case with named ticks but
positional axes, however. That
> I think we have to start from the nD case, even if I (and I think most
> users) will tend to think in 2D. The rest is just going to have to be
> up to developers how they want users to interact with what we, the
> developers, see as axes. No end-user wants to think about the 6th
> axis of the d
> 3. That the best solution to allow integer ticks while retaining
> 'normal' indexing semantics for integers would be to have
>
> arr[int] -> normal indexing
> arr.somethin[int] -> tick-based indexing, where an int can mean anything.
All right, it's clear lots of people like it better this way,
>> Still, I have a question. Did you also agree that this should forcibly index
>> through ticks?
>>
>> arr.something[int] -> tick-based indexing
>>
>
> Yes.
I feel like people are talking about different things because it's
unclear what the .something is.
If the .something is an axis name,
> No. I'd rather go for eliminating the 'arr.year.named', and providing only:
> * arr.__getitem__
> * arr.named.__getitem__
> * arr..__getitem__
>
> The first being just the current ndarray.__getitem__, and the two last methods
> would accept both strings and integers, assuming that names/ticks
On Thu, Jul 8, 2010 at 2:27 PM, Skipper Seabold wrote:
> On Thu, Jul 8, 2010 at 1:35 PM, Rob Speer wrote:
>> Your labels are unique if you look at them the right way. Here's how I
>> would represent that in a datarray:
>> * axis0 = 'city', ['Au
>> But I don't understand your second example:
>>> arr.country['Spain'].year[1994:2010]
>
>> That seems to run straight into the index/name ambiguity. Shouldn't
>> that take the 1994th through 2010th indices along the "year" axis? Not
>> every axis will have names, so you can't make *all* the ind
> Forgive me if this is has already been addressed, but my question is
> what happens when we have more than one "label" (not as in a labeled
> axis but an observation label -- but not a tick because they're not
> unique!) per say row axis and heterogenous dtypes. This is really the
> problem that
> While I haven't had a chance to really look in-depth at the changes
> myself (I'm a busy man! So many mailing lists!), I so far like the
> look and sound of them. That's just my opinion, though.
If people are okay with the attribute magic, I have a proposal for more of it.
In my own project whe
On Thu, Jul 8, 2010 at 7:13 AM, Lluís wrote:
> Thus, we can use something in the middle:
>
> arr[0,1]
> arr.names['Netherlands',2010] # I'd rather go for 'names' instead of 'ticks'
Ah ha. So this is the case with positional axes but named ticks, which
we haven't really brought up yet. I'm def
Glad I finally found this discussion.
I implemented some of the ideas from the SciPy BOAF discussion, and
Joshua has already merged them into his datarray on GitHub (thanks,
Joshua, for being so fast on the merge button).
To introduce these changes, here's a couple of examples of how you
could in
22 matches
Mail list logo
