NumPy is a NumFocus fiscally sponsored project, perhaps they can help with the
costs of different/better hosting.
Bryan
> On Mar 15, 2017, at 07:24, Nathaniel Smith wrote:
>
> On Mar 15, 2017 02:47, "Ralf Gommers" wrote:
>
>
> On Wed, Mar 15, 2017 at 3:21 PM, Matthew Brett
> wrote:
> Hi
Doesn't help all the CI builds that are failing because they utilize
intersphinx to link to the official docs, unfortunately.
Bryan
> On Mar 15, 2017, at 05:59, Ilhan Polat wrote:
>
> By the way, this is not bad at all in the absence of the actual documentation
> http://devdocs.io/numpy~1.1
Bryan Van de Ven
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
There's a good chance that bokeh.charts will be split off into a separately
distributed package as well. Hopefully being a much smaller, pure Python
project makes it a more accessible target for anyone interested in maintaining
it, and if no one is interested in it anymore, well that fact become
Documentation is available at http://bokeh.pydata.org/en/0.12.1
Questions can be directed to the Bokeh mailing list: bo...@continuum.io or the
Gitter Chat room: https://gitter.im/bokeh/bokeh
Thanks,
Bryan Van de Ven
Continuum Analytics
-
Bokeh is a Python interactive visualization library that
or the
Gitter Chat room: https://gitter.im/bokeh/bokeh
Thanks,
Bryan Van de Ven
Continuum Analytics
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
[This is a complete tangent, and so I apologize in advance.]
We are considering applying to GSOC for Bokeh. However, I have zero experience
with GSOC, but non-zero questions (e.g. go it alone, vs apply through PSF... I
think?) If anyone with experience from the mentoring organization side of
th
> On Jan 25, 2016, at 5:21 PM, G Young wrote:
>
> With regards to testing numpy, both Conda and Pip + Virtualenv work quite
> well. I have used both to install master and run unit tests, and both pass
> with flying colors. This chart here illustrates my point nicely as well.
>
> However,
> On Jan 15, 2016, at 21:22, Chris Barker wrote:
>
> Indeed, it's not uncommon for folks on the distutils list to say "go use
> conda" in response to issues that pip does not address well.
I was in the room at the very first proto-PyData conference when Guido told the
assembled crowd "if p
Your first citation is incorrect. It is "VAN DER WALT" (missing V in yours)
Bryan
> On Jan 15, 2016, at 10:36 AM, Li Jiajia wrote:
>
> Hi all,
> I’m a PhD student in Georgia Tech. Recently, we’re working on a survey
> paper about tensor algorithms: basic tensor operations, tensor decomp
> On Dec 4, 2015, at 9:49 AM, Charles R Harris
> wrote:
>
>
>
> On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor
> wrote:
> dropping 3.2: +-0 as it would remove some extra code in our broken py3
> string handling but not much
> dropping 3.3: -1 doesn't gain us anything so far I know
> droppi
> On Dec 3, 2015, at 4:59 PM, Eric Firing wrote:
>
> Chuck,
>
> I would support dropping the old versions now. As a related data point,
> matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and 3.3.
Ditto for Bokeh.
___
NumPy-Discussion
Bokeh also uses TravisCI, and we automatically build deploy docs on "dev"
builds and releases, using encrypted Travis variables to store the necessary
credentials. In case any of that sounds useful, most of the machinery is in
these files:
https://github.com/bokeh/bokeh/blob/master/.tra
> On Sep 22, 2015, at 9:58 PM, Charles R Harris
> wrote:
>
> Hi All,
>
> Just posting to elicit thoughts about scipy.org having a presence in social
> media for announcements.
Of the ones listed in the subject, I would suggest Twitter is the most
valuable. It has been great for release and
> On Sep 22, 2015, at 1:48 PM, Matthew Brett wrote:
>
> The point is, that a sensible organization and a sensible leader has
> to take the possibility of conflict of interest into account. They
> also have to consider the perception of a conflict of interest.
Of course, and the policies to dea
> I have no expectation that continuum will follow any of these paths,
> and in most cases am not even sure what that would mean, BUT just
> because I think it is useful to have a wide variety of concrete
> examples to draw on -- data is good! -- there actually are *lots* of
> examples of "communit
> I don't know how productive it is to dream up examples, but it's not
Well, agreed, to be honest.
> very hard to do. Currently, e.g., the community is not ready to adopt
> numba as part of the ufunc core. But it's been stated by some that,
Who are you speaking for? The entire community? Und
> On Sep 21, 2015, at 9:42 PM, David Cournapeau wrote:
>
>
>
> On Mon, Sep 21, 2015 at 6:33 PM, Bryan Van de Ven wrote:
>
> > On Sep 21, 2015, at 9:24 PM, Matthew Brett wrote:
> >
> > The second problem is that you have a potential conflict of interest
>
> until then our only real options are either hard breaks or nothing, so
> unless we want to do a hard break there's not much point talking about
> it.
I think this is the most important sentence from this thread. Thank you
Nathaniel for you extremely thorough analysis of the impact on real-w
> On Sep 21, 2015, at 9:24 PM, Matthew Brett wrote:
>
> The second problem is that you have a potential conflict of interest,
> in that it is possible for the needs of Continuum to conflict with the
> needs of numpy. I believe, from previous emails on this list, that
> you don't think that is
> On Aug 27, 2015, at 1:57 PM, Matthew Brett wrote:
>
> The 'president' idea
...seems to be predicated on a steady stream of people who: actually want job,
don't mind campaigning, are willing to accept any and all blame, and have the
technical experience to make "final decisions". As others
> On Aug 27, 2015, at 10:22 AM, Matthew Brett wrote:
>
> In the case of the 'core' model, we have some compelling testimony
> from someone with a great deal of experience:
>
> """
> Much of this early structure (CVS, web site, cabal ["core" group],
> etc.) was copied verbatim by other open sour
> On Aug 27, 2015, at 9:36 AM, Matthew Brett wrote:
>
>
> So, in answer to your question, it's difficult to know if a particular
> governance model is successful. It isn't enough that a project has
> lasted, or is still active, because there are so many factors in play.
> On the other hand,
And to eliminate the order kwarg, use functools.partial to patch the zeros
function (or any others, as needed):
In [26]: import numpy as np
In [27]: from functools import partial
In [28]: np.zeros = partial(np.zeros, order="F")
In [29]: x = np.zeros((2,3), dtype
Hi Tom,
I would wait for 0.7, where we are going to make a few changes to the
plotting.py interface. That API started out as a "stateful, implicit current
plot" style interface, and experience has shown that this does not always work
well, especially in the IPython notebook where you can have a
the Bokeh mailing list: bo...@continuum.io
If you have interest in helping to develop Bokeh, please get involved!
Thanks,
Bryan Van de Ven
Continuum Analytics
http://continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail
cial
thanks to recent contributors: Tabish Chasmawala, Samuel Colvin, Christina
Doig, Tarun Gaba, Maggie Mari, Amy Troschinetz, Ben Zaitlen.
Bryan Van de Ven
Continuum Analytics
http://continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion
Speaking as someone who started but then stopped dabbling in the NumPy C core,
having to think about two build system is a huge turn-off. Getting into the
NumPy C code is hard enough without having to worry about multiple build
systems.
Bryan
On Jul 5, 2014, at 6:42 PM, Ralf Gommers wrote:
Special
thanks to recent contributors: Amy Troschinetz and Gerald Dalley
Bryan Van de Ven
Continuum Analytics
http://continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
b.com/continuumio/bokeh
Questions can be directed to the Bokeh mailing list: bo...@continuum.io
Special thanks to recent contributors: Melissa Gymrek, Amy Troschinetz, Ben
Zaitlen, Damian Avila, and Terry Jones
Regards,
Bryan Van de Ven
Continuum Analytics
http://continu
s can be made on the Bokeh Github
page: https://github.com/continuumio/bokeh
Questions can be directed to the Bokeh mailing list: bo...@continuum.io
Special thanks to recent contributors: Janek Klawe, Samantha Hughes, Rebecca
Paz, and Benedikt Sauer.
Regards,
Bryan Van de Ven
uumio/bokeh
Questions can be directed to the Bokeh mailing list: bo...@continuum.io
Regards,
Bryan Van de Ven
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On the other hand, the most salient quality an unavoidable copy is that it is
unavoidable. For people for whom using Hermitian conjugates is common, it's not
like they won't do it just because they can't avoid a copy that can't be
avoided. Given that if a problem dictates a Hermitian conjugate
I'm not sure what you tried, but stack will do what you are seeking:
In [7]: cc = np.ones((2,10)) * np.arange(1, 11)
In [8]: cc
Out[8]:
array([[ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10.],
[ 1., 2., 3., 4., 5., 6., 7., 8., 9., 10.]])
In [9]: np.vstack((n
On 6/13/12 5:11 PM, Wes McKinney wrote:
> And retrieving group indicies/summing:
>
> In [8]: %timeit arr=='a'
> 1000 loops, best of 3: 1.52 ms per loop
> In [10]: vals = np.random.randn(100)
> In [20]: inds = [arr==x for x in lets]
> In [23]: %timeit for ind in inds: vals[ind].sum()
> 10 loops,
On 6/13/12 1:12 PM, Nathaniel Smith wrote:
> your-branch's-base-master but not in your-repo's-master are new stuff
> that you did on your branch. Solution is just to do
>git push master
Fixed, thanks.
> Yes, of course we *could* write the code to implement these "open"
> dtypes, and then wri
On 6/13/12 1:54 PM, Wes McKinney wrote:
> OK, I need to spend some time on this as it will directly impact me.
> Random thoughts here.
>
> It looks like the levels can only be strings. This is too limited for
> my needs. Why not support all possible NumPy dtypes? In pandas world,
> the levels can b
On 6/13/12 8:33 AM, Nathaniel Smith wrote:
> Hi Bryan,
>
> I skimmed over the diff:
> https://github.com/bryevdv/numpy/compare/master...enum
> It was a bit hard to read since it seems like about half the changes
> in that branch are datatime cleanups or something? I hope you'll
> separate those
provide!
Thanks,
Bryan Van de Ven
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 4/12/12 8:41 PM, Charles R Harris wrote:
It seems that python2.7 is far, far, too recent to be part of Debian
6. I mean, finding python 2.7 in recent Debian stable would be like
finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in
testing, but for replication I like to know
On 4/10/12 2:40 PM, Ralf Gommers wrote:
On Mon, Apr 9, 2012 at 10:32 PM, Bryan Van de Ven <mailto:bry...@continuum.io>> wrote:
On 4/3/12 4:18 PM, Ralf Gommers wrote:
> Here some first impressions.
>
> The good:
> - It's responsive!
>
On 4/3/12 4:18 PM, Ralf Gommers wrote:
> Here some first impressions.
>
> The good:
> - It's responsive!
> - It remembers my preferences (view type, # of issues per page, etc.)
> - Editing multiple issues with the command window is easy.
> - Search and filter functionality is powerful
>
> The bad:
On 4/3/12 4:18 PM, Ralf Gommers wrote:
> The bad:
> - Multiple projects are supported, but issues are then really mixed.
> The way this works doesn't look very useful for combined admin of
> numpy/scipy trackers.
> - I haven't found a way yet to make versions and subsystems appear in
> the one-l
Sure, that would be easy enough to implement. I don't really have
a preference, is there a reason you would prefer that API?
No, just exploring possibilities. Another would be a different name,
searchargsorted or some such. I actually think that is a better
alternative than the pair,
On 3/26/12 4:57 PM, Charles R Harris wrote:
On Mon, Mar 26, 2012 at 3:34 PM, Bryan Van de Ven <mailto:bry...@continuum.io>> wrote:
I recently got asked about an "arg" version of searchsorted,
basically a
version that could take a sorter as an additional argumen
I recently got asked about an "arg" version of searchsorted, basically a
version that could take a sorter as an additional argument. For instance:
In [13]: a = np.array([5,6,8,1,6,9,0])
In [14]: s = np.argsort(a)
In [17]: s
Out[17]: array([6, 3, 0, 1, 4, 2, 5])
In [18]
Hi all,
I have spent some time thinking about things, and discussing them with
folks nearby. I actually got to wondering whether we really need new
dtypes for this. It seems like enumerated values or factor levels could
be cast as an annotation or metadata that could be attached to any
existin
Hi all,
I have started working on a NEP for adding an enumerated type to NumPy.
It is on my GitHub:
https://github.com/bryevdv/numpy/blob/enum/doc/neps/enum.rst
It is still very rough, and incomplete in places. But I would like to
get feedback sooner rather than later in order to refine i
On 3/6/12 2:39 PM, Sturla Molden wrote:
> We can augment standard C with syntax suger for
> generics, or even NumPy arrays and Python types, using a Python script
> as meta-compiler. We don't need C++ for that.
I can only speak for myself. I do not want to be in the meta-compiler
business, and I d
nd documenting what subset of C++ features
are acceptable for use within the numpy codebase.
Bryan Van de Ven
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ly did was rename reserved keywords and add extern "C" where
necessary. Although, AFAIK C99 complex support is included as an
extension, so I believe you are correct that there would be more work
there to get that working under more platforms.
in the future.
BTW I'd also just like to take this chance to say "Hello" to the list, I
am very excited to help improve numpy.
Bryan Van de Ven
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
otypes needs to be set for this to work.
In [19]: vstrip = vectorize( string.strip, otypes=[object])
In [20]: s = [' aa ' , ' bb ', '
cc ']
In [21]: vstrip(s)
Out[21]: array([aa, bb, cc],
dtype=object)
Christopher Barker wrote:
> Does anyone know the status of support for valarrays now?
I used std::valarray to implement a variant of the example Matrix class in
Stroustrup's book (2D only) about two years ago. I was aware that is in disuse,
by and large, but it worked well enough for my purpose
> Do you know if there's a current package to associate units with numpy
> arrays? For my purposes it would usually be sufficient to have arrays
> of quantities with uniform units. Conversions need only be
> multiplicative (I don't care about Celsius-to-Fahrenheit style
> conversions) and need not
Neal Becker wrote:
> I'm perfectly happy with python myself, but I wonder if anyone has good
> arguments for why to prefer python over matlab?
>
From my own experience, once you move past static plots and want to include
some kind of interactive GUI (that is, build an actual application) then y
56 matches
Mail list logo
