Re: [Numpy-discussion] svd error checking vs. speed

On 2/15/14 3:37 PM, alex wrote: > The proposal would be to make np.linalg.svd more like scipy.linalg.svd > with respect to input checking. The argument against the change is > raw speed; if you know that you will never feed non-finite input to > svd, then np.linalg.svd is a bit faster than scipy.l

Re: [Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

On 10/24/13 1:42 PM, Peter Wang wrote: > On Thu, Oct 24, 2013 at 10:11 AM, Jason Grout > mailto:jason-s...@creativetrax.com>> wrote: > > It would be really cool if you could hook into the new IPython comm > infrastructure to push events back to the server in

Re: [Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

On 10/24/13 9:47 AM, Peter Wang wrote: > You will still have interactivity *within* plots inside a single > Notebook, but they will not drive events back to the server side. Also, > if your data is large, then the notebook will also get pretty big. (We > will be working on more efficient encoding

Re: [Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

in github or somewhere to see how you made these plots. Since Bokeh is (at least partly) about making beautiful plots easy, showing off the source code is half of the story. Thanks, Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-D

Re: [Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

On 10/24/13 6:35 AM, Jason Grout wrote: > This looks really cool. I was checking out how easy it would be to > embed in the Sage Cell Server [1]. I briefly looked at the code, and it > appears that the IPython notebook mode does not use nodejs, redis, > gevent, etc.? Is that righ

Re: [Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

On 10/23/13 6:00 PM, Peter Wang wrote: > Hi everyone, > > I'm excited to announce the v0.2 release of Bokeh, an interactive web > plotting library for Python. The long-term vision for Bokeh is to > provide rich interactivity, using the full power of Javascript and > Canvas, to Python users who don

Re: [Numpy-discussion] Proposal of new function: iteraxis()

On 4/26/13 6:33 AM, Robert Kern wrote: > In any case, whether you put the documentation in the rollaxis() > docstring or in one of the indexing/iteration sections, or > (preferably) both, I strongly encourage you to do that first and see > how it goes before adding a new alias. +1 (for what it's w

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

On 2/6/13 12:46 AM, Charles R Harris wrote: > if we decide to do so I should mention that we don't really depend on either behavior (we probably should have a better doctest testing for an array of None values anyway), but we noticed the oddity and thought we ought to mention it. So it doesn't

Re: [Numpy-discussion] Issues to fix for 1.7.0rc2.

On 2/4/13 12:04 AM, Ondřej Čertík wrote: > Hi, > > Here are the last open issues for 1.7, there are 9 of them: > > https://github.com/numpy/numpy/issues?milestone=3&sort=updated&state=open > Here's something we noticed while working on getting 1.7rc1 into Sage with one of our doctests. With nump

Re: [Numpy-discussion] DARPA funding for Blaze and passing the NumPy torch

On 12/16/12 11:07 PM, Travis Oliphant wrote: > Hello all, > > There is a lot happening in my life right now and I am spread quite > thin among the various projects that I take an interest in. In > particular, I am thrilled to publicly announce on this list that > Continuum Analytics has receive

[Numpy-discussion] IPython receives $1.15 million from Alfred P. Sloan Foundation

It's great to see a significant open-source python project that many of us use on a day-to-day basis get such great funding! Thanks, Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/ma

Re: [Numpy-discussion] [matplotlib-devel] GitHub attachments

On 12/7/12 3:21 PM, Nathaniel Smith wrote: > Oh, never mind, I guess they *only* allow image files. So, uh, no test > data files, but if we have any lolcats in the trac attachments, we can > migrate those. > It looks like what they do is just automatically upload it to their own cloud, and then

Re: [Numpy-discussion] matrix norm

On 10/22/12 3:08 PM, Robert Kern wrote: > > http://mail.scipy.org/pipermail/numpy-discussion/2006-March/019194.html > Ah, so it was basically speed that was the issue. I won't push this further. I'll just note that I was confused for a bit, and I probably won't be the last person confused about

Re: [Numpy-discussion] matrix norm

On 10/22/12 3:03 PM, Pauli Virtanen wrote: > Jason Grout creativetrax.com> writes: > [clip] >> I think we've established that the other software mentioned does indeed >> use the spectral norm by default. I'm still curious: what was the >> reason for breaking

Re: [Numpy-discussion] matrix norm

On 10/22/12 10:44 AM, Jason Grout wrote: > I'm curious why scipy/numpy defaults to calculating the Frobenius norm > for matrices [1], when Matlab, Octave, and Mathematica all default to > calculating the induced 2-norm [2]. Is it solely because the Frobenius > norm is easier to

Re: [Numpy-discussion] matrix norm

On 10/22/12 11:08 AM, Charles R Harris wrote: > > The 2-norm and the Frobenius norm are the same thing. For vectors, but I was talking about matrices and induced p-norms (sorry for not being clear). Warren pointed out that the spectral norm (the induced 2-norm) is used in Octave as the default

Re: [Numpy-discussion] matrix norm

On 10/22/12 10:56 AM, Charles R Harris wrote: > > > On Mon, Oct 22, 2012 at 9:44 AM, Jason Grout > mailto:jason-s...@creativetrax.com>> wrote: > > I'm curious why scipy/numpy defaults to calculating the Frobenius norm > for matrices [1], when Matlab, Octave

[Numpy-discussion] matrix norm

I'm curious why scipy/numpy defaults to calculating the Frobenius norm for matrices [1], when Matlab, Octave, and Mathematica all default to calculating the induced 2-norm [2]. Is it solely because the Frobenius norm is easier to calculate, or is there some other good mathematical reason for d

Re: [Numpy-discussion] Access to SPARC 64

On 8/30/12 10:10 PM, Ondřej Čertík wrote: > Hi, > > Does anyone have a SPARC 64 machine that I could have an access to, so > that I can try to reproduce and fix the following issue? > > http://projects.scipy.org/numpy/ticket/2076 > > That would be greatly appreciated, as it is currently marked as a

Re: [Numpy-discussion] Meta: help, devel and stackoverflow

In fact, since it's easy to switch the tags, it's easier than a mailing list to shuttle a question to the right "mailing list"/tag. Thanks, Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Meta: help, devel and stackoverflow

On 6/30/12 12:10 PM, Fernando Perez wrote: > On Sat, Jun 30, 2012 at 9:51 AM, Matthew Brett > wrote: >> As a matter of interest - do y'all hang out much on stackexchange? I >> notice that I often go to stackexchange for a good answer, but it >> doesn't seem that good for - discussion. Or maybe

Re: [Numpy-discussion] Meta: help, devel and stackoverflow

On 6/28/12 2:46 PM, Cera, Tim wrote: > That is really funny. Looking through the posts, there wasn't any spam > (could have been deleted), but it wasn't used as much as I would think. > Have to attract people who answer questions. Early on the > registration seemed to be a problem. > > Solace,

Re: [Numpy-discussion] Created NumPy 1.7.x branch

On 6/26/12 3:31 PM, Travis Oliphant wrote: > Thank you for the reminder. I was already called out for not stopping. > Thanks, Dag. A flame-list might indeed be a good idea at this point if > there is further need for "clearing the air" > Also, having it set up before it is needed is part

Re: [Numpy-discussion] Created NumPy 1.7.x branch

On 6/26/12 3:06 PM, Dag Sverre Seljebotn wrote: > Something the Sage project does very well is meeting often in person Another thing we have that has improved the mailing list climate is a "sage-flame" list [1] that serves as a venting release valve for anyone to post *anything* at all. There h

Re: [Numpy-discussion] NumPy 1.7 release delays

On 6/26/12 2:48 PM, Ralf Gommers wrote: > Unfortunately, I think there are issues we are just now seeing with > code that was released in 1.6.x, and there are many people who have > not moved forward to 1.6.x yet. > > > Some examples would be nice. I'll bite. Here's an issue that pre

Re: [Numpy-discussion] Issue Tracking

On 5/1/12 7:24 PM, Charles R Harris wrote: > I would agree that a good search facility is essential, and not > keyword/tag based. I've found some trac tickets with google on occasion, > although not by initial intent. I use google to search the sage trac these days, using a shortcut to limit sear

Re: [Numpy-discussion] Issue Tracking

On 5/1/12 3:19 PM, Fernando Perez wrote: > But if you do decide to go with GHI, it should be based on what the > system is like*today*, not on the hope that it will get better. > About a month ago they broke label filtering by turning multi-label > filters into an OR operation, which effectively re

Re: [Numpy-discussion] Issue Tracking

On 5/1/12 1:52 AM, Travis Oliphant wrote: >> 1. No key:value pairs for labels (Fernando brought this up a long time >> ago, I think). This is brilliant in Google code's tracker, and allows >> for custom fields that help in tracking workflow (like status, priority, >> etc.). Sure, you can do what t

Re: [Numpy-discussion] Issue Tracking

On 4/30/12 6:31 PM, Travis Oliphant wrote: > Hey all, > > We have been doing some investigation of various approaches to issue > tracking. The last time the conversation left this list was with Ralf's > current list of preferences as: > > 1) Redmine > 2) Trac > 3) Github > > Since that time,

Re: [Numpy-discussion] What is consensus anyway

On 4/25/12 11:08 PM, Puneeth Chaganti wrote: > On Thu, Apr 26, 2012 at 6:41 AM, Travis Oliphant wrote: > [snip] >> >> It would be nice if every pull request created a message to this list.Is >> that even possible? > > That is definitely possible and shouldn't be too hard to do, like > Jason s

Re: [Numpy-discussion] What is consensus anyway

On 4/25/12 8:11 PM, Travis Oliphant wrote: > > On Apr 25, 2012, at 7:18 PM, josef.p...@gmail.com wrote: > >> >> Except for the big changes like NA and datetime, I think the debate is >> pretty boring. >> The main problem that I see for discussing technical issues is whether >> there are many >> dev

[Numpy-discussion] Nature Editorial: Science Software should be Open Source

Jan Groenewald posted this link to the Sage development list, and I thought people here would be interested (and I figured people on the matplotlib, scipy, and ipython lists would see it here too): http://www.nature.com/nature/journal/v482/n7386/full/nature10836.html Thanks, Jason

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2/17/12 10:10 PM, Sturla Molden wrote: > Sure. They just keep adding features for the expence of stability. No > focus or sence of direction. Focus on a small feature set, make it > right, then don't add to it. That is the root of the successes of C, > Python and Java. NumPy needs a stabile com

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2/17/12 9:54 PM, Sturla Molden wrote: > We would have to write a C++ programming tutorial that is based on Pyton > knowledge instead of C knowledge. I personally would love such a thing. It's been a while since I did anything nontrivial on my own in C++. Jason _

Re: [Numpy-discussion] Proposed Roadmap Overview

On 2/17/12 9:07 PM, Sturla Molden wrote: > > Den 18. feb. 2012 kl. 01:58 skrev Charles R Harris > mailto:charlesr.har...@gmail.com>>: > >> >> >> On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau > > wrote: >> >> I don't think c++ has any significant advantage over c f

Re: [Numpy-discussion] Numpy governance update

On 2/16/12 8:06 AM, Scott Sinclair wrote: > On 16 February 2012 15:08, Thomas Kluyver wrote: >> It strikes me that the effort everyone's put into this thread could >> have by now designed some way to resolve disputes. ;-) > > This is not intended to downplay the concerns raised in this thread, > b

Re: [Numpy-discussion] Numpy governance update

On 2/16/12 6:23 AM, Francesc Alted wrote: > On Feb 16, 2012, at 12:15 PM, Jason Grout wrote: > >> On 2/15/12 6:27 PM, Dag Sverre Seljebotn wrote: >>> But in the very end, when agreement can't be reached by other >>> means, the developers are the one maki

Re: [Numpy-discussion] Numpy governance update

On 2/15/12 6:27 PM, Dag Sverre Seljebotn wrote: > But in the very end, when agreement can't > be reached by other means, the developers are the one making the calls. > (This is simply a consequence that they are the only ones who can > credibly threaten to fork the project.) Interesting point. I

Re: [Numpy-discussion] Numpy governance update - was: Updated differences between 1.5.1 to 1.6.1

On 2/14/12 7:17 PM, Travis Oliphant wrote: > * Fund Open Source Projects in Science (currently NumPy, SciPy, > IPython, and Matplotlib are first-tier with a whole host of second-tier > projects that could received funding) > * through grants So, for example, would the Foundat

Re: [Numpy-discussion] Issue Tracking

Jeroen's reply about the Sage "buildbot" is below: >Jeroen, do we have an > automatic buildbot system for Sage? Depends on what you mean with "automatic". We have the buildbot setup at http://build.sagemath.org/sage/waterfall which builds automatically but I still have to change versions by ha

Re: [Numpy-discussion] Migrating issues to GitHub

On 2/11/12 3:12 PM, Eric Firing wrote: > A third problem is that the entire style of presentation is poorly > designed from a use standpoint, in comparison to the sourceforge tracker > which mpl used previously. The github tracker appears to have been > designed by a graphics person, not a softwar

Re: [Numpy-discussion] Migrating issues to GitHub

On 2/11/12 1:44 PM, Travis Oliphant wrote: > How to people feel about moving the issue tracking for NumPy to Github? > It looks like they have improved their issue tracking quite a bit and > the workflow and integration with commits looks quite good from what I > can see. > > Here is one tool I saw

Re: [Numpy-discussion] consensus

f it's just me ;) Just a thought: what if this also worked: a.mask[0:2]=np.NA as a synonym for a.mask[0:2]=True? Would that be less confusing, and/or would it be less powerful or extensible in important ways? Thanks, Jason Grout ___ NumPy-Di

Re: [Numpy-discussion] consensus

ictating code to someone (e.g., teaching, or helping someone verbally), it's going to be hard to distinguish between the verbal sounds of "NA" and "MA". And from a lurker (me), thanks for the discussion. I find it very interesting to read. Thanks, Jason Grout

Re: [Numpy-discussion] A Foundation for the support of NumPy and SciPy

On 10/4/11 6:36 PM, Nathaniel Smith wrote: > TL;DR: When it comes to legal matters: starting your own non-profit is > to joining an existing umbrella non-profit as CVS is to git. (And in > fact git is also a SF Conservancy member.) Good point. William has a Sage Foundation set up through Universi

Re: [Numpy-discussion] dtype repr change?

re unit tests, but the requirement right now is only for doctests. Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEPaNEP lessons - was: alterNEP

lear communication. I see that as a very responsible thing to do, given the intensity of some of the feelings in this discussion. Thanks, Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] missing data discussion round 2

On 6/28/11 5:20 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 28, 2011 at 4:06 PM, Nathaniel Smith wrote: > ... >> (You might think, what difference does it make if you *can* unmask an >> item? Us missing data folks could just ignore this feature. But: >> whatever we end up implementing is someth

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 3:18 PM, Jason Grout wrote: > On 4/26/11 11:49 AM, Pauli Virtanen wrote: >> But apparently either there's a bug, or the LAPACK man page needs to >> be understood as you say. > > I've posted a question to the Lapack forum: > > http://icl.cs.utk.edu/

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 3:29 PM, Pauli Virtanen wrote: > On Tue, 26 Apr 2011 14:52:52 -0500, Jason Grout wrote: > [clip] >> The updated rwork calculation makes no difference with a 3x4 matrix >> (both the old calculation and the new calculation give 66 in the 3x4 >> case), so I don&#

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 11:49 AM, Pauli Virtanen wrote: > But apparently either there's a bug, or the LAPACK man page needs to > be understood as you say. I've posted a question to the Lapack forum: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=2402 Thanks, Jason __

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 11:49 AM, Pauli Virtanen wrote: > Tue, 26 Apr 2011 11:36:19 -0500, Jason Grout wrote: > [clip] >> Okay, just one more data point. Our people that are seeing the problem >> with numpy returning a non-unitary V also see a non-unitary V being >> returned by the te

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 11:22 AM, Jason Grout wrote: > On 4/26/11 11:12 AM, Jason Grout wrote: >> On 4/26/11 11:07 AM, Jason Grout wrote: >>> And indeed, I get a 0 row as the last row of the V**H matrix >> >> I just double-checked things one last time and saw that I actual

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 11:12 AM, Jason Grout wrote: > On 4/26/11 11:07 AM, Jason Grout wrote: >> And indeed, I get a 0 row as the last row of the V**H matrix > > I just double-checked things one last time and saw that I actually > hadn't changed the first argument of zgesdd to &q

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/26/11 11:07 AM, Jason Grout wrote: > And indeed, I get a 0 row as the last row of the V**H matrix I just double-checked things one last time and saw that I actually hadn't changed the first argument of zgesdd to "A" in the program that I actually ran. So with this chang

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/25/11 12:57 PM, Pauli Virtanen wrote: > The Numpy routine is a very thin wrapper of LAPACK's ZGESDD, and probably > cannot have any bugs of this kind, As noted in my other message, I've been digging through the ZGESDD docs to understand it better. Here is the doc string for what becomes the

Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's

On 4/25/11 12:57 PM, Pauli Virtanen wrote: > On Mon, 25 Apr 2011 10:16:13 -0700, Rob Beezer wrote: > [clip] >> Many more details and complete transcripts are at: >> http://trac.sagemath.org/sage_trac/ticket/11248 >> >> Any thoughts or advice to help us understand this would be greatly >> appreciate

Re: [Numpy-discussion] What Requires C and what is just python

On 3/20/11 11:54 AM, Lou Pecora wrote: > I'll add my $0.02 here. Someone mentioned SAGE. I can say that on the Mac > the > sage package seems to install very easily and reliably. I've done 4 > installations on Macs 10.4 to 10.6. You can do them with one command line. > They take a few hours

[Numpy-discussion] numpy.linalg.svd documentation

The SVD documentation seems a bit misleading. It says: Factors the matrix a as u * np.diag(s) * v, where u and v are unitary and s is a 1-d array of a‘s singular values. However, that only is true (i.e., you just have to do np.diag(s) to get S) in general if full_matrices is False, which is no

Re: [Numpy-discussion] Development workflow

On 10/12/10 10:33 AM, Charles R Harris wrote: > On Tue, Oct 12, 2010 at 9:22 AM, Pierre GM wrote: > >> >> On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote: >> >>> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote: All, All my sincere apologies for the mess I caused... The changes I wa

Re: [Numpy-discussion] additions to random: innovative names vs. algorithm specification

On 7/29/10 1:37 PM, Robert Kern wrote: > (Book of Guido, 7:42) That's intriguing. Do you happen to have a link to it? Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Disabling Extended Precision in NumPy (like -ffloat-store)

On 04/21/2010 09:47 AM, Adrien Guillon wrote: > Hello all, > > I've recently started to use NumPy to prototype some numerical > algorithms, which will eventually find their way to a GPU (where I > want to limit myself to single-precision operations for performance > reasons). I have recently switc