Sup y'all,
I just installed numpy from github, but when I tried to import it I
got some odd errors! What's going on, and how can it be fixed?
josh@pidgey:~$ python -c 'import numpy; numpy.test()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.6/dist-pack
Maybe I'm missing something, but why not just implement sum() using
dot() and ones() ?
--Josh
On Thu, Feb 10, 2011 at 11:49 AM, Pauli Virtanen wrote:
> On Thu, 10 Feb 2011 22:38:52 +0200, eat wrote:
> [clip]
>> I hope so. Please suggest if there's anything that I can do to further
>> advance thi
>>
>> The only disadvantage I see, is that choosing the axes to operate on
>> in a program or function requires string manipulation.
>
>
> One possibility would be for the Python exposure to accept lists or tuples
> of integers. The subscript 'ii' could be [(0,0)], and 'ij,jk->ik' could be
> [(0,1
> Ah, sorry for misunderstanding. That would actually be very difficult,
> as the iterator required a fair bit of fixes and adjustments to the core.
> The new_iterator branch should be 1.5 ABI compatible, if that helps.
I see. Perhaps the fixes and adjustments can/should be included with
numpy st
>
> It think his real question is whether einsum() and the iterator stuff
> can live in a separate module that *uses* a released version of numpy
> rather than a development branch.
>
> --
> Robert Kern
>
Indeed, I would like to be able to install and use einsum() without
having to install another
On Wed, Jan 26, 2011 at 12:48 PM, Mark Wiebe wrote:
> On Wed, Jan 26, 2011 at 1:36 PM, Joshua Holbrook
> wrote:
>>
>> On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe wrote:
>> > I wrote a new function, einsum, which implements Einstein summation
>> > notation,
On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe wrote:
> I wrote a new function, einsum, which implements Einstein summation
> notation, and I'd like comments/thoughts from people who might be interested
> in this kind of thing.
This sounds really cool! I've definitely considered doing something
lik
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris
wrote:
> Here. This looks harmless but it makes the history really ugly. We need to
> get the word out *not* to do things this way.
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@sc
On Mon, Oct 11, 2010 at 9:52 PM, Matthew Brett wrote:
> Sorry - just re-reading that - it's a bit cryptic. I mean, yes, I
> agree wholeheartedly that it's a shame to stick to svn workflows when
> using git. I'm just some guy as well of course. I suppose we
> just-some-guys should start an just
In projects I've worked on, most people have worked on their own
repos, continually merging in changes from other repos to keep
themselves current. I think this is generally a good approach for
development, if a bit disorganized. In addition, obviously a group of
people pushing to numpy/numpy is ne
On Fri, Oct 8, 2010 at 9:05 PM, Fernando Perez wrote:
> Hi,
>
> On Fri, Oct 8, 2010 at 8:20 PM, Joshua Holbrook
> wrote:
>>
>> What mechanism are you using for gh-pages, if I may ask? I would be
>> interested in this for future projects.
>
> the default githu
On Fri, Oct 8, 2010 at 6:21 PM, Fernando Perez wrote:
> Hi Rob, Josh and Lluis,
>
> On Thu, Sep 30, 2010 at 9:41 AM, Rob Speer wrote:
>> The fact that I wasn't around for the sprint probably has a lot to do
>> with how much the code had diverged. But it's not too bad -- I merged
>> Fernando's bra
One thing I'd like to throw out there is that I haven't really done
anything with my branch past maybe adding a gh-pages branch, 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
Seeing this made me think it might be of interest to some of us who
want to work with tabular data:
http://thechangelog.com/post/1112527716/tablib-pythonic-tabular-data-library
It's definitely working in 2 dimensions instead of datarray's n
dimensions, but it looks nice! Plus, import/export.
On Mon, Sep 13, 2010 at 7:33 PM, wrote:
> On Mon, Sep 13, 2010 at 11:18 PM, Joshua Holbrook
> wrote:
>> you have my sympathy, but no hints. :( The only thing I can think of
>> is something like a preprocessor.
>>
>> --Josh
>>
>> On Mon, Sep 13, 2010
you have my sympathy, but no hints. :( The only thing I can think of
is something like a preprocessor.
--Josh
On Mon, Sep 13, 2010 at 7:13 PM, Robert Kern wrote:
> On Mon, Sep 13, 2010 at 21:24, David Goldsmith
> wrote:
>> (Sorry for the OT post; I thought I'd get a more sympathetic response
>
On Sun, Aug 15, 2010 at 5:53 PM, wrote:
> On Sun, Aug 15, 2010 at 4:27 PM, Sturla Molden wrote:
>>
>>> Matlab also takes a copy if we create an array slice. It means for example
>>> that a wavelet transform written in Python will be O(n) with respect to
>>> memory, whereas it will be O(n log n)
On Fri, Aug 13, 2010 at 3:48 PM, wrote:
> On Fri, Aug 13, 2010 at 5:11 PM, Joshua Holbrook
> wrote:
>>> Cause honestly, If I could dump everything in one file and be able to
>>> use it everywhere.
>>
>> ...I could.
>>
>> Sorry.
>
>
> Cause honestly, If I could dump everything in one file and be able to
> use it everywhere.
...I could.
Sorry.
--Josh
On Fri, Aug 13, 2010 at 1:09 PM, Joshua Holbrook
wrote:
> Yeah, I don't really like it either. Is there a good way to put
> multiple global functions in a fi
Yeah, I don't really like it either. Is there a good way to put
multiple global functions in a file without matlab getting upset?
Cause honestly, If I could dump everything in one file and be able to
use it everywhere.
--Josh
On Fri, Aug 13, 2010 at 12:59 PM, John Hunter wrote:
> On Fri, Aug 13,
Ugh! I miss all that stuff anytime I have to use matlab. Working with
strings sucks especially hard.
In fact, I've tried reimplementing half of the tools I wish I had. If
anyone cares:
http://github.com/jesusabdullah/methlabs
I'd love feedback. Perhaps ironically, I haven't used it much, due
On Tue, Aug 3, 2010 at 10:44 AM, Alan G Isaac wrote:
> On 8/3/2010 1:29 PM, Joshua Holbrook wrote:
>> What's the
>> advantage of the matrix datatype?
>
>
> As it turns out, that's a controversial question. ;-)
>
> One answer: pedagogy (for those
I don't think I've ever actually seen someone use the matrix datatype
instead of the array datatype.
Hopefully nobody minds me asking the noob question: What's the
advantage of the matrix datatype?
--Josh
On Tue, Aug 3, 2010 at 8:59 AM, Wayne Watson
wrote:
> Thank you. That's almost amusing. T
On Mon, Jul 26, 2010 at 4:51 PM, Alan G Isaac wrote:
> On 7/26/2010 8:22 PM, Joshua Holbrook wrote:
>> imo, the determinant of a scalar should be defined as itself, based on
>> the definition of the determinant.
>
> What definition do you have in
On Mon, Jul 26, 2010 at 4:18 PM, Skipper Seabold wrote:
> On Mon, Jul 26, 2010 at 7:38 PM, Charles R Harris
> wrote:
>>
>>
>> On Mon, Jul 26, 2010 at 5:05 PM, Skipper Seabold
>> wrote:
>>>
>>> On Mon, Jul 26, 2010 at 5:48 PM, Alan G Isaac wrote:
>>> > On 7/26/2010 12:45 PM, Skipper Seabold wrot
Make that +2.
--Josh
On Wed, Jul 21, 2010 at 1:38 PM, Skipper Seabold wrote:
> On Wed, Jul 21, 2010 at 5:32 PM, Rob Speer wrote:
>> 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
On Mon, Jul 19, 2010 at 5:50 PM, Charles R Harris
wrote:
> Hi All,
>
> I'm thinking about adding some functionality to lstsq because I find myself
> doing the same fixes over and over. List follows.
>
> Add weights so data points can be weighted.
> Use column scaling so condition numbers make more
This is awesome! I love github. I really wanted to champion for its
use at the BoF but unfortunately missed it.
--Josh
On Tue, Jul 13, 2010 at 6:20 PM, Jarrod Millman wrote:
> Hello all,
>
> On May 26th, I sent an email titled "curious about how people would
> feel about moving to github." Whil
On Tue, Jul 13, 2010 at 4:31 AM, Wes McKinney wrote:
> On Tue, Jul 13, 2010 at 8:26 AM, Sebastian Haase wrote:
>> On Tue, Jul 13, 2010 at 2:20 PM, William Johnston
>> wrote:
>>> Hello,
>>>
>>> I simply installed numpy in my Python26 installation, and then copied the
>>> numpy directory to my si
On Fri, Jul 9, 2010 at 5:26 PM, Keith Goodman wrote:
> On Fri, Jul 9, 2010 at 6:11 PM, Joshua Holbrook
> wrote:
>
>> I think I like being able to group ticks with their axis, so I know
>> which ticks belong to which axis without having to scan back-and-forth
>> betwee
On Fri, Jul 9, 2010 at 4:56 PM, Keith Goodman wrote:
> On Fri, Jul 9, 2010 at 5:52 PM, Joshua Holbrook
> wrote:
>> On Fri, Jul 9, 2010 at 4:22 PM, Keith Goodman wrote:
>>> On Fri, Jul 9, 2010 at 5:00 PM, Christopher Barker
>>> wrote:
>>>> Keith Goodma
On Fri, Jul 9, 2010 at 4:22 PM, Keith Goodman wrote:
> On Fri, Jul 9, 2010 at 5:00 PM, Christopher Barker
> wrote:
>> Keith Goodman wrote:
>>> On Fri, Jul 9, 2010 at 4:05 PM, Christopher Barker
>>> wrote:
>>>
So what would you get if you wanted:
MyDataArray['jones':'wilson']
>> I was going to reply to it after I considered its contents but kinda
>> forgot until now.
>>
>> Anyways: while I like the idea of having ticks that correspond to
>> their axis being next to each other as the current behavior goes, I
>> find this alternative syntax easier to read, probably due to
On Fri, Jul 9, 2010 at 11:42 AM, Rob Speer wrote:
> Now, the one part I've implemented that I just made up instead of
> looking to the SciPy consensus (because there was no SciPy consensus)
> was how to refer to multiple labeled axes without repeating ".axis"
> all over the place. My choice, which
> Then how is this not different than a record array?
How is this the *same* as a record array?
--Josh
On Thu, Jul 8, 2010 at 2:03 PM, Rob Speer wrote:
>> 3. That the best solution to allow integer ticks while retaining
>> 'normal' indexing semantics for integers would be to have
>>
>> arr[int
On Thu, Jul 8, 2010 at 1:39 PM, Rob Speer wrote:
>>> 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
> uncle
On Thu, Jul 8, 2010 at 1:30 PM, Lluís wrote:
> Joshua Holbrook writes:
>>> arr[not int] -> tick-based indexing
>
>> At the BoF, we chose to drop this because we wanted to allow integer ticks
>> (or
>> implicit type conversion, either way) without the ambig
On Thu, Jul 8, 2010 at 12:55 PM, Lluís wrote:
> Fernando Perez writes:
>> The consensus at the BoF (not that it means it's set in stone, simply
>> that there was good chance for back-and-forth on the topic with many
>> voices) was that:
>
>> 1. There are valid use cases for 'integer ticks', i.e
On Thu, Jul 8, 2010 at 12:20 PM, Fernando Perez wrote:
> On Thu, Jul 8, 2010 at 1:15 PM, Lluís wrote:
>>
>>
>>> My impression from SciPy was that people would prefer separate
>>> accessors for names and indices, especially because integers (a really
>>> common data type, after all) shouldn't be f
On Thu, Jul 8, 2010 at 3:13 AM, Lluís wrote:
> Rob Speer writes:
>
> arr.country.named('Netherlands').year.named(2010)
> arr.country.named('Spain').year.named(slice(1994, 2010))
> arr.year.named(2006).country[0:2]
>
> This looks too verbose to me.
>
> As axis always have a total order,
On Wed, Jul 7, 2010 at 10:25 PM, Rob Speer wrote:
> 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
On Wed, Jul 7, 2010 at 5:52 AM, Bruce Southey wrote:
> On 07/06/2010 01:09 PM, Gael Varoquaux wrote:
>> Just to give a data point, my research group and I would be very excited
>> at the idea of having Fernando's data arrays in Numpy. We can't offer to
>> maintain it, because we are already fairly
On Tue, Jul 6, 2010 at 2:23 PM, Alan G Isaac wrote:
> On 7/6/2010 3:37 PM, Joshua Holbrook wrote:
>> In [10]: np.array(list(reversed(np.arange(10).cumsum(
>> Out[10]: array([45, 36, 28, 21, 15, 10, 6, 3, 1, 0])
>>
>
>
> That might appear to match the subject
On Tue, Jul 6, 2010 at 11:25 AM, Jonathan Stickel wrote:
> On 7/6/10 10:42 , numpy-discussion-requ...@scipy.org wrote:
>> Date: Tue, 06 Jul 2010 10:02:57 -0400
>> From: Alan G Isaac
>> Subject: Re: [Numpy-discussion] reverse cumsum?
>> To: Discussion of Numerical Python
>> Message-ID:<4c333791.501
On Tue, Jul 6, 2010 at 8:42 AM, Skipper Seabold wrote:
> On Tue, Jul 6, 2010 at 12:36 PM, Joshua Holbrook
> wrote:
>> I'm kinda-sorta still getting around to building/reading the sphinx
>> docs for datarray. <_< Like, I've gone through them before, but it
llowing
integer-datatyped labels.
Thoughts?
--Josh
On Tue, Jul 6, 2010 at 8:23 AM, Keith Goodman wrote:
> On Tue, Jul 6, 2010 at 9:13 AM, Skipper Seabold wrote:
>> On Tue, Jul 6, 2010 at 11:55 AM, Keith Goodman wrote:
>>> On Tue, Jul 6, 2010 at 7:47 AM, Joshua Holbrook
I really really really want to work on this. I already forked datarray
on github and did some research on What Other People Have Done (
http://jesusabdullah.github.com/2010/07/02/datarray.html ). With any
luck I'll contribute something actually useful. :)
Anyways!
--Josh
On Mon, Jul 5, 2010 at 8
47 matches
Mail list logo
