Re: [Numpy-discussion] GSoC 2017: NumFocus will be an umbrella organization

[Max Linke]

On 01/18/2017 09:28 AM, Ralf Gommers wrote:

Hi Max,

On Tue, Jan 17, 2017 at 2:38 AM, Max Linke mailto:max_li...@gmx.de>> wrote:

Hi

Organizations can start submitting applications for Google Summer of
Code 2017 on January 19 (and the deadline is February 9)

https://developers.google.com/open-source/gsoc/timeline?hl=en



Thanks for bringing this up, and for organizing the NumFOCUS
participation!


NumFOCUS will be applying again this year. If you want to work with
us please let me know and if you apply as an organization yourself
or under a different umbrella organization please tell me as well.


I suspect we won't participate at all, but if we do then it's likely
under the PSF umbrella as we have done previously.


Thanks for letting me now. If you decide to participate with the PSF
please write me a private mail so that I can update the NumFOCUS gsoc
page accordingly.



@all: in practice working on NumPy is just far too hard for most
GSoC students. Previous years we've registered and generated ideas,
but not gotten any students. We're also short on maintainer capacity.
So I propose to not participate this year.

Ralf



___ NumPy-Discussion
mailing list NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2017: NumFocus will be an umbrella organization

[Ralf Gommers]

Hi Max,

On Tue, Jan 17, 2017 at 2:38 AM, Max Linke  wrote:

> Hi
>
> Organizations can start submitting applications for Google Summer of Code
> 2017 on January 19 (and the deadline is February 9)
>
> https://developers.google.com/open-source/gsoc/timeline?hl=en


Thanks for bringing this up, and for organizing the NumFOCUS participation!


> NumFOCUS will be applying again this year. If you want to work with us
> please let me know and if you apply as an organization yourself or under a
> different umbrella organization please tell me as well.


I suspect we won't participate at all, but if we do then it's likely under
the PSF umbrella as we have done previously.

@all: in practice working on NumPy is just far too hard for most GSoC
students. Previous years we've registered and generated ideas, but not
gotten any students. We're also short on maintainer capacity. So I propose
to not participate this year.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC 2017: NumFocus will be an umbrella organization

[Max Linke]

Hi

Organizations can start submitting applications for Google Summer of Code
2017 on January 19 (and the deadline is February 9)

https://developers.google.com/open-source/gsoc/timeline?hl=en

NumFOCUS will be applying again this year. If you want to work with us
please let me know and if you apply as an organization yourself or under a
different umbrella organization please tell me as well. If you participate
with us it would be great if you start to add possible projects to the
ideas page on github soon. We some general information for mentors on
github.

https://github.com/numfocus/gsoc/blob/master/CONTRIBUTING-mentors.md

We also have a template for ideas that might help. It lists the things
Google likes to see.

https://github.com/numfocus/gsoc/blob/master/2017/ideas-list-skeleton.md

In case you participated in earlier years with NumFOCUS there are some
small changes this year. Raniere won't be the admin this year. Instead I'm
going to be the admin. We are also planning to include two explicit rules
when a student should be failed, they have to communicate regularly and
commit code into your development branch at the end of the summer.

best, Max


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Sebastian Berg]

On Fr, 2016-03-04 at 21:20 +, Pauli Virtanen wrote:
> Thu, 11 Feb 2016 00:02:52 +0100, Ralf Gommers kirjoitti:
> [clip]
> > OK first version:
> > https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas I kept
> > some
> > of the ideas from last year, but removed all potential mentors as
> > the
> > same people may not be available this year - please re-add
> > yourselves
> > where needed.
> > 
> > And to everyone who has a good idea, and preferably is willing to
> > mentor
> > for that idea: please add it to that page.
> 
> I probably don't have bandwidth for mentoring, but as the Numpy 
> suggestions seem to be mostly "hard" problems, we can add another 
> one:
> 
> ## Dealing with overlapping input/output data
> 
> Numpy operations where output arrays overlap with 
> input arrays can produce unexpected results.
> A simple example is
> ```
> x = np.arange(100*100).reshape(100,100)
> x += x.T# <- undefined result!
> ```
> The task is to change Numpy so that the results
> here become similar to as if the input arrays
> overlapping with output were separate (here: `x += x.T.copy()`).
> The challenge here lies in doing this without sacrificing 
> too much performance or memory efficiency.
> 
> Initial steps toward solving this problem were taken in
> https://github.com/numpy/numpy/pull/6166
> where a simplest available algorithm for detecting
> if arrays overlap was added. However, this is not yet
> utilized in ufuncs. An initial attempt to sketch what 
> should be done is at https://github.com/numpy/numpy/issues/6272
> and issues referenced therein.
> 

Since I like the idea, I copy pasted it into the GSoC project ideas
wiki.

- Sebastian


> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Pauli Virtanen]

Thu, 11 Feb 2016 00:02:52 +0100, Ralf Gommers kirjoitti:
[clip]
> OK first version:
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas I kept some
> of the ideas from last year, but removed all potential mentors as the
> same people may not be available this year - please re-add yourselves
> where needed.
> 
> And to everyone who has a good idea, and preferably is willing to mentor
> for that idea: please add it to that page.

I probably don't have bandwidth for mentoring, but as the Numpy 
suggestions seem to be mostly "hard" problems, we can add another 
one:

## Dealing with overlapping input/output data

Numpy operations where output arrays overlap with 
input arrays can produce unexpected results.
A simple example is
```
x = np.arange(100*100).reshape(100,100)
x += x.T# <- undefined result!
```
The task is to change Numpy so that the results
here become similar to as if the input arrays
overlapping with output were separate (here: `x += x.T.copy()`).
The challenge here lies in doing this without sacrificing 
too much performance or memory efficiency.

Initial steps toward solving this problem were taken in
https://github.com/numpy/numpy/pull/6166
where a simplest available algorithm for detecting
if arrays overlap was added. However, this is not yet
utilized in ufuncs. An initial attempt to sketch what 
should be done is at https://github.com/numpy/numpy/issues/6272
and issues referenced therein.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Evgeni Burovski]

> On Wed, Feb 10, 2016 at 11:55 PM, Ralf Gommers 
> wrote:



>> This is last year's page:
>> https://github.com/scipy/scipy/wiki/GSoC-2015-project-ideas
>>
>> Some ideas have been worked on, others are still relevant. Let's copy this
>> page to -2016- and start editing it and adding new ideas. I'll start right
>> now actually.
>
>
> OK first version:
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas
> I kept some of the ideas from last year, but removed all potential mentors
> as the same people may not be available this year - please re-add yourselves
> where needed.

Thanks Ralf for doing it!

Just a quick note on de-listed projects. While I do not disagree with
removing the projects on splines and special functions, this IMO does
not mean we won't consider proposals on either of these topics if
someone wants to write one. For instance, if Josh or Ted want to frame
their work on hypergeometric functions as a GSoC project, I'm sure
we're going to at least consider these.

Evgeni
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Andy Ray Terrel]

On Wed, Feb 17, 2016 at 12:57 PM, Chris Barker 
wrote:

> Apparetnly, NumFocus is applyign to be a GSoC Umbrella org as well:
>
> https://github.com/numfocus/gsoc
>
> Not sure why one might choose NumFocus vs PSF...
>
>
No reason to choose, you can get students from both orgs.


> -Chris
>
>
> On Wed, Feb 17, 2016 at 6:05 AM, Bryan Van de Ven 
> wrote:
>
>> [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 things wouldn't mind a quick chat (or a few emails) to
>> answer questions, share your experience, or offer advice, please drop me a
>> line directly.
>>
>> Thanks,
>>
>> Bryan
>>
>>
>>
>> > On Feb 17, 2016, at 1:14 AM, Stephan Hoyer  wrote:
>> >
>> > On Wed, Feb 10, 2016 at 4:22 PM, Chris Barker 
>> wrote:
>> > We might consider adding "improve duck typing for numpy arrays"
>> >
>> > care to elaborate on that one?
>> >
>> > I know it come up on here that it would be good to have some code in
>> numpy itself that made it easier to make array-like objects (I.e. do
>> indexing the same way) Is that what you mean?
>> >
>> > I was thinking particularly of improving the compatibility of numpy
>> functions (e.g., concatenate) with non-numpy array-like objects, but now
>> that you mention it utilities to make it easier to make array-like objects
>> could also be a good thing.
>> >
>> > In any case, I've now elaborated on my thought into a full project idea
>> on the Wiki:
>> >
>> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas#improved-duck-typing-support-for-n-dimensional-arrays
>> >
>> > Arguably, this might be too difficult for most GSoC students -- the API
>> design questions here are quite contentious. But given that "Pythonic
>> dtypes" is up there as a GSoC proposal still it's in good company.
>> >
>> > Cheers,
>> > Stephan
>> >
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@scipy.org
>> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Chris Barker]

Apparetnly, NumFocus is applyign to be a GSoC Umbrella org as well:

https://github.com/numfocus/gsoc

Not sure why one might choose NumFocus vs PSF...

-Chris


On Wed, Feb 17, 2016 at 6:05 AM, Bryan Van de Ven 
wrote:

> [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 things wouldn't mind a quick chat (or a few emails) to
> answer questions, share your experience, or offer advice, please drop me a
> line directly.
>
> Thanks,
>
> Bryan
>
>
>
> > On Feb 17, 2016, at 1:14 AM, Stephan Hoyer  wrote:
> >
> > On Wed, Feb 10, 2016 at 4:22 PM, Chris Barker 
> wrote:
> > We might consider adding "improve duck typing for numpy arrays"
> >
> > care to elaborate on that one?
> >
> > I know it come up on here that it would be good to have some code in
> numpy itself that made it easier to make array-like objects (I.e. do
> indexing the same way) Is that what you mean?
> >
> > I was thinking particularly of improving the compatibility of numpy
> functions (e.g., concatenate) with non-numpy array-like objects, but now
> that you mention it utilities to make it easier to make array-like objects
> could also be a good thing.
> >
> > In any case, I've now elaborated on my thought into a full project idea
> on the Wiki:
> >
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas#improved-duck-typing-support-for-n-dimensional-arrays
> >
> > Arguably, this might be too difficult for most GSoC students -- the API
> design questions here are quite contentious. But given that "Pythonic
> dtypes" is up there as a GSoC proposal still it's in good company.
> >
> > Cheers,
> > Stephan
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Bryan Van de Ven]

[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 
things wouldn't mind a quick chat (or a few emails) to answer questions, share 
your experience, or offer advice, please drop me a line directly. 

Thanks,

Bryan 



> On Feb 17, 2016, at 1:14 AM, Stephan Hoyer  wrote:
> 
> On Wed, Feb 10, 2016 at 4:22 PM, Chris Barker  wrote:
> We might consider adding "improve duck typing for numpy arrays" 
> 
> care to elaborate on that one?
> 
> I know it come up on here that it would be good to have some code in numpy 
> itself that made it easier to make array-like objects (I.e. do indexing the 
> same way) Is that what you mean?
> 
> I was thinking particularly of improving the compatibility of numpy functions 
> (e.g., concatenate) with non-numpy array-like objects, but now that you 
> mention it utilities to make it easier to make array-like objects could also 
> be a good thing.
> 
> In any case, I've now elaborated on my thought into a full project idea on 
> the Wiki:
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas#improved-duck-typing-support-for-n-dimensional-arrays
> 
> Arguably, this might be too difficult for most GSoC students -- the API 
> design questions here are quite contentious. But given that "Pythonic dtypes" 
> is up there as a GSoC proposal still it's in good company.
> 
> Cheers,
> Stephan
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Stephan Hoyer]

On Wed, Feb 10, 2016 at 4:22 PM, Chris Barker  wrote:

> We might consider adding "improve duck typing for numpy arrays"
>>
>
> care to elaborate on that one?
>
> I know it come up on here that it would be good to have some code in numpy
> itself that made it easier to make array-like objects (I.e. do indexing the
> same way) Is that what you mean?
>

I was thinking particularly of improving the compatibility of numpy
functions (e.g., concatenate) with non-numpy array-like objects, but now
that you mention it utilities to make it easier to make array-like objects
could also be a good thing.

In any case, I've now elaborated on my thought into a full project idea on
the Wiki:
https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas#improved-duck-typing-support-for-n-dimensional-arrays

Arguably, this might be too difficult for most GSoC students -- the API
design questions here are quite contentious. But given that "Pythonic
dtypes" is up there as a GSoC proposal still it's in good company.

Cheers,
Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Chris Barker]

>
> We might consider adding "improve duck typing for numpy arrays"
>

care to elaborate on that one?

I know it come up on here that it would be good to have some code in numpy
itself that made it easier to make array-like objects (I.e. do indexing the
same way) Is that what you mean?

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Stephan Hoyer]

On Wed, Feb 10, 2016 at 3:02 PM, Ralf Gommers 
wrote:

> OK first version:
> https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas
> I kept some of the ideas from last year, but removed all potential mentors
> as the same people may not be available this year - please re-add
> yourselves where needed.
>
> And to everyone who has a good idea, and preferably is willing to mentor
> for that idea: please add it to that page.
>
> Ralf
>

I removed the "Improve Numpy datetime functionality" project, since the
relevant improvements have mostly already made it into NumPy 1.11.

We might consider adding "improve duck typing for numpy arrays" if any GSOC
students are true masochists ;). I could potentially be a mentor for this
one, though of course Nathaniel is the obvious choice.

Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Ralf Gommers]

On Wed, Feb 10, 2016 at 11:55 PM, Ralf Gommers 
wrote:

>
>
> On Wed, Feb 10, 2016 at 11:48 PM, Chris Barker 
> wrote:
>
>> Thanks Ralf,
>>
>> Note that we have always done a combined numpy/scipy ideas page and
>>> submission. For really good students numpy may be the right challenge, but
>>> in general scipy is easier to get started on.
>>>
>>
>> yup -- good idea. Is there a page ready to go, or do we need to get one
>> up? (I don't even know where to put it...)
>>
>
> This is last year's page:
> https://github.com/scipy/scipy/wiki/GSoC-2015-project-ideas
>
> Some ideas have been worked on, others are still relevant. Let's copy this
> page to -2016- and start editing it and adding new ideas. I'll start right
> now actually.
>

OK first version:
https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas
I kept some of the ideas from last year, but removed all potential mentors
as the same people may not be available this year - please re-add
yourselves where needed.

And to everyone who has a good idea, and preferably is willing to mentor
for that idea: please add it to that page.

Ralf



>
>
>>
>>
>>> Under the PSF umbrella has always worked very well, both in terms of
>>> communication quality and of getting the amount of slots we wanted, so yes.
>>>
>>
>> hmm, looking here:
>>
>> https://wiki.python.org/moin/SummerOfCode/2016#Sub-orgs
>>
>> it seems it's time to get started. and I _think_ our ideas page can go on
>> that Wiki.
>>
>>
>>> Are you maybe interested in co-organizing or mentoring Chris? Updating
>>> the ideas page, proposal reviewing and interviewing students via video
>>> calls can be time-consuming, and mentoring definitely is, so the more the
>>> merrier.
>>>
>>
>> I would love to help -- though I don't think I can commit to being a
>> full-on mentor.
>>
>> If we get a couple people to agree to mentor,
>>
>
> That's always the tricky part. We normally let people indicate whether
> they're interested in mentoring for specific project ideas on the ideas
> page.
>
>
>> then we can get ourselves setup up with the PSF.
>> 
>>
>
> That's the easiest part, takes one email and one wiki page edit:)
>
> Ralf
>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Ralf Gommers]

On Wed, Feb 10, 2016 at 11:48 PM, Chris Barker 
wrote:

> Thanks Ralf,
>
> Note that we have always done a combined numpy/scipy ideas page and
>> submission. For really good students numpy may be the right challenge, but
>> in general scipy is easier to get started on.
>>
>
> yup -- good idea. Is there a page ready to go, or do we need to get one
> up? (I don't even know where to put it...)
>

This is last year's page:
https://github.com/scipy/scipy/wiki/GSoC-2015-project-ideas

Some ideas have been worked on, others are still relevant. Let's copy this
page to -2016- and start editing it and adding new ideas. I'll start right
now actually.


>
>
>> Under the PSF umbrella has always worked very well, both in terms of
>> communication quality and of getting the amount of slots we wanted, so yes.
>>
>
> hmm, looking here:
>
> https://wiki.python.org/moin/SummerOfCode/2016#Sub-orgs
>
> it seems it's time to get started. and I _think_ our ideas page can go on
> that Wiki.
>
>
>> Are you maybe interested in co-organizing or mentoring Chris? Updating
>> the ideas page, proposal reviewing and interviewing students via video
>> calls can be time-consuming, and mentoring definitely is, so the more the
>> merrier.
>>
>
> I would love to help -- though I don't think I can commit to being a
> full-on mentor.
>
> If we get a couple people to agree to mentor,
>

That's always the tricky part. We normally let people indicate whether
they're interested in mentoring for specific project ideas on the ideas
page.


> then we can get ourselves setup up with the PSF.
> 
>

That's the easiest part, takes one email and one wiki page edit:)

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Chris Barker]

Thanks Ralf,

Note that we have always done a combined numpy/scipy ideas page and
> submission. For really good students numpy may be the right challenge, but
> in general scipy is easier to get started on.
>

yup -- good idea. Is there a page ready to go, or do we need to get one up?
(I don't even know where to put it...)


> Under the PSF umbrella has always worked very well, both in terms of
> communication quality and of getting the amount of slots we wanted, so yes.
>

hmm, looking here:

https://wiki.python.org/moin/SummerOfCode/2016#Sub-orgs

it seems it's time to get started. and I _think_ our ideas page can go on
that Wiki.


> Are you maybe interested in co-organizing or mentoring Chris? Updating the
> ideas page, proposal reviewing and interviewing students via video calls
> can be time-consuming, and mentoring definitely is, so the more the merrier.
>

I would love to help -- though I don't think I can commit to being a
full-on mentor.

If we get a couple people to agree to mentor, then we can get ourselves
setup up with the PSF.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Ralf Gommers]

On Tue, Feb 9, 2016 at 1:02 AM, Chris Barker  wrote:

> As you can see in the timeline:
>
> https://developers.google.com/open-source/gsoc/timeline
>
> We are now in the stage where mentoring organizations are getting their
> act together. So the question now is -- are there folks that want to mentor
> for numpy projects? It can be rewarding, but it's a pretty big commitment
> as well, and, I suppose depending on the project, would require some good
> knowledge of the innards of numpy -- there are not a lot of those folks out
> there that have that background.
>

Note that we have always done a combined numpy/scipy ideas page and
submission. For really good students numpy may be the right challenge, but
in general scipy is easier to get started on. So we have difficult project
ideas for both, but easy/intermediate ones will most likely be for scipy.


>
> So to students, I suggest you keep an eye out, and engage a little later
> on in the process.
>
> That being said, if you have a idea for a numpy improvement you'd like to
> work on , by all means propose it and maybe you'll get a mentor or two
> excited.
>
> -CHB
>
>
>
>
>
> On Mon, Feb 8, 2016 at 3:33 PM, SMRUTI RANJAN SAHOO 
> wrote:
>
>> sir actually i am interested  very much . so can you help me about this
>> or suggest some , so that i  can contribute .
>>
>
Hi Smruti, I suggest you look at the numpy or scipy issues on Github, and
start with one labeled "easy-fix".


>
>> Thanks  & Regards,
>> Smruti Ranjan Sahoo
>>
>> On Tue, Feb 9, 2016 at 1:58 AM, Chris Barker 
>> wrote:
>>
>>>
>>> I think the real challenge is having folks with the time to really put
>>> into mentoring, but if folks want to do it -- numpy could really benefit.
>>>
>>> Maybe as a python.org sub-project?
>>>
>>
Under the PSF umbrella has always worked very well, both in terms of
communication quality and of getting the amount of slots we wanted, so yes.


>
>>> https://wiki.python.org/moin/SummerOfCode/2016
>>>
>>> Deadlines are approaching -- so I thought I'd ping the list and see if
>>> folks are interested.
>>> ANyone interested in Google Summer of Code this year?
>>>
>>
Yes, last year we had quite a productive GSoC, so I had planned to organize
it along the same lines again (with an updated ideas page of course).

Are you maybe interested in co-organizing or mentoring Chris? Updating the
ideas page, proposal reviewing and interviewing students via video calls
can be time-consuming, and mentoring definitely is, so the more the merrier.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Elliot Hallmark]

Is there a clean way of importing existing C code as a vectorized numpy
func?  Like, it would be awesome to use gdal in a vectorized way just with
ctypes or something.

Just something I've dreamed of that I thought I'd ask about in regards to
the GSoC.

Elliot
On Feb 8, 2016 6:03 PM, "Chris Barker"  wrote:

> As you can see in the timeline:
>
> https://developers.google.com/open-source/gsoc/timeline
>
> We are now in the stage where mentoring organizations are getting their
> act together. So the question now is -- are there folks that want to mentor
> for numpy projects? It can be rewarding, but it's a pretty big commitment
> as well, and, I suppose depending on the project, would require some good
> knowledge of the innards of numpy -- there are not a lot of those folks out
> there that have that background.
>
> So to students, I suggest you keep an eye out, and engage a little later
> on in the process.
>
> That being said, if you have a idea for a numpy improvement you'd like to
> work on , by all means propose it and maybe you'll get a mentor or two
> excited.
>
> -CHB
>
>
>
>
>
> On Mon, Feb 8, 2016 at 3:33 PM, SMRUTI RANJAN SAHOO 
> wrote:
>
>> sir actually i am interested  very much . so can you help me about this
>> or suggest some , so that i  can contribute .
>>
>>
>>
>>
>> Thanks  & Regards,
>> Smruti Ranjan Sahoo
>>
>> On Tue, Feb 9, 2016 at 1:58 AM, Chris Barker 
>> wrote:
>>
>>> ANyone interested in Google Summer of Code this year?
>>>
>>> I think the real challenge is having folks with the time to really put
>>> into mentoring, but if folks want to do it -- numpy could really benefit.
>>>
>>> Maybe as a python.org sub-project?
>>>
>>> https://wiki.python.org/moin/SummerOfCode/2016
>>>
>>> Deadlines are approaching -- so I thought I'd ping the list and see if
>>> folks are interested.
>>>
>>> -Chris
>>>
>>>
>>>
>>> --
>>>
>>> Christopher Barker, Ph.D.
>>> Oceanographer
>>>
>>> Emergency Response Division
>>> NOAA/NOS/OR&R(206) 526-6959   voice
>>> 7600 Sand Point Way NE   (206) 526-6329   fax
>>> Seattle, WA  98115   (206) 526-6317   main reception
>>>
>>> chris.bar...@noaa.gov
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[Chris Barker]

As you can see in the timeline:

https://developers.google.com/open-source/gsoc/timeline

We are now in the stage where mentoring organizations are getting their act
together. So the question now is -- are there folks that want to mentor for
numpy projects? It can be rewarding, but it's a pretty big commitment as
well, and, I suppose depending on the project, would require some good
knowledge of the innards of numpy -- there are not a lot of those folks out
there that have that background.

So to students, I suggest you keep an eye out, and engage a little later on
in the process.

That being said, if you have a idea for a numpy improvement you'd like to
work on , by all means propose it and maybe you'll get a mentor or two
excited.

-CHB





On Mon, Feb 8, 2016 at 3:33 PM, SMRUTI RANJAN SAHOO 
wrote:

> sir actually i am interested  very much . so can you help me about this or
> suggest some , so that i  can contribute .
>
>
>
>
> Thanks  & Regards,
> Smruti Ranjan Sahoo
>
> On Tue, Feb 9, 2016 at 1:58 AM, Chris Barker 
> wrote:
>
>> ANyone interested in Google Summer of Code this year?
>>
>> I think the real challenge is having folks with the time to really put
>> into mentoring, but if folks want to do it -- numpy could really benefit.
>>
>> Maybe as a python.org sub-project?
>>
>> https://wiki.python.org/moin/SummerOfCode/2016
>>
>> Deadlines are approaching -- so I thought I'd ping the list and see if
>> folks are interested.
>>
>> -Chris
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>>
>> chris.bar...@noaa.gov
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC?

[SMRUTI RANJAN SAHOO]

sir actually i am interested  very much . so can you help me about this or
suggest some , so that i  can contribute .




Thanks  & Regards,
Smruti Ranjan Sahoo

On Tue, Feb 9, 2016 at 1:58 AM, Chris Barker  wrote:

> ANyone interested in Google Summer of Code this year?
>
> I think the real challenge is having folks with the time to really put
> into mentoring, but if folks want to do it -- numpy could really benefit.
>
> Maybe as a python.org sub-project?
>
> https://wiki.python.org/moin/SummerOfCode/2016
>
> Deadlines are approaching -- so I thought I'd ping the list and see if
> folks are interested.
>
> -Chris
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC?

[Chris Barker]

ANyone interested in Google Summer of Code this year?

I think the real challenge is having folks with the time to really put into
mentoring, but if folks want to do it -- numpy could really benefit.

Maybe as a python.org sub-project?

https://wiki.python.org/moin/SummerOfCode/2016

Deadlines are approaching -- so I thought I'd ping the list and see if
folks are interested.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC'15 accepted students for Scipy/Numpy

[Ralf Gommers]

Hi all,

Google has just announced which students got accepted for this year's GSoC.
For Scipy these are:
- Nikolay Mayorov, "Improve nonlinear least squares minimization
functionality in SciPy"
  mentors: Chuck & Evgeni
- Abraham Escalante, "SciPy: scipy.stats improvements"
  mentor: Ralf (Evgeni is backup mentor)

Furthermore, this proposal was accepted for Scikit-image:
- Aman Singh, "Scikit-Image: rewriting scipy.ndimage to cython"
  mentors: Jaime, Ralf & the scikit-image devs

Congratulations to all of you!

We had a lot of interest this year, which is great to see. GSoC
applications are competitive, and unfortunately there are students who
didn't make it. To those students I would say: please stay involved, and
you're very welcome to apply again next year!

Today is also the start of the "community bonding period", where the
students aren't yet expected to start working on their project but do get
time to further figure out how things work, interact with the community and
ensure that they can hit the ground running on day 1 of the coding period:
http://googlesummerofcode.blogspot.nl/2007/04/so-what-is-this-community-bonding-all.html.


It looks like it'll be an interesting and productive summer!

Cheers,
Ralf

P.S. all proposals are linked on
https://github.com/scipy/scipy/wiki/GSoC-project-ideas#student-applications-for-2015-to-scipy-and-numpy
for who's interested in the details.

P.P.S. some students have asked to get some feedback about why they
were/weren't accepted, in order to learn from it for a next time. Until
today we weren't allowed to say much, but now that Google has announced the
results I'd be happy to give some feedback - please contact me in private
if you want.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC students: please read

[Ralf Gommers]

On Mon, Mar 23, 2015 at 10:42 PM, Ralf Gommers 
wrote:

Hi Stephan, all,

On Mon, Mar 23, 2015 at 10:29 PM, Stephan Hoyer  wrote:
>
>> On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers 
>> wrote:
>>
>>> It's great to see that this year there are a lot of students interested
>>> in doing a GSoC project with Numpy or Scipy. So far five proposals have
>>> been submitted, and it looks like several more are being prepared now.
>>>
>>
>> Hi Ralf,
>>
>> Is there a centralized place for non-mentors to view proposals and give
>> feedback?
>>
>
> Hi Stephan, there isn't really. All students post their drafts to the
> mailing list, where they can get feedback. They're free to keep that draft
> wherever they want - blogs, Github, StackEdit, ftp sites and more are all
> being used. The central overview is in Melange (the official GSoC tool),
> but that's not publicly accessible.
>

This was actually a very good idea, for next year we should require
proposals on Github and added to an overview page. For this year it was a
bit late to require all students to make this change, but I've compiled an
overview of all proposals that have been submitted including links to
Melange and the public drafts that students posted to the mailing lists:
https://github.com/scipy/scipy/wiki/GSoC-project-ideas#student-applications-for-2015-to-scipy-and-numpy

I hope that this helps. Everyone who is signed up as a mentor can comment
(privately or publicly) in Melange, and everyone who's interested can now
more easily find back the mailing list threads on this and comment there.

Cheers,
Ralf




> Note that an overview of project ideas can be found at
> https://github.com/scipy/scipy/wiki/GSoC-project-ideas. If you're
> particularly interested in one or more of those, it should be easy to find
> back in the mailing list archive what students sent draft proposals for
> feedback. Your comments on individual proposals will be much appreciated.
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC students: please read

[Ralf Gommers]

On Mon, Mar 23, 2015 at 10:21 PM, Ralf Gommers 
wrote:

> Hi all,
>
> It's great to see that this year there are a lot of students interested in
> doing a GSoC project with Numpy or Scipy. So far five proposals have been
> submitted, and it looks like several more are being prepared now. I'd like
> to give you a bit of advice as well as an idea of what's going to happen in
> the few weeks.
>
> The deadline for submitting applications is 27 March. Don't wait until the
> last day to submit your proposal! It has happened before that Melange was
> overloaded and unavailable - the Google program admins will not accept that
> as an excuse and allow you to submit later. So as soon as your proposal is
> in good shape, put it in. You can still continue revising it.
>
> From 28 March until 13 April we will continue to interact with you, as we
> request slots from the PSF and rank the proposals. We don't know how many
> slots we will get this year, but to give you an impression: for the last
> two years we got 2 slots. Hopefully we can get more this year, but that's
> far from certain.
>
> Our ranking will be based on a combination of factors: the interaction
> you've had with potential mentors and the community until now (and continue
> to have), the quality of your submitted PRs, quality and projected impact
> of your proposal, your enthusiasm, match with potential mentors, etc. We
> will also organize a video call (Skype / Google Hangout / ...) with each of
> you during the first half of April to be able to exchange ideas with a
> higher communication bandwidth medium than email.
>
> Finally a note on mentoring: we will be able to mentor all proposals
> submitted or suggested until now. Due to the large interest and technical
> nature of a few topics it has in some cases taken a bit long to provide
> feedback on draft proposals, however there are no showstoppers in this
> regard. Please continue improving your proposals and working with your
> potential mentors.
>

Hi all, just a heads up that I'll be offline until next Friday. Good luck
everyone with the last-minute proposal edits. I plan to contact all
students that submitted a GSoC application next weekend with more details
on what will happen next and see when we can schedule a call.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC students: please read

[Ralf Gommers]

On Mon, Mar 23, 2015 at 10:29 PM, Stephan Hoyer  wrote:

> On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers 
> wrote:
>
>> It's great to see that this year there are a lot of students interested
>> in doing a GSoC project with Numpy or Scipy. So far five proposals have
>> been submitted, and it looks like several more are being prepared now.
>>
>
> Hi Ralf,
>
> Is there a centralized place for non-mentors to view proposals and give
> feedback?
>

Hi Stephan, there isn't really. All students post their drafts to the
mailing list, where they can get feedback. They're free to keep that draft
wherever they want - blogs, Github, StackEdit, ftp sites and more are all
being used. The central overview is in Melange (the official GSoC tool),
but that's not publicly accessible.

Note that an overview of project ideas can be found at
https://github.com/scipy/scipy/wiki/GSoC-project-ideas. If you're
particularly interested in one or more of those, it should be easy to find
back in the mailing list archive what students sent draft proposals for
feedback. Your comments on individual proposals will be much appreciated.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC students: please read

[Stephan Hoyer]

On Mon, Mar 23, 2015 at 2:21 PM, Ralf Gommers 
wrote:

> It's great to see that this year there are a lot of students interested in
> doing a GSoC project with Numpy or Scipy. So far five proposals have been
> submitted, and it looks like several more are being prepared now.
>

Hi Ralf,

Is there a centralized place for non-mentors to view proposals and give
feedback?

Thanks,
Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC students: please read

[Ralf Gommers]

Hi all,

It's great to see that this year there are a lot of students interested in
doing a GSoC project with Numpy or Scipy. So far five proposals have been
submitted, and it looks like several more are being prepared now. I'd like
to give you a bit of advice as well as an idea of what's going to happen in
the few weeks.

The deadline for submitting applications is 27 March. Don't wait until the
last day to submit your proposal! It has happened before that Melange was
overloaded and unavailable - the Google program admins will not accept that
as an excuse and allow you to submit later. So as soon as your proposal is
in good shape, put it in. You can still continue revising it.

>From 28 March until 13 April we will continue to interact with you, as we
request slots from the PSF and rank the proposals. We don't know how many
slots we will get this year, but to give you an impression: for the last
two years we got 2 slots. Hopefully we can get more this year, but that's
far from certain.

Our ranking will be based on a combination of factors: the interaction
you've had with potential mentors and the community until now (and continue
to have), the quality of your submitted PRs, quality and projected impact
of your proposal, your enthusiasm, match with potential mentors, etc. We
will also organize a video call (Skype / Google Hangout / ...) with each of
you during the first half of April to be able to exchange ideas with a
higher communication bandwidth medium than email.

Finally a note on mentoring: we will be able to mentor all proposals
submitted or suggested until now. Due to the large interest and technical
nature of a few topics it has in some cases taken a bit long to provide
feedback on draft proposals, however there are no showstoppers in this
regard. Please continue improving your proposals and working with your
potential mentors.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC projects

[Ralf Gommers]

Hi Lulu, welcome!

On Mon, Mar 23, 2015 at 6:09 AM, Lulu Li  wrote:

> My apology if I am posting to the wrong mailing list. I am interested in
> NumPy project ideas for Google Summer of Code 2015 as posted here
> https://github.com/scipy/scipy/wiki/GSoC-project-ideas. In particular,
> knowing C and Python, I am interested in porting parts of bumpy from C to
> Cython or pythonic types. I wonder if these projects are still looking for
> participants? If not I will be excited to put together a proposal and work
> on them these summer.
>

Proposals are still very welcome. There has been some interest in this
particular project idea, but I haven't seen any submitted proposals yet.
And even if there were, you can still submit yours. The deadline is closing
in fast, so you'll have to be quick though. Try to post a first draft asap,
so you can get some feedback and improve your proposal before the 27th.

Also keep in mind that one of the requirements for getting your proposal
accepted is that you have submitted at least one patch to Numpy. This
allows us to interact with you and gives you an idea of how the Numpy
development process works.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC projects

[Lulu Li]

My apology if I am posting to the wrong mailing list. I am interested in
NumPy project ideas for Google Summer of Code 2015 as posted here
https://github.com/scipy/scipy/wiki/GSoC-project-ideas. In particular,
knowing C and Python, I am interested in porting parts of bumpy from C to
Cython or pythonic types. I wonder if these projects are still looking for
participants? If not I will be excited to put together a proposal and work
on them these summer.

Lulu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Sebastian Berg]

On Do, 2015-02-26 at 07:09 -0800, Jaime Fernández del Río wrote:

> 
> 
> To add one of my own: the old iterator is still being used in many,
> many places throughout the numpy code base. Wouldn't it make sense to
> port those to the new one? In doing so, it would probably lead to
> producing simplified interfaces to the new iterator, e.g. reproducing
> the old PyIter_AllButAxis is infinitely more verbose with the new
> iterator.
> 
> 

Might be a bit off topic. But I used to wonder if it could make sense to
create a Cython code generation support for nditer? NDiter is pretty
powerful, but we often have things like the contiguous special case,
buffering, etc. that is always identical code but without having
something ready in cython nobody will ever use nditer from cython, even
though for some things it might make a lot of sense.

- Sebastian


> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Jaime Fernández del Río]

On Thu, Feb 26, 2015 at 2:54 AM, Todd  wrote:

> I am not able to mentor, but I have some ideas about easier projects.
> These may be too easy, too hard, or not even desirable so take them or
> leave them as you please.
>
> scipy:
>
> Implement a set of circular statistics functions comparable to those in R
> or MATLAB circular statistics toolbox.
>
> Either implement some window functions that only apply to the beginning
> and end of an array, or implement a wrapper that takes a window function
> and some parameters and creates a new window that only applies to the
> beginning and end of an array.
>
> numpy:
>
> Integrate the bottleneck project optimizations into numpy proper.
>
> Not sure how much of the bottleneck optimizations can be fitted into the
ufunc machinery. But I'd be more than happy to mentor or co-mentor an
implementation in numpy of the moving window functions. I have already
contributed some work on some of those in scipy.ndimage and pandas, and
find the subject fascinating.

> Integrate as much as possible the matplotlib.mlab functionality into numpy
> (and, optionally, also scipy).
>
> In many places different approaches to the same task have substantially
> different performance (such as indexing vs. take) and check for one
> approach being substantially slower.  If it is, fix the performance problem
> if possible (perhaps by using the same implementation), and if not document
> the difference.
>
The take performance advantage is no longer there since seberg's rewrite of
indexing. Are there any other obvious examples?

> Modify ufuncs so their documentation appears in help() in addition to
> numpy.info().
>
To add one of my own: the old iterator is still being used in many, many
places throughout the numpy code base. Wouldn't it make sense to port those
to the new one? In doing so, it would probably lead to producing simplified
interfaces to the new iterator, e.g. reproducing the old PyIter_AllButAxis
is infinitely more verbose with the new iterator.



> Hi all,
>
>
> On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers 
> wrote:
>
>> Hi all,
>>
>> It's time to start preparing for this year's Google Summer of Code. There
>> is actually one urgent thing to be done (before 19.00 UTC today), which is
>> to get our ideas page in decent shape. It doesn't have to be final, but
>> there has to be enough on there for the organizers to judge it. This page
>> is here: https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
>> reworking it and linking it from the PSF page today, but if you already
>> have new ideas please add them there. See
>> https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate for this
>> year's template for adding a new idea.
>>
>
> The ideas page is now in pretty good shape. More ideas are very welcome
> though, especially easy or easy/intermediate ideas. Numpy right now has
> zero easy ones and Scipy only one and a half.
>
> What we also need is mentors. All ideas already have a potential mentor
> listed, however some ideas are from last year and I'm not sure that all
> those mentors really are available this year. And more than one potential
> mentor per idea is always good. So can everyone please add/remove his or
> her name on that page?
>
> I'm happy to take care of most of the organizational aspects this year,
> however I'll be offline for two weeks in July and from the end of August
> onwards, so I'll some help in those periods. Any volunteers?
>
> Thanks,
> Ralf
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Todd]

I am not able to mentor, but I have some ideas about easier projects.
These may be too easy, too hard, or not even desirable so take them or
leave them as you please.

scipy:

Implement a set of circular statistics functions comparable to those in R
or MATLAB circular statistics toolbox.

Either implement some window functions that only apply to the beginning and
end of an array, or implement a wrapper that takes a window function and
some parameters and creates a new window that only applies to the beginning
and end of an array.

numpy:

Integrate the bottleneck project optimizations into numpy proper.

Integrate as much as possible the matplotlib.mlab functionality into numpy
(and, optionally, also scipy).

In many places different approaches to the same task have substantially
different performance (such as indexing vs. take) and check for one
approach being substantially slower.  If it is, fix the performance problem
if possible (perhaps by using the same implementation), and if not document
the difference.

Modify ufuncs so their documentation appears in help() in addition to
numpy.info().


 Hi all,


On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers 
wrote:

> Hi all,
>
> It's time to start preparing for this year's Google Summer of Code. There
> is actually one urgent thing to be done (before 19.00 UTC today), which is
> to get our ideas page in decent shape. It doesn't have to be final, but
> there has to be enough on there for the organizers to judge it. This page
> is here: https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
> reworking it and linking it from the PSF page today, but if you already
> have new ideas please add them there. See
> https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate for this
> year's template for adding a new idea.
>

The ideas page is now in pretty good shape. More ideas are very welcome
though, especially easy or easy/intermediate ideas. Numpy right now has
zero easy ones and Scipy only one and a half.

What we also need is mentors. All ideas already have a potential mentor
listed, however some ideas are from last year and I'm not sure that all
those mentors really are available this year. And more than one potential
mentor per idea is always good. So can everyone please add/remove his or
her name on that page?

I'm happy to take care of most of the organizational aspects this year,
however I'll be offline for two weeks in July and from the end of August
onwards, so I'll some help in those periods. Any volunteers?

Thanks,
Ralf




___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Nathaniel Smith]

On Feb 25, 2015 12:10 PM, "Charles R Harris" 
wrote:
>
>
>
> On Wed, Feb 25, 2015 at 11:23 AM, Pauli Virtanen  wrote:
>>
>> 25.02.2015, 19:59, Pauli Virtanen kirjoitti:
>> > 25.02.2015, 07:11, Nathaniel Smith kirjoitti:
>> >> Not sure if this is a full GSoC but it would be good to get the
benchmarks
>> >> into the numpy repository, so we can start asking people who submit
>> >> optimizations to submit new benchmarks as part of the PR (just like
other
>> >> changes require tests).
>> >
>> > This may be relevant in this respect:
>> >
>> > https://github.com/scipy/scipy/pull/4501
>>
>> Ok, I didn't read the thread. The vbench benchmarks seem to not be so
>> many and could probably be ported to asv fairly quickly. The bigger job
>> is in setting up and maintaining a host that runs them periodically.
>> Also, asv doesn't (yet) do branches.
>
>
> I would expect a GSOC student to also write some benchmarks. Anyone have
thoughts/ideas on hosting?

One possibility is Rackspace, who seem keen to hand out ~unlimited amounts
of computing resources to FOSS projects. (I think their default is
$10,000/mo/project worth of VMs/storage/etc.) Of course one has to be a bit
careful running benchmarks on virtual hardware...

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Charles R Harris]

On Wed, Feb 25, 2015 at 11:23 AM, Pauli Virtanen  wrote:

> 25.02.2015, 19:59, Pauli Virtanen kirjoitti:
> > 25.02.2015, 07:11, Nathaniel Smith kirjoitti:
> >> Not sure if this is a full GSoC but it would be good to get the
> benchmarks
> >> into the numpy repository, so we can start asking people who submit
> >> optimizations to submit new benchmarks as part of the PR (just like
> other
> >> changes require tests).
> >
> > This may be relevant in this respect:
> >
> > https://github.com/scipy/scipy/pull/4501
>
> Ok, I didn't read the thread. The vbench benchmarks seem to not be so
> many and could probably be ported to asv fairly quickly. The bigger job
> is in setting up and maintaining a host that runs them periodically.
> Also, asv doesn't (yet) do branches.
>

I would expect a GSOC student to also write some benchmarks. Anyone have
thoughts/ideas on hosting?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Pauli Virtanen]

25.02.2015, 19:59, Pauli Virtanen kirjoitti:
> 25.02.2015, 07:11, Nathaniel Smith kirjoitti:
>> Not sure if this is a full GSoC but it would be good to get the benchmarks
>> into the numpy repository, so we can start asking people who submit
>> optimizations to submit new benchmarks as part of the PR (just like other
>> changes require tests).
> 
> This may be relevant in this respect:
> 
> https://github.com/scipy/scipy/pull/4501

Ok, I didn't read the thread. The vbench benchmarks seem to not be so
many and could probably be ported to asv fairly quickly. The bigger job
is in setting up and maintaining a host that runs them periodically.
Also, asv doesn't (yet) do branches.

Pauli

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Pauli Virtanen]

25.02.2015, 07:11, Nathaniel Smith kirjoitti:
> Not sure if this is a full GSoC but it would be good to get the benchmarks
> into the numpy repository, so we can start asking people who submit
> optimizations to submit new benchmarks as part of the PR (just like other
> changes require tests).

This may be relevant in this respect:

https://github.com/scipy/scipy/pull/4501

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Nathaniel Smith]

Not sure if this is a full GSoC but it would be good to get the benchmarks
into the numpy repository, so we can start asking people who submit
optimizations to submit new benchmarks as part of the PR (just like other
changes require tests).
On Feb 24, 2015 10:29 AM, "Charles R Harris" 
wrote:

>
>
> On Tue, Feb 24, 2015 at 10:15 AM, Julian Taylor <
> jtaylor.deb...@googlemail.com> wrote:
>
>> On 02/24/2015 05:41 PM, Charles R Harris wrote:
>> >
>> >
>> > On Mon, Feb 23, 2015 at 11:49 PM, Ralf Gommers > > > wrote:
>> >
>> > Hi all,
>> >
>> >
>> > On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers
>> > mailto:ralf.gomm...@gmail.com>> wrote:
>> >
>> > Hi all,
>> >
>> > It's time to start preparing for this year's Google Summer of
>> > Code. There is actually one urgent thing to be done (before
>> > 19.00 UTC today), which is to get our ideas page in decent
>> > shape. It doesn't have to be final, but there has to be enough
>> > on there for the organizers to judge it. This page is here:
>> > https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
>> > reworking it and linking it from the PSF page today, but if you
>> > already have new ideas please add them there. See
>> > https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate
>> > for this year's template for adding a new idea.
>> >
>> >
>> > The ideas page is now in pretty good shape. More ideas are very
>> > welcome though, especially easy or easy/intermediate ideas. Numpy
>> > right now has zero easy ones and Scipy only one and a half.
>> >
>> >
>> > We could add a benchmark project for numpy that would build off the work
>> > Pauli is doing in Scipy. That would be easy to intermediate I think, as
>> > the programming bits might be easy, but coming up with the benchmarks
>> > would be more difficult.
>> >
>>
>> we already have decent set of benchmarks in yaroslavs setup:
>> http://yarikoptic.github.io/numpy-vbench/
>>
>
> Are you suggesting that we steal copy those (my thought), or
> that we don't need a project? I note that Pauli is using Air Speed Velocity
> instead of vbench.
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Charles R Harris]

On Tue, Feb 24, 2015 at 10:15 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:

> On 02/24/2015 05:41 PM, Charles R Harris wrote:
> >
> >
> > On Mon, Feb 23, 2015 at 11:49 PM, Ralf Gommers  > > wrote:
> >
> > Hi all,
> >
> >
> > On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers
> > mailto:ralf.gomm...@gmail.com>> wrote:
> >
> > Hi all,
> >
> > It's time to start preparing for this year's Google Summer of
> > Code. There is actually one urgent thing to be done (before
> > 19.00 UTC today), which is to get our ideas page in decent
> > shape. It doesn't have to be final, but there has to be enough
> > on there for the organizers to judge it. This page is here:
> > https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
> > reworking it and linking it from the PSF page today, but if you
> > already have new ideas please add them there. See
> > https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate
> > for this year's template for adding a new idea.
> >
> >
> > The ideas page is now in pretty good shape. More ideas are very
> > welcome though, especially easy or easy/intermediate ideas. Numpy
> > right now has zero easy ones and Scipy only one and a half.
> >
> >
> > We could add a benchmark project for numpy that would build off the work
> > Pauli is doing in Scipy. That would be easy to intermediate I think, as
> > the programming bits might be easy, but coming up with the benchmarks
> > would be more difficult.
> >
>
> we already have decent set of benchmarks in yaroslavs setup:
> http://yarikoptic.github.io/numpy-vbench/
>

Are you suggesting that we steal copy those (my thought), or
that we don't need a project? I note that Pauli is using Air Speed Velocity
instead of vbench.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Julian Taylor]

On 02/24/2015 05:41 PM, Charles R Harris wrote:
> 
> 
> On Mon, Feb 23, 2015 at 11:49 PM, Ralf Gommers  > wrote:
> 
> Hi all,
> 
> 
> On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers
> mailto:ralf.gomm...@gmail.com>> wrote:
> 
> Hi all,
> 
> It's time to start preparing for this year's Google Summer of
> Code. There is actually one urgent thing to be done (before
> 19.00 UTC today), which is to get our ideas page in decent
> shape. It doesn't have to be final, but there has to be enough
> on there for the organizers to judge it. This page is here:
> https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
> reworking it and linking it from the PSF page today, but if you
> already have new ideas please add them there. See
> https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate
> for this year's template for adding a new idea.
> 
> 
> The ideas page is now in pretty good shape. More ideas are very
> welcome though, especially easy or easy/intermediate ideas. Numpy
> right now has zero easy ones and Scipy only one and a half.
> 
> 
> We could add a benchmark project for numpy that would build off the work
> Pauli is doing in Scipy. That would be easy to intermediate I think, as
> the programming bits might be easy, but coming up with the benchmarks
> would be more difficult.
> 

we already have decent set of benchmarks in yaroslavs setup:
http://yarikoptic.github.io/numpy-vbench/

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC'15 - mentors & ideas

[Charles R Harris]

On Mon, Feb 23, 2015 at 11:49 PM, Ralf Gommers 
wrote:

> Hi all,
>
>
> On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers 
> wrote:
>
>> Hi all,
>>
>> It's time to start preparing for this year's Google Summer of Code. There
>> is actually one urgent thing to be done (before 19.00 UTC today), which is
>> to get our ideas page in decent shape. It doesn't have to be final, but
>> there has to be enough on there for the organizers to judge it. This page
>> is here: https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
>> reworking it and linking it from the PSF page today, but if you already
>> have new ideas please add them there. See
>> https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate for this
>> year's template for adding a new idea.
>>
>
> The ideas page is now in pretty good shape. More ideas are very welcome
> though, especially easy or easy/intermediate ideas. Numpy right now has
> zero easy ones and Scipy only one and a half.
>

We could add a benchmark project for numpy that would build off the work
Pauli is doing in Scipy. That would be easy to intermediate I think, as the
programming bits might be easy, but coming up with the benchmarks would be
more difficult.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC'15 - mentors & ideas

[Ralf Gommers]

Hi all,


On Fri, Feb 20, 2015 at 10:05 AM, Ralf Gommers 
wrote:

> Hi all,
>
> It's time to start preparing for this year's Google Summer of Code. There
> is actually one urgent thing to be done (before 19.00 UTC today), which is
> to get our ideas page in decent shape. It doesn't have to be final, but
> there has to be enough on there for the organizers to judge it. This page
> is here: https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
> reworking it and linking it from the PSF page today, but if you already
> have new ideas please add them there. See
> https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate for this
> year's template for adding a new idea.
>

The ideas page is now in pretty good shape. More ideas are very welcome
though, especially easy or easy/intermediate ideas. Numpy right now has
zero easy ones and Scipy only one and a half.

What we also need is mentors. All ideas already have a potential mentor
listed, however some ideas are from last year and I'm not sure that all
those mentors really are available this year. And more than one potential
mentor per idea is always good. So can everyone please add/remove his or
her name on that page?

I'm happy to take care of most of the organizational aspects this year,
however I'll be offline for two weeks in July and from the end of August
onwards, so I'll some help in those periods. Any volunteers?

Thanks,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC'15 prep - ideas page

[Ralf Gommers]

Hi all,

It's time to start preparing for this year's Google Summer of Code. There
is actually one urgent thing to be done (before 19.00 UTC today), which is
to get our ideas page in decent shape. It doesn't have to be final, but
there has to be enough on there for the organizers to judge it. This page
is here: https://github.com/scipy/scipy/wiki/GSoC-project-ideas. I'll be
reworking it and linking it from the PSF page today, but if you already
have new ideas please add them there. See
https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate for this
year's template for adding a new idea.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC - what's next

[Charles R Harris]

On Mon, Mar 24, 2014 at 5:34 PM, Ralf Gommers wrote:

> Hi all,
>
> Just a short update, now that the deadline for submitting GSoC proposals
> has passed. We received four proposals:
>
> 1. Leo Mao, "Numpy: Vector Math Library Integration"
> 2. Janani Padmanbhan, "SciPy/NumPy- enhancements in scipy.special (hyp2f1,
> sph_harm) "
> 3. Ankit Agrawal, "SciPy : Discrete Wavelet Transforms and related
> algorithms"
> 4. Richard Tsai, "SciPy: Rewrite and improve cluster package in Cython"
>
> In principle we have enough mentors for all these proposals, although it
> looks like I'll have to chase them a bit to sign up in Melange etc. We're
> going to have to rank these proposals in the next week or so and
> communicate our preferences to the PSF organizers. I'll be in touch with
> all potential mentors about that. The announcement by Google of which
> students were accepted will follow on April 21.
>
> Thanks to the four students who spent a lot of effort on creating solid
> proposals, and to all who helped them by giving feedback. Looks like it's
> going to be a productive summer!
>
>
I signed up to mentor Richard Tsai. I also signed up for Leo Mao, but I
hope Julian Taylor will do the work ;) It is much more his area of
expertise.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC - what's next

[Ralf Gommers]

Hi all,

Just a short update, now that the deadline for submitting GSoC proposals
has passed. We received four proposals:

1. Leo Mao, "Numpy: Vector Math Library Integration"
2. Janani Padmanbhan, "SciPy/NumPy- enhancements in scipy.special (hyp2f1,
sph_harm) "
3. Ankit Agrawal, "SciPy : Discrete Wavelet Transforms and related
algorithms"
4. Richard Tsai, "SciPy: Rewrite and improve cluster package in Cython"

In principle we have enough mentors for all these proposals, although it
looks like I'll have to chase them a bit to sign up in Melange etc. We're
going to have to rank these proposals in the next week or so and
communicate our preferences to the PSF organizers. I'll be in touch with
all potential mentors about that. The announcement by Google of which
students were accepted will follow on April 21.

Thanks to the four students who spent a lot of effort on creating solid
proposals, and to all who helped them by giving feedback. Looks like it's
going to be a productive summer!

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Julian Taylor]

On 12.03.2014 17:52, Leo Mao wrote:
> Hi,
> The attachment is my draft of proposal. The project is "vector math
> library integration".
> I think I need some feedback to make it solider.
> Any comment will be appreciated.
> Thanks in advance.
> 

hi,
I finally had some time too properly look at your proposal, here are my
comments.

First of all I hope you are aware this is a very challenging project as
you will have to deal with issues of several different areas: build
systems, portability, low level performance, numerical issues, testing
and the in some places quite daunting numpy codebase.
I do fear that it might be too much for a first year student.

Your proposal is lacking some information on your experiences. Are you
already familiar with vectorization via SIMD? While the goal of this
project is partly to avoid writing more vector code in NumPy it is still
very useful if you are familiar with how it works.
If you have no experience maybe add some time to learning the basics to
the schedule.

The numerical accuracy of the vector library needs to be evaluated, I
suspect that this might be the biggest roadblock in adding support by
default. The performance of the library over different value ranges also
needs to investigated.

What kind of hardware do you have at your disposal?
SIMD vectorization performance is very hardware dependent, you probably
want at least a intel sandy bridge or AMD bulldozer type cpu to get the
most out of the library, those CPUs have the newish AVX SIMD instructions.


While I think your schedule is already packed, another point you could
add if you have extra time is extending the existing SSE vectorized code
in numpy to AVX if the vector library does not provide an equivalent
(e.g. probably the boolean stuff)
The runtime feature detection vector libraries provide can be very
useful for this.

Regards,
Julian Taylor
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

Because of the license problem, I think I will choose Yeppp as a default
backend.
And if time allows, maybe I can implement other bindings. (Vc library)

Also I found that sleef library is in public domain. But it seems that it
only provides fast math function,
 not "vectorized math function". So I am not sure if it can be used in this
project.

Finally, if there are any suggestions for my proposal, please point out.
I will appreciate your suggestions.

Thanks.

Regards,
Leo Mao
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Robert Kern]

On Fri, Mar 14, 2014 at 7:42 PM, Julian Taylor
 wrote:
> On 14.03.2014 17:40, Robert Kern wrote:
>> On Fri, Mar 14, 2014 at 4:33 PM, Leo Mao  wrote:
>>
>>> Yeppp is bsd 3 clauses so I think Yeppp is really a good choice.
>>> Is there a list of licenses which can be added into numpy without pain? (how
>>> about LGPL3 ?)
>>
>> No, just BSD and its rough equivalents like the Expat license.
>
> They can't be added into numpy, but support linking or building against
> a non-bsd like library can still be added.
> Only our binary distributions are limited in what we can use.

Optionally, yes.

-- 
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Julian Taylor]

On 14.03.2014 17:40, Robert Kern wrote:
> On Fri, Mar 14, 2014 at 4:33 PM, Leo Mao  wrote:
> 
>> Yeppp is bsd 3 clauses so I think Yeppp is really a good choice.
>> Is there a list of licenses which can be added into numpy without pain? (how
>> about LGPL3 ?)
> 
> No, just BSD and its rough equivalents like the Expat license.
> 

They can't be added into numpy, but support linking or building against
a non-bsd like library can still be added.
Only our binary distributions are limited in what we can use.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Robert Kern]

On Fri, Mar 14, 2014 at 4:33 PM, Leo Mao  wrote:

> Yeppp is bsd 3 clauses so I think Yeppp is really a good choice.
> Is there a list of licenses which can be added into numpy without pain? (how
> about LGPL3 ?)

No, just BSD and its rough equivalents like the Expat license.

-- 
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

Hi everyone,

Thanks for your relies!
I think Gregor's uvml package is really a good starting point for me.

 I think the actual choice of the library could be made a configurable
> option.
>

Sounds like a good idea? If the implementations are very similar, maybe I
can implement multiple libraries bindings?
A potential issue is that some libraries may lack some functions.
For example, Yeppp is a good candidates as long as it provides pre-build
libraries on many platforms and its API is pretty clear.
But Yeppp lacks some functions like inverse trigonometric functions.
Intels VML provides much more functions but sadly it is not free.

I found another library called Vc, which looks like a potential candidates
for this project:
http://code.compeng.uni-frankfurt.de/projects/vc
I haven't digged into it yet so I'm not sure if it provides what we want.

supporting a library that is bsd 3 clauses could help
> to higly reduce the compilation problem like what we have with blas.
>

Yeppp is bsd 3 clauses so I think Yeppp is really a good choice.
Is there a list of licenses which can be added into numpy without pain?
(how about LGPL3 ?)

Regards,
Leo Mao


On Fri, Mar 14, 2014 at 9:20 PM, Frédéric Bastien  wrote:

> Just a comment, supporting a library that is bsd 3 clauses could help
> to higly reduce the compilation problem like what we have with blas.
> We could just include it in numpy/download it automatically or
> whatever to make the install trivial and then we could suppose all
> users have it. Deadling with blas is already not fun, if new
> dependency could be trivial to link to, it would be great.
>
> Fred
>
> On Fri, Mar 14, 2014 at 8:57 AM, Gregor Thalhammer
>  wrote:
> >
> > Am 14.03.2014 um 11:00 schrieb Eric Moore :
> >
> >
> >
> > On Friday, March 14, 2014, Gregor Thalhammer <
> gregor.thalham...@gmail.com>
> > wrote:
> >>
> >>
> >> Am 13.03.2014 um 18:35 schrieb Leo Mao :
> >>
> >> > Hi,
> >> >
> >> > Thanks a lot for your advice, Chuck.
> >> > Following your advice, I have modified my draft of proposal.
> >> > (attachment)
> >> > I think it still needs more comments so that I can make it better.
> >> >
> >> > And I found that maybe I can also make some functions related to
> linalg
> >> > (like dot, svd or something else) faster by integrating a proper
> library
> >> > into numpy.
> >> >
> >> > Regards,
> >> > Leo Mao
> >> >
> >> Dear Leo,
> >>
> >> large parts of your proposal are covered by the uvml package
> >> https://github.com/geggo/uvml
> >> In my opinion you should also consider Intels VML (part of MKL) as a
> >> candidate. (Yes I know, it is not free). To my best knowledge it
> provides
> >> many more vectorized functions than the open source alternatives.
> >> Concerning your time table, once you implemented support for one
> function,
> >> adding more functions is very easy.
> >>
> >> Gregor
> >>
> >
> > I'm not sure that your week old project is enough to discourage this gsoc
> > project. In particular, it would be nice to be able to ship this
> directly as
> > part of numpy and that won't really be possible with mlk.
> >
> > Eric
> >
> >
> >
> > Hi,
> >
> > it's not at all my intention to discourage this project. I hope Leo Mao
> can
> > use the uvml package as a starting point for further improvements. Since
> > most vectorized math libraries share a very similar interface, I think
> the
> > actual choice of the library could be made a configurable option.
> Adapting
> > uvml to use e.g. yeppp instead of MKL should be straightforward. Similar
> to
> > numpy or scipy built with MKL lapack and distributed by enthought or
> > Christoph Gohlke, using MKL should not be ruled out completely.
> >
> > Gregor
> >
> >
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Frédéric Bastien]

Just a comment, supporting a library that is bsd 3 clauses could help
to higly reduce the compilation problem like what we have with blas.
We could just include it in numpy/download it automatically or
whatever to make the install trivial and then we could suppose all
users have it. Deadling with blas is already not fun, if new
dependency could be trivial to link to, it would be great.

Fred

On Fri, Mar 14, 2014 at 8:57 AM, Gregor Thalhammer
 wrote:
>
> Am 14.03.2014 um 11:00 schrieb Eric Moore :
>
>
>
> On Friday, March 14, 2014, Gregor Thalhammer 
> wrote:
>>
>>
>> Am 13.03.2014 um 18:35 schrieb Leo Mao :
>>
>> > Hi,
>> >
>> > Thanks a lot for your advice, Chuck.
>> > Following your advice, I have modified my draft of proposal.
>> > (attachment)
>> > I think it still needs more comments so that I can make it better.
>> >
>> > And I found that maybe I can also make some functions related to linalg
>> > (like dot, svd or something else) faster by integrating a proper library
>> > into numpy.
>> >
>> > Regards,
>> > Leo Mao
>> >
>> Dear Leo,
>>
>> large parts of your proposal are covered by the uvml package
>> https://github.com/geggo/uvml
>> In my opinion you should also consider Intels VML (part of MKL) as a
>> candidate. (Yes I know, it is not free). To my best knowledge it provides
>> many more vectorized functions than the open source alternatives.
>> Concerning your time table, once you implemented support for one function,
>> adding more functions is very easy.
>>
>> Gregor
>>
>
> I'm not sure that your week old project is enough to discourage this gsoc
> project. In particular, it would be nice to be able to ship this directly as
> part of numpy and that won't really be possible with mlk.
>
> Eric
>
>
>
> Hi,
>
> it's not at all my intention to discourage this project. I hope Leo Mao can
> use the uvml package as a starting point for further improvements. Since
> most vectorized math libraries share a very similar interface, I think the
> actual choice of the library could be made a configurable option. Adapting
> uvml to use e.g. yeppp instead of MKL should be straightforward. Similar to
> numpy or scipy built with MKL lapack and distributed by enthought or
> Christoph Gohlke, using MKL should not be ruled out completely.
>
> Gregor
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Gregor Thalhammer]

Am 14.03.2014 um 11:00 schrieb Eric Moore :

> 
> 
> On Friday, March 14, 2014, Gregor Thalhammer  
> wrote:
> 
> Am 13.03.2014 um 18:35 schrieb Leo Mao :
> 
> > Hi,
> >
> > Thanks a lot for your advice, Chuck.
> > Following your advice, I have modified my draft of proposal. (attachment)
> > I think it still needs more comments so that I can make it better.
> >
> > And I found that maybe I can also make some functions related to linalg 
> > (like dot, svd or something else) faster by integrating a proper library 
> > into numpy.
> >
> > Regards,
> > Leo Mao
> >
> Dear Leo,
> 
> large parts of your proposal are covered by the uvml package
> https://github.com/geggo/uvml
> In my opinion you should also consider Intels VML (part of MKL) as a 
> candidate. (Yes I know, it is not free). To my best knowledge it provides 
> many more vectorized functions than the open source alternatives.
> Concerning your time table, once you implemented support for one function, 
> adding more functions is very easy.
> 
> Gregor
> 
> 
> I'm not sure that your week old project is enough to discourage this gsoc 
> project. In particular, it would be nice to be able to ship this directly as 
> part of numpy and that won't really be possible with mlk.
> 
> Eric 
>  

Hi,

it's not at all my intention to discourage this project. I hope Leo Mao can use 
the uvml package as a starting point for further improvements. Since most 
vectorized math libraries share a very similar interface, I think the actual 
choice of the library could be made a configurable option. Adapting uvml to use 
e.g. yeppp instead of MKL should be straightforward. Similar to numpy or scipy 
built with MKL lapack and distributed by enthought or Christoph Gohlke, using 
MKL should not be ruled out completely.

Gregor




___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Eric Moore]

On Friday, March 14, 2014, Gregor Thalhammer 
wrote:

>
> Am 13.03.2014 um 18:35 schrieb Leo Mao 
> >:
>
> > Hi,
> >
> > Thanks a lot for your advice, Chuck.
> > Following your advice, I have modified my draft of proposal. (attachment)
> > I think it still needs more comments so that I can make it better.
> >
> > And I found that maybe I can also make some functions related to linalg
> (like dot, svd or something else) faster by integrating a proper library
> into numpy.
> >
> > Regards,
> > Leo Mao
> >
> Dear Leo,
>
> large parts of your proposal are covered by the uvml package
> https://github.com/geggo/uvml
> In my opinion you should also consider Intels VML (part of MKL) as a
> candidate. (Yes I know, it is not free). To my best knowledge it provides
> many more vectorized functions than the open source alternatives.
> Concerning your time table, once you implemented support for one function,
> adding more functions is very easy.
>
> Gregor
>
>
I'm not sure that your week old project is enough to discourage this gsoc
project. In particular, it would be nice to be able to ship this directly
as part of numpy and that won't really be possible with mlk.

Eric


> __
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org 
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Gregor Thalhammer]

Am 13.03.2014 um 18:35 schrieb Leo Mao :

> Hi,
> 
> Thanks a lot for your advice, Chuck.
> Following your advice, I have modified my draft of proposal. (attachment)
> I think it still needs more comments so that I can make it better.
> 
> And I found that maybe I can also make some functions related to linalg (like 
> dot, svd or something else) faster by integrating a proper library into numpy.
> 
> Regards,
> Leo Mao
> 
Dear Leo,

large parts of your proposal are covered by the uvml package 
https://github.com/geggo/uvml
In my opinion you should also consider Intels VML (part of MKL) as a candidate. 
(Yes I know, it is not free). To my best knowledge it provides many more 
vectorized functions than the open source alternatives. 
Concerning your time table, once you implemented support for one function, 
adding more functions is very easy. 

Gregor

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

On Fri, Mar 14, 2014 at 1:43 AM, alex  wrote:
>
> I think everyone who wants fast numpy linalg already connects to
> something like OpenBLAS or MKL.  When these are not available, numpy
> uses its own "lapack-lite" which is way slower.  I don't think you are
> going to beat OpenBLAS, so are you suggesting to speed up the slow
> default "lapack-lite", or are you proposing something else?
>

I think most CPUs nowadays support instructions like SSE2, AVX etc,
so maybe numpy can use OpenBLAS (or somethine else) by default ?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[alex]

On Thu, Mar 13, 2014 at 1:35 PM, Leo Mao  wrote:
>>
> And I found that maybe I can also make some functions related to linalg
> (like dot, svd or something else) faster by integrating a proper library
> into numpy.

I think everyone who wants fast numpy linalg already connects to
something like OpenBLAS or MKL.  When these are not available, numpy
uses its own "lapack-lite" which is way slower.  I don't think you are
going to beat OpenBLAS, so are you suggesting to speed up the slow
default "lapack-lite", or are you proposing something else?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

Hi,

Thanks a lot for your advice, Chuck.
Following your advice, I have modified my draft of proposal. (attachment)
I think it still needs more comments so that I can make it better.

And I found that maybe I can also make some functions related to linalg
(like dot, svd or something else) faster by integrating a proper library
into numpy.

Regards,
Leo Mao



On Thu, Mar 13, 2014 at 3:09 AM, Charles R Harris  wrote:

>
>
>
> On Wed, Mar 12, 2014 at 11:12 AM, Leo Mao  wrote:
>
>> Hi Aron,
>>
>> Previously mentioned by Julian, Yeppp may be a good candidate.
>> As for selecting a good library, I will consider the performance and the
>> API of the library.
>> The integration of the library should improve the performance of numpy
>> and also not make the source too complicated to maintain.
>> And I think the library should be mature so that the API will not be
>> changed significantly.
>>
>> Please point out if there is something I miss.
>> Also I will be grateful to any suggestions for my proposal.
>>
>> Regards,
>> Leo Mao
>>
>>
>> On Thu, Mar 13, 2014 at 12:54 AM, Aron Ahmadia  wrote:
>>
>>> Hi Leo,
>>>
>>> Out of curiosity, which vector math libraries did you have in mind as
>>> likely candidates for inclusion?  How are you planning on selecting the
>>> library to integrate?
>>>
>>> Cheers,
>>> Aron
>>>
>>>
>>> On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao  wrote:
>>>
 Hi,
 The attachment is my draft of proposal. The project is "vector math
 library integration".
 I think I need some feedback to make it solider.
 Any comment will be appreciated.
 Thanks in advance.

 Regards,
 Leo Mao


> The proposal as it stands is too open ended and lacking in specifics.
> Probably you should select a library before the start of GSOC, or at least
> have a list of candidates, and also narrow the part of numpy you want to
> improve to something definite: linalg, special functions, etc. That doesn't
> mean you can't do more if time allows ;) An estimate of expected gains over
> current code would also help.
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
<<< text/html; charset=US-ASCII; name="proposal.html": Unrecognized >>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC application template available

[Ralf Gommers]

On Mon, Mar 10, 2014 at 10:45 PM, Ralf Gommers wrote:

> Hi GSoC students,
>
> The PSF just made their application template for this year available:
> https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2014. There
> are a few things in there that are required (for one, submit a patch to
> numpy or scipy if you haven't done so yet), and some good recommendations.
>

Also a heads up that Google has changes the process a bit; you'll be
required to provide proof that you're a student now instead of later on.
Apparently this slows down the initial part of the application, so it's
even more important that you submit your (draft) proposals early on. Note
that you can keep on editing in Melange until the deadline.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Charles R Harris]

On Wed, Mar 12, 2014 at 11:12 AM, Leo Mao  wrote:

> Hi Aron,
>
> Previously mentioned by Julian, Yeppp may be a good candidate.
> As for selecting a good library, I will consider the performance and the
> API of the library.
> The integration of the library should improve the performance of numpy and
> also not make the source too complicated to maintain.
> And I think the library should be mature so that the API will not be
> changed significantly.
>
> Please point out if there is something I miss.
> Also I will be grateful to any suggestions for my proposal.
>
> Regards,
> Leo Mao
>
>
> On Thu, Mar 13, 2014 at 12:54 AM, Aron Ahmadia  wrote:
>
>> Hi Leo,
>>
>> Out of curiosity, which vector math libraries did you have in mind as
>> likely candidates for inclusion?  How are you planning on selecting the
>> library to integrate?
>>
>> Cheers,
>> Aron
>>
>>
>> On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao  wrote:
>>
>>> Hi,
>>> The attachment is my draft of proposal. The project is "vector math
>>> library integration".
>>> I think I need some feedback to make it solider.
>>> Any comment will be appreciated.
>>> Thanks in advance.
>>>
>>> Regards,
>>> Leo Mao
>>>
>>>
The proposal as it stands is too open ended and lacking in specifics.
Probably you should select a library before the start of GSOC, or at least
have a list of candidates, and also narrow the part of numpy you want to
improve to something definite: linalg, special functions, etc. That doesn't
mean you can't do more if time allows ;) An estimate of expected gains over
current code would also help.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

Hi Aron,

Previously mentioned by Julian, Yeppp may be a good candidate.
As for selecting a good library, I will consider the performance and the
API of the library.
The integration of the library should improve the performance of numpy and
also not make the source too complicated to maintain.
And I think the library should be mature so that the API will not be
changed significantly.

Please point out if there is something I miss.
Also I will be grateful to any suggestions for my proposal.

Regards,
Leo Mao


On Thu, Mar 13, 2014 at 12:54 AM, Aron Ahmadia  wrote:

> Hi Leo,
>
> Out of curiosity, which vector math libraries did you have in mind as
> likely candidates for inclusion?  How are you planning on selecting the
> library to integrate?
>
> Cheers,
> Aron
>
>
> On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao  wrote:
>
>> Hi,
>> The attachment is my draft of proposal. The project is "vector math
>> library integration".
>> I think I need some feedback to make it solider.
>> Any comment will be appreciated.
>> Thanks in advance.
>>
>> Regards,
>> Leo Mao
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC project: draft of proposal

[Aron Ahmadia]

Hi Leo,

Out of curiosity, which vector math libraries did you have in mind as
likely candidates for inclusion?  How are you planning on selecting the
library to integrate?

Cheers,
Aron


On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao  wrote:

> Hi,
> The attachment is my draft of proposal. The project is "vector math
> library integration".
> I think I need some feedback to make it solider.
> Any comment will be appreciated.
> Thanks in advance.
>
> Regards,
> Leo Mao
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC project: draft of proposal

[Leo Mao]

Hi,
The attachment is my draft of proposal. The project is "vector math library
integration".
I think I need some feedback to make it solider.
Any comment will be appreciated.
Thanks in advance.

Regards,
Leo Mao
<<< text/html; charset=US-ASCII; name="proposal.html": Unrecognized >>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC application template available

[Ralf Gommers]

Hi GSoC students,

The PSF just made their application template for this year available:
https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2014. There
are a few things in there that are required (for one, submit a patch to
numpy or scipy if you haven't done so yet), and some good recommendations.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC: ideas & finding mentors

[Ralf Gommers]

Hi students,

There is quite a bit of interest in GSoC ideas for Scipy and Numpy, which
is great to see. The official application period to submit proposals opens
next week and closes on the 21st, which is in two weeks and a bit. So now
is the time to start discussing draft proposals on the list.

There have been a few ideas posted on the list which haven't gotten enough
feedback yet (FFTs, cluster, ODEs). This may reflect the lack of an active
maintainer of those modules, so it will be harder to find a suitable
mentor. I want to point out that this is also a chicken-and-egg problem: if
you're actively posting and improving your draft and sending some pull
requests to fix some small issues, it shows both your willingness to work
with the community and how you work with core devs to get your PRs merged,
which helps find an interested mentor.

To tackle the student-mentor matchmaking from another angle, I've added on
https://github.com/scipy/scipy/wiki/GSoC-project-ideas a "potential
mentors" field to the idea I know the names for (Stefan and me, for
wavelets). If other potential mentors could do the same for other ideas,
that would be very helpful. I can take some guesses (Pauli, Evgeni for
splines? Chuck, Chris Barker for datetime?) but I haven't added any names.
So please do add your name, keeping in mind that this is to get the process
going and not yet a full commitment.

Final note: you don't necessarily have to be a core developer to be a
co-mentor. If you're an expert on a topic that a student is interested in
and would like to see that project happen, please indicate you're willing
to help.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2014 NumPy

[Ralf Gommers]

On Wed, Mar 5, 2014 at 5:52 PM, Leo Mao  wrote:

> On Tue, Mar 4, 2014 at 5:42 AM, Ralf Gommers wrote:
>
>>
>> It's possible to come up with an interesting proposal in this area I
>> think. An issue may be that the FFT code in numpy and scipy isn't very
>> actively worked on at the moment, so finding a suitable mentor could be
>> tricky.
>>
>
> So should I choose another topic?
>

I suspect that that may be better.


> Actually, I just read the thread "numpy gsoc topic idea" and I found that
> the idea "vector math library integration" really interests me!
>

If it's interesting, I suggest to dive in. It's Julian's idea, so probably
he's interested to (co-)mentor a project on this topic. Julian?


> And I have a qeustion: how can I find a suitable mentor?
>

That's a nontrivial question. Let me send a separate email to the list
about that.


> Currently I'm digging into the source of numpy and trying to make a small
> pull request. Also I keep thinking how to write a proper proposal.
> Are these enough? Can I do more for now?
>

Keep in mind that your proposal will need to go through a few rounds of
feedback and rework before it's solid enough that you can submit it. The
same usually goes for pull requests.

Cheers,
Ralf


> I will be grateful for any advice.
> Thanks in advance.
>
> Regards,
> Leo Mao
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2014 NumPy

[Leo Mao]

On Tue, Mar 4, 2014 at 5:42 AM, Ralf Gommers  wrote:

>
> It's possible to come up with an interesting proposal in this area I
> think. An issue may be that the FFT code in numpy and scipy isn't very
> actively worked on at the moment, so finding a suitable mentor could be
> tricky.
>

So should I choose another topic? Actually, I just read the thread "numpy
gsoc topic idea" and I found that the idea "vector math library
integration" really interests me!

And I have a qeustion: how can I find a suitable mentor?

Currently I'm digging into the source of numpy and trying to make a small
pull request. Also I keep thinking how to write a proper proposal.
Are these enough? Can I do more for now?

I will be grateful for any advice.
Thanks in advance.

Regards,
Leo Mao
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2014 NumPy

[Ralf Gommers]

On Sun, Mar 2, 2014 at 5:12 AM, Leo Mao  wrote:

> Hello Ray,
> Thanks for your suggestion! I just read the links you provided and I think
> I can implement it as long as I do further research on zoom fft algorithm.
> So I wonder if this can be a GSoC project?
>

By itself that's not enough for a GSoC project.


> Maybe I should extend this idea or combine it with other ideas?
>

It's possible to come up with an interesting proposal in this area I think.
An issue may be that the FFT code in numpy and scipy isn't very actively
worked on at the moment, so finding a suitable mentor could be tricky.


> BTW, just for curiosity, why we need both scipy.linalg and numpy.linalg?
> Is implementing all functions in numpy a bad idea?
>

The overlap is mostly due to historical reasons. The long-term plan is to
remove duplicate functions from scipy.linalg.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC 2014 : "Improve Numpy datetime functionality"

[Ralf Gommers]

On Mon, Mar 3, 2014 at 6:38 PM, Chris Barker  wrote:

> On Sat, Mar 1, 2014 at 6:42 AM, faisal anees <
> mohammedfaisal.an...@students.iiit.ac.in> wrote:
>
>> I am Mohammed Faisal Anees , a Computer Science student at IIIT-
>> Hyderabad. I was going though the ideas page and I found "Improve Numpy
>> datetime functionality" really interesting ,
>>
>
> It's great to have the interest!
>
> One trick is that I dont hink there is a consensus on what needs to be
> done to "improve datetime".
>
> One thing that does need to be done is cleaning up time zone handling --
> and I think we ALMOST have consensus on how to do that (at least the quick
> fix part).
>
> Take a look for threads on this list in the last year about "datetime64"
> and this ticket:
>
> https://github.com/numpy/numpy/issues/3388
>
> (and search for other datetime64 tickets...)
>
> Note that we are hoping to fix that for 1.9 -- anyone have a time scale
> for that? Too soon for GSoC?
>

Yes too soon and no, unlikely to happen given that no one volunteered yet.
So seeing a solid GSoC proposal would be good.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC 2014 : "Improve Numpy datetime functionality"

[Chris Barker]

On Sat, Mar 1, 2014 at 6:42 AM, faisal anees <
mohammedfaisal.an...@students.iiit.ac.in> wrote:

> I am Mohammed Faisal Anees , a Computer Science student at IIIT-
> Hyderabad. I was going though the ideas page and I found "Improve Numpy
> datetime functionality" really interesting ,
>

It's great to have the interest!

One trick is that I dont hink there is a consensus on what needs to be done
to "improve datetime".

One thing that does need to be done is cleaning up time zone handling --
and I think we ALMOST have consensus on how to do that (at least the quick
fix part).

Take a look for threads on this list in the last year about "datetime64"
and this ticket:

https://github.com/numpy/numpy/issues/3388

(and search for other datetime64 tickets...)

Note that we are hoping to fix that for 1.9 -- anyone have a time scale for
that? Too soon for GSoC?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2014 NumPy

[Leo Mao]

Hello Ray,
Thanks for your suggestion! I just read the links you provided and I think
I can implement it as long as I do further research on zoom fft algorithm.
So I wonder if this can be a GSoC project?
Maybe I should extend this idea or combine it with other ideas?

BTW, just for curiosity, why we need both scipy.linalg and numpy.linalg? Is
implementing all functions in numpy a bad idea?

Regards,
Leo Mao
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC 2014 NumPy

[RayS]

At 04:42 AM 3/1/2014, you wrote:
>Currently I am trying to come up with some ideas about enhancing NumPy.

Hello Leo,

How about you implement fft.zoom_fft() as a single function? (Not to 
be confused with chirp-Z)
We might be able to lend some ideas, but I've never been satisfied with mine:
http://mail.scipy.org/pipermail/numpy-discussion/2007-March/026529.html
and Matlab
https://www.mathworks.com/matlabcentral/newsreader/view_thread/85241
http://www.numerix-dsp.com/zoomfft.html
http://www.ee.ic.ac.uk/hp/staff/dmb/voicebox/doc/voicebox/zoomfft.html

- Ray S 

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSOC 2014 : "Improve Numpy datetime functionality"

[faisal anees]

Hi ,

I am Mohammed Faisal Anees , a Computer Science student at IIIT- Hyderabad.
I was going though the ideas page and I found "Improve Numpy datetime
functionality" really interesting , and it suits my experience as I have a
considerable(hopefully !!) amount of experience in C/C++, and Python .
Right now I am going through the link suggested by you and the codebase.

Thanks
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSoC 2014 NumPy

[Leo Mao]

Hello,
I'm a student studying electrical engineering.  I am interested in
contributing to NumPy and applying GSoC 2014.
I have experience of python and C/C++ programming, and I have already seen
https://github.com/scipy/scipy/wiki/GSoC-project-ideas.
But on that page only the project "Improve Numpy datetime functionality"
targets NumPy.
Currently I am trying to come up with some ideas about enhancing NumPy.
I will be grateful if someone could give me some ideas or guide me as how
to do next.
BTW, I am looking into the issue list of NumPy on github and trying to make
some small bugfixes/enhancement for NumPy.
Thanks in advance.

Regards:
Leo Mao,
student in National Taiwan University,
Email: lmao20...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Pauli Virtanen]

23.02.2014 11:30, Ralf Gommers kirjoitti:
[clip]
> 1. fix up ideas page with scipy/numpy descriptions, idea difficulty levels
> and preferably some more ideas.

Here's a start:

https://github.com/scipy/scipy/wiki/GSoC-project-ideas



___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Ralf Gommers]

On Sun, Feb 23, 2014 at 10:44 AM, Sebastian Berg  wrote:

> On So, 2014-02-23 at 10:30 +0100, Ralf Gommers wrote:
> >
> >
> >
> > On Fri, Feb 21, 2014 at 5:17 PM, Charles R Harris
> >  wrote:
> >
> >
> >
> > On Fri, Feb 21, 2014 at 1:18 AM, Jennifer stone
> >  wrote:
> > https://wiki.python.org/moin/SummerOfCode/2014
> > The link provided by Josef is yet to list SciPy/NumPy
> > under it. Somebody please contact Terri.
> > That page acts as major guiding factor for Python-GSoC
> > prospective students. Please have SciPy listed there.
> >
> >
> >
> >
> > Ralph, do you know if there is there someone representing
> > Scipy/Numpy who is officially supposed to handle this, or
> > should I take a shot at it?
> >
> >
> >
> > Last year I did that, but we don't really have an official role within
> > the project for that. I had intended to do it within the deadline, but
> > that happened to coincide with me traveling without network
> > connection. Sorry about the delay. Should be fixable though, last year
> > we were way later.
> >
> >
> > Todo is now:
> >
> > 1. fix up ideas page with scipy/numpy descriptions, idea difficulty
> > levels and preferably some more ideas.
> >
>
> Considering that little has been moving there, the datetime cleanup
> might be a decent project[1]? But to be honest, I have no idea if the
> work load fits at all or how much work fixing this should be anyway.
>

+1 would be very good to get that moving. Should fit in a GSoC, but the
difficulty should be set to high. That's true for most numpy ideas though;
scipy can offer a wider range of difficulty levels.

Ralf



>
> - Sebastian
>
> [1] I know, everyone wants to see it fixed in 1.9. and that would be
> better...
>
> > 2. add scipy/numpy to PSF page
> >
> > 3. contact PSF admins
> >
> >
> > I can get around to doing this today. (1) is probably the most work,
> > if you could help out that would be great.
> >
> >
> > Ralf
> >
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Sebastian Berg]

On So, 2014-02-23 at 10:30 +0100, Ralf Gommers wrote:
> 
> 
> 
> On Fri, Feb 21, 2014 at 5:17 PM, Charles R Harris
>  wrote:
> 
> 
> 
> On Fri, Feb 21, 2014 at 1:18 AM, Jennifer stone
>  wrote:
> https://wiki.python.org/moin/SummerOfCode/2014
> The link provided by Josef is yet to list SciPy/NumPy
> under it. Somebody please contact Terri.
> That page acts as major guiding factor for Python-GSoC
> prospective students. Please have SciPy listed there.
>  
> 
> 
> 
> Ralph, do you know if there is there someone representing
> Scipy/Numpy who is officially supposed to handle this, or
> should I take a shot at it?
> 
> 
> 
> Last year I did that, but we don't really have an official role within
> the project for that. I had intended to do it within the deadline, but
> that happened to coincide with me traveling without network
> connection. Sorry about the delay. Should be fixable though, last year
> we were way later.
> 
> 
> Todo is now:
> 
> 1. fix up ideas page with scipy/numpy descriptions, idea difficulty
> levels and preferably some more ideas. 
> 

Considering that little has been moving there, the datetime cleanup
might be a decent project[1]? But to be honest, I have no idea if the
work load fits at all or how much work fixing this should be anyway.

- Sebastian

[1] I know, everyone wants to see it fixed in 1.9. and that would be
better...

> 2. add scipy/numpy to PSF page
> 
> 3. contact PSF admins
> 
> 
> I can get around to doing this today. (1) is probably the most work,
> if you could help out that would be great.
> 
> 
> Ralf
> 
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Ralf Gommers]

On Fri, Feb 21, 2014 at 5:17 PM, Charles R Harris  wrote:

>
>
>
> On Fri, Feb 21, 2014 at 1:18 AM, Jennifer stone 
> wrote:
>
>> https://wiki.python.org/moin/SummerOfCode/2014
>> The link provided by Josef is yet to list SciPy/NumPy under it. Somebody
>> please contact Terri.
>> That page acts as major guiding factor for Python-GSoC prospective
>> students. Please have SciPy listed there.
>>
>>
> Ralph, do you know if there is there someone representing Scipy/Numpy who
> is officially supposed to handle this, or should I take a shot at it?
>

Last year I did that, but we don't really have an official role within the
project for that. I had intended to do it within the deadline, but that
happened to coincide with me traveling without network connection. Sorry
about the delay. Should be fixable though, last year we were way later.

Todo is now:
1. fix up ideas page with scipy/numpy descriptions, idea difficulty levels
and preferably some more ideas.
2. add scipy/numpy to PSF page
3. contact PSF admins

I can get around to doing this today. (1) is probably the most work, if you
could help out that would be great.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Charles R Harris]

On Fri, Feb 21, 2014 at 1:18 AM, Jennifer stone wrote:

> https://wiki.python.org/moin/SummerOfCode/2014
> The link provided by Josef is yet to list SciPy/NumPy under it. Somebody
> please contact Terri.
> That page acts as major guiding factor for Python-GSoC prospective
> students. Please have SciPy listed there.
>
>
Ralph, do you know if there is there someone representing Scipy/Numpy who
is officially supposed to handle this, or should I take a shot at it?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Jennifer stone]

https://wiki.python.org/moin/SummerOfCode/2014
The link provided by Josef is yet to list SciPy/NumPy under it. Somebody
please contact Terri.
That page acts as major guiding factor for Python-GSoC prospective
students. Please have SciPy listed there.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[josef . pktd]

On Thu, Feb 13, 2014 at 2:44 PM, Pauli Virtanen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 13.02.2014 20:59, josef.p...@gmail.com kirjoitti:
> [clip]
>> I assume numpy/scipy will participate under the PSF umbrella. So
>> this deadline is for the PSF. However, Terri, the organizer for the
>> PSF, asked for links to Ideas pages to be able to show Google what
>> interesting projects the PSF has.
>
> Here's a shot at that (stolen from roadmap etc):
>
> https://github.com/scipy/scipy/wiki/GSoC-project-ideas
>
> Please update as you see fit.
>
> Did we count the number of prospective mentors >= 3? Scipy is not yet
> listed on the PSF GSoC 2014 project list, so I think if we are going
> to participate, we should let them know.

It should be possible to edit the python wiki
https://wiki.python.org/moin/SummerOfCode/2014

Terri phrased it so that it means that projects should add the links.

The decision which projects will participate under the PSF will be
later, if it's the same pattern as in previous years.

Josef

>
> Best,
> Pauli
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iEYEARECAAYFAlL9IJoACgkQ6BQxb7O0pWALNwCgy0YwyTBxuaD+As3lOiAlp0/A
> 3ZcAnR4VCb9rjQ0WE/JDbfpWPxbAj76W
> =iYXB
> -END PGP SIGNATURE-
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Pauli Virtanen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

13.02.2014 20:59, josef.p...@gmail.com kirjoitti:
[clip]
> I assume numpy/scipy will participate under the PSF umbrella. So
> this deadline is for the PSF. However, Terri, the organizer for the
> PSF, asked for links to Ideas pages to be able to show Google what
> interesting projects the PSF has.

Here's a shot at that (stolen from roadmap etc):

https://github.com/scipy/scipy/wiki/GSoC-project-ideas

Please update as you see fit.

Did we count the number of prospective mentors >= 3? Scipy is not yet
listed on the PSF GSoC 2014 project list, so I think if we are going
to participate, we should let them know.

Best,
Pauli
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlL9IJoACgkQ6BQxb7O0pWALNwCgy0YwyTBxuaD+As3lOiAlp0/A
3ZcAnR4VCb9rjQ0WE/JDbfpWPxbAj76W
=iYXB
-END PGP SIGNATURE-

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[josef . pktd]

On Thu, Feb 13, 2014 at 1:27 PM, Jennifer stone wrote:

>
>
>
> On Thu, Feb 13, 2014 at 10:18 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Thought I'd forward this to the lists in case we need to do something.
>>
>> Hi everyone,
>>>
>>> Just a friendly reminder that applications for mentoring organizations
>>> close in about 24 hours. Please get your applications in soon, we will
>>> not accept late applications for any reason!
>>>
>>> Thanks,
>>> Carol
>>
>>
>> Chuck
>>
>> Guys, please register. People like me are eagerly looking forward to work
> with the organization this summer!
>

I assume numpy/scipy will participate under the PSF umbrella. So this
deadline is for the PSF.
However, Terri, the organizer for the PSF, asked for links to Ideas pages
to be able to show Google what interesting projects the PSF has.

Josef



>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

[Jennifer stone]

On Thu, Feb 13, 2014 at 10:18 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

> Thought I'd forward this to the lists in case we need to do something.
>
> Hi everyone,
>>
>> Just a friendly reminder that applications for mentoring organizations
>> close in about 24 hours. Please get your applications in soon, we will
>> not accept late applications for any reason!
>>
>> Thanks,
>> Carol
>
>
> Chuck
>
> Guys, please register. People like me are eagerly looking forward to work
with the organization this summer!
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] GSOC

[Charles R Harris]

Thought I'd forward this to the lists in case we need to do something.

Hi everyone,
>
> Just a friendly reminder that applications for mentoring organizations
> close in about 24 hours. Please get your applications in soon, we will
> not accept late applications for any reason!
>
> Thanks,
> Carol


Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Charles R Harris]

On Fri, May 3, 2013 at 12:13 PM, Arink Verma wrote:

> I have created a new PR, have removed one irrelevant version check.
> https://github.com/numpy/numpy/pull/3304/files
>

I made some remarks on the PR.

The convention on numpy-discussion is bottom posting so you should do that
to avoid future complaints.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Arink Verma]

I have created a new PR, have removed one irrelevant version check.
https://github.com/numpy/numpy/pull/3304/files


On Fri, May 3, 2013 at 11:29 PM, Arink Verma wrote:

> I hardly found, any thing to improve and correct.. not even typo in docs?
> Where we need to avoid the version checks?
>
>
>
> On Fri, May 3, 2013 at 10:52 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 2, 2013 at 6:47 PM,  wrote:
>>
>>> On Thu, May 2, 2013 at 6:30 PM, Ralf Gommers 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers 
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris
>>> >>  wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers <
>>> ralf.gomm...@gmail.com>
>>> >>> wrote:
>>> 
>>> 
>>> 
>>> 
>>>  On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>>> >
>>> > Charles R Harris  gmail.com> writes:
>>> > [clip]
>>> > > * Did you notice this line on the requirements page? "Having your
>>> > > first pull request merged before the GSoC application deadline
>>> (May
>>> > > 3)
>>> > > is required for your application to be accepted."
>>> > >
>>> > > Where is that last requirement? It seems out of line to me.
>>> > > Arink now has a pull request, but it looks intrusive enough
>>> > > and needs enough work that I don't think we can just put it in.
>>> >
>>> > Well, we wrote so here:
>>> >
>>> > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>>> >
>>> > but that's maybe just a mistake -- PSF states exactly the opposite:
>>> >
>>> >
>>> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
>>> 
>>> 
>>>  It wasn't a mistake - the part of a PR process that is most
>>> interesting
>>>  in the context of evaluating GSoC applications is the dialogue and
>>> how the
>>>  submitter deals with feedback.
>>> 
>>>  I forgot to add on that page (although I think it was in one of my
>>>  emails) that the patch shouldn't be completely trivial - fixing a
>>> typo
>>>  doesn't really tell us all that much. But in this case Chuck's
>>> suggestion on
>>>  the PR of how to get something merged looks fine.
>>> 
>>> >>>
>>> >>> My feeling is that learning to work with the community is part of the
>>> >>> process after acceptance and one of the reasons there are mentors.
>>> You might
>>> >>> get some bad choices skipping the submission/acceptance bit, but you
>>> might
>>> >>> also close the door on people who are new to the whole thing.
>>> Ideally, the
>>> >>> applicants would already have involved themselves with the community,
>>> >>> practically that may often not be ths case.
>>> >>
>>> >>
>>> >> You may be right in all of that, but since there's a good chance that
>>> >> there are more applicants than slots I'd rather not make those bad
>>> choices
>>> >> if they're acceptable.
>>> >
>>> >
>>> > acceptable --> avoidable
>>> >
>>> >>
>>> >> Right now we have three solid proposals, from Arink, Blake and Surya.
>>> If
>>> >> we're lucky we'll get three slots, but if not then we'll have a tough
>>> choice
>>> >> to make.
>>> >>
>>> >> The application deadline is tomorrow, so now is the time for final
>>> tweaks
>>> >> to the proposals. After that of course the plan can still be worked
>>> out
>>> >> more, but it can't be edited on Melange anymore.
>>>
>>> Terri can still make it editable on Melange if necessary.
>>>
>>>
>> Arink, you still have work to do for a PR.
>>
>> Chuck.
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
>
> --
> Arink
> Computer Science and Engineering
> Indian Institute of Technology Ropar
> www.arinkverma.in
>



-- 
Arink
Computer Science and Engineering
Indian Institute of Technology Ropar
www.arinkverma.in
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Arink Verma]

I hardly found, any thing to improve and correct.. not even typo in docs?
Where we need to avoid the version checks?



On Fri, May 3, 2013 at 10:52 PM, Charles R Harris  wrote:

>
>
> On Thu, May 2, 2013 at 6:47 PM,  wrote:
>
>> On Thu, May 2, 2013 at 6:30 PM, Ralf Gommers 
>> wrote:
>> >
>> >
>> >
>> > On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers 
>> > wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris
>> >>  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers > >
>> >>> wrote:
>> 
>> 
>> 
>> 
>>  On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>> >
>> > Charles R Harris  gmail.com> writes:
>> > [clip]
>> > > * Did you notice this line on the requirements page? "Having your
>> > > first pull request merged before the GSoC application deadline
>> (May
>> > > 3)
>> > > is required for your application to be accepted."
>> > >
>> > > Where is that last requirement? It seems out of line to me.
>> > > Arink now has a pull request, but it looks intrusive enough
>> > > and needs enough work that I don't think we can just put it in.
>> >
>> > Well, we wrote so here:
>> >
>> > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>> >
>> > but that's maybe just a mistake -- PSF states exactly the opposite:
>> >
>> >
>> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
>> 
>> 
>>  It wasn't a mistake - the part of a PR process that is most
>> interesting
>>  in the context of evaluating GSoC applications is the dialogue and
>> how the
>>  submitter deals with feedback.
>> 
>>  I forgot to add on that page (although I think it was in one of my
>>  emails) that the patch shouldn't be completely trivial - fixing a
>> typo
>>  doesn't really tell us all that much. But in this case Chuck's
>> suggestion on
>>  the PR of how to get something merged looks fine.
>> 
>> >>>
>> >>> My feeling is that learning to work with the community is part of the
>> >>> process after acceptance and one of the reasons there are mentors.
>> You might
>> >>> get some bad choices skipping the submission/acceptance bit, but you
>> might
>> >>> also close the door on people who are new to the whole thing.
>> Ideally, the
>> >>> applicants would already have involved themselves with the community,
>> >>> practically that may often not be ths case.
>> >>
>> >>
>> >> You may be right in all of that, but since there's a good chance that
>> >> there are more applicants than slots I'd rather not make those bad
>> choices
>> >> if they're acceptable.
>> >
>> >
>> > acceptable --> avoidable
>> >
>> >>
>> >> Right now we have three solid proposals, from Arink, Blake and Surya.
>> If
>> >> we're lucky we'll get three slots, but if not then we'll have a tough
>> choice
>> >> to make.
>> >>
>> >> The application deadline is tomorrow, so now is the time for final
>> tweaks
>> >> to the proposals. After that of course the plan can still be worked out
>> >> more, but it can't be edited on Melange anymore.
>>
>> Terri can still make it editable on Melange if necessary.
>>
>>
> Arink, you still have work to do for a PR.
>
> Chuck.
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 
Arink
Computer Science and Engineering
Indian Institute of Technology Ropar
www.arinkverma.in
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Charles R Harris]

On Thu, May 2, 2013 at 6:47 PM,  wrote:

> On Thu, May 2, 2013 at 6:30 PM, Ralf Gommers 
> wrote:
> >
> >
> >
> > On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers 
> > wrote:
> >>
> >>
> >>
> >>
> >> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers 
> >>> wrote:
> 
> 
> 
> 
>  On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
> >
> > Charles R Harris  gmail.com> writes:
> > [clip]
> > > * Did you notice this line on the requirements page? "Having your
> > > first pull request merged before the GSoC application deadline (May
> > > 3)
> > > is required for your application to be accepted."
> > >
> > > Where is that last requirement? It seems out of line to me.
> > > Arink now has a pull request, but it looks intrusive enough
> > > and needs enough work that I don't think we can just put it in.
> >
> > Well, we wrote so here:
> >
> > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
> >
> > but that's maybe just a mistake -- PSF states exactly the opposite:
> >
> > http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
> 
> 
>  It wasn't a mistake - the part of a PR process that is most
> interesting
>  in the context of evaluating GSoC applications is the dialogue and
> how the
>  submitter deals with feedback.
> 
>  I forgot to add on that page (although I think it was in one of my
>  emails) that the patch shouldn't be completely trivial - fixing a typo
>  doesn't really tell us all that much. But in this case Chuck's
> suggestion on
>  the PR of how to get something merged looks fine.
> 
> >>>
> >>> My feeling is that learning to work with the community is part of the
> >>> process after acceptance and one of the reasons there are mentors. You
> might
> >>> get some bad choices skipping the submission/acceptance bit, but you
> might
> >>> also close the door on people who are new to the whole thing. Ideally,
> the
> >>> applicants would already have involved themselves with the community,
> >>> practically that may often not be ths case.
> >>
> >>
> >> You may be right in all of that, but since there's a good chance that
> >> there are more applicants than slots I'd rather not make those bad
> choices
> >> if they're acceptable.
> >
> >
> > acceptable --> avoidable
> >
> >>
> >> Right now we have three solid proposals, from Arink, Blake and Surya. If
> >> we're lucky we'll get three slots, but if not then we'll have a tough
> choice
> >> to make.
> >>
> >> The application deadline is tomorrow, so now is the time for final
> tweaks
> >> to the proposals. After that of course the plan can still be worked out
> >> more, but it can't be edited on Melange anymore.
>
> Terri can still make it editable on Melange if necessary.
>
>
Arink, you still have work to do for a PR.

Chuck.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[josef . pktd]

On Thu, May 2, 2013 at 6:30 PM, Ralf Gommers  wrote:
>
>
>
> On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers 
> wrote:
>>
>>
>>
>>
>> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris
>>  wrote:
>>>
>>>
>>>
>>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers 
>>> wrote:




 On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>
> Charles R Harris  gmail.com> writes:
> [clip]
> > * Did you notice this line on the requirements page? "Having your
> > first pull request merged before the GSoC application deadline (May
> > 3)
> > is required for your application to be accepted."
> >
> > Where is that last requirement? It seems out of line to me.
> > Arink now has a pull request, but it looks intrusive enough
> > and needs enough work that I don't think we can just put it in.
>
> Well, we wrote so here:
>
> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>
> but that's maybe just a mistake -- PSF states exactly the opposite:
>
> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013


 It wasn't a mistake - the part of a PR process that is most interesting
 in the context of evaluating GSoC applications is the dialogue and how the
 submitter deals with feedback.

 I forgot to add on that page (although I think it was in one of my
 emails) that the patch shouldn't be completely trivial - fixing a typo
 doesn't really tell us all that much. But in this case Chuck's suggestion 
 on
 the PR of how to get something merged looks fine.

>>>
>>> My feeling is that learning to work with the community is part of the
>>> process after acceptance and one of the reasons there are mentors. You might
>>> get some bad choices skipping the submission/acceptance bit, but you might
>>> also close the door on people who are new to the whole thing. Ideally, the
>>> applicants would already have involved themselves with the community,
>>> practically that may often not be ths case.
>>
>>
>> You may be right in all of that, but since there's a good chance that
>> there are more applicants than slots I'd rather not make those bad choices
>> if they're acceptable.
>
>
> acceptable --> avoidable
>
>>
>> Right now we have three solid proposals, from Arink, Blake and Surya. If
>> we're lucky we'll get three slots, but if not then we'll have a tough choice
>> to make.
>>
>> The application deadline is tomorrow, so now is the time for final tweaks
>> to the proposals. After that of course the plan can still be worked out
>> more, but it can't be edited on Melange anymore.

Terri can still make it editable on Melange if necessary.

Josef

>>
>> Ralf
>>
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Ralf Gommers]

On Fri, May 3, 2013 at 12:29 AM, Ralf Gommers wrote:

>
>
>
> On Thu, May 2, 2013 at 9:54 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote:
>>
>>>
>>>
>>>
>>> On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>>>
 Charles R Harris  gmail.com> writes:
 [clip]
 > * Did you notice this line on the requirements page? "Having your
 > first pull request merged before the GSoC application deadline (May 3)
 > is required for your application to be accepted."
 >
 > Where is that last requirement? It seems out of line to me.
 > Arink now has a pull request, but it looks intrusive enough
 > and needs enough work that I don't think we can just put it in.

 Well, we wrote so here:

 http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas

 but that's maybe just a mistake -- PSF states exactly the opposite:

 http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013

>>>
>>> It wasn't a mistake - the part of a PR process that is most interesting
>>> in the context of evaluating GSoC applications is the dialogue and how the
>>> submitter deals with feedback.
>>>
>>> I forgot to add on that page (although I think it was in one of my
>>> emails) that the patch shouldn't be completely trivial - fixing a typo
>>> doesn't really tell us all that much. But in this case Chuck's suggestion
>>> on the PR of how to get something merged looks fine.
>>>
>>>
>> My feeling is that learning to work with the community is part of the
>> process after acceptance and one of the reasons there are mentors. You
>> might get some bad choices skipping the submission/acceptance bit, but you
>> might also close the door on people who are new to the whole thing.
>> Ideally, the applicants would already have involved themselves with the
>> community, practically that may often not be ths case.
>>
>
> You may be right in all of that, but since there's a good chance that
> there are more applicants than slots I'd rather not make those bad choices
> if they're acceptable.
>

acceptable --> avoidable


> Right now we have three solid proposals, from Arink, Blake and Surya. If
> we're lucky we'll get three slots, but if not then we'll have a tough
> choice to make.
>
> The application deadline is tomorrow, so now is the time for final tweaks
> to the proposals. After that of course the plan can still be worked out
> more, but it can't be edited on Melange anymore.
>
> Ralf
>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Ralf Gommers]

On Thu, May 2, 2013 at 9:54 PM, Charles R Harris
wrote:

>
>
> On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote:
>
>>
>>
>>
>> On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>>
>>> Charles R Harris  gmail.com> writes:
>>> [clip]
>>> > * Did you notice this line on the requirements page? "Having your
>>> > first pull request merged before the GSoC application deadline (May 3)
>>> > is required for your application to be accepted."
>>> >
>>> > Where is that last requirement? It seems out of line to me.
>>> > Arink now has a pull request, but it looks intrusive enough
>>> > and needs enough work that I don't think we can just put it in.
>>>
>>> Well, we wrote so here:
>>>
>>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>>>
>>> but that's maybe just a mistake -- PSF states exactly the opposite:
>>>
>>> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
>>>
>>
>> It wasn't a mistake - the part of a PR process that is most interesting
>> in the context of evaluating GSoC applications is the dialogue and how the
>> submitter deals with feedback.
>>
>> I forgot to add on that page (although I think it was in one of my
>> emails) that the patch shouldn't be completely trivial - fixing a typo
>> doesn't really tell us all that much. But in this case Chuck's suggestion
>> on the PR of how to get something merged looks fine.
>>
>>
> My feeling is that learning to work with the community is part of the
> process after acceptance and one of the reasons there are mentors. You
> might get some bad choices skipping the submission/acceptance bit, but you
> might also close the door on people who are new to the whole thing.
> Ideally, the applicants would already have involved themselves with the
> community, practically that may often not be ths case.
>

You may be right in all of that, but since there's a good chance that there
are more applicants than slots I'd rather not make those bad choices if
they're acceptable.

Right now we have three solid proposals, from Arink, Blake and Surya. If
we're lucky we'll get three slots, but if not then we'll have a tough
choice to make.

The application deadline is tomorrow, so now is the time for final tweaks
to the proposals. After that of course the plan can still be worked out
more, but it can't be edited on Melange anymore.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Charles R Harris]

On Thu, May 2, 2013 at 11:49 AM, Ralf Gommers wrote:

>
>
>
> On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:
>
>> Charles R Harris  gmail.com> writes:
>> [clip]
>> > * Did you notice this line on the requirements page? "Having your
>> > first pull request merged before the GSoC application deadline (May 3)
>> > is required for your application to be accepted."
>> >
>> > Where is that last requirement? It seems out of line to me.
>> > Arink now has a pull request, but it looks intrusive enough
>> > and needs enough work that I don't think we can just put it in.
>>
>> Well, we wrote so here:
>>
>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>>
>> but that's maybe just a mistake -- PSF states exactly the opposite:
>>
>> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
>>
>
> It wasn't a mistake - the part of a PR process that is most interesting in
> the context of evaluating GSoC applications is the dialogue and how the
> submitter deals with feedback.
>
> I forgot to add on that page (although I think it was in one of my emails)
> that the patch shouldn't be completely trivial - fixing a typo doesn't
> really tell us all that much. But in this case Chuck's suggestion on the PR
> of how to get something merged looks fine.
>
>
My feeling is that learning to work with the community is part of the
process after acceptance and one of the reasons there are mentors. You
might get some bad choices skipping the submission/acceptance bit, but you
might also close the door on people who are new to the whole thing.
Ideally, the applicants would already have involved themselves with the
community, practically that may often not be ths case.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Ralf Gommers]

On Thu, May 2, 2013 at 6:45 PM, Pauli Virtanen  wrote:

> Charles R Harris  gmail.com> writes:
> [clip]
> > * Did you notice this line on the requirements page? "Having your
> > first pull request merged before the GSoC application deadline (May 3)
> > is required for your application to be accepted."
> >
> > Where is that last requirement? It seems out of line to me.
> > Arink now has a pull request, but it looks intrusive enough
> > and needs enough work that I don't think we can just put it in.
>
> Well, we wrote so here:
>
> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas
>
> but that's maybe just a mistake -- PSF states exactly the opposite:
>
> http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013
>

It wasn't a mistake - the part of a PR process that is most interesting in
the context of evaluating GSoC applications is the dialogue and how the
submitter deals with feedback.

I forgot to add on that page (although I think it was in one of my emails)
that the patch shouldn't be completely trivial - fixing a typo doesn't
really tell us all that much. But in this case Chuck's suggestion on the PR
of how to get something merged looks fine.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Pauli Virtanen]

Charles R Harris  gmail.com> writes:
[clip]
> * Did you notice this line on the requirements page? "Having your
> first pull request merged before the GSoC application deadline (May 3)
> is required for your application to be accepted."
> 
> Where is that last requirement? It seems out of line to me.
> Arink now has a pull request, but it looks intrusive enough
> and needs enough work that I don't think we can just put it in.

Well, we wrote so here:

http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas‎

but that's maybe just a mistake -- PSF states exactly the opposite:

http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Raul Cota]

For the sake of completeness, I don't think I ever mentioned what I used 
to profile when I was working on speeding up the scalars. I used AQTime 
7. It is commercial and only for Windows (as far as I know). It works 
great and it gave me fairly accurate timings and all sorts of visual 
navigation features. I do have to mock around with the numpy code every 
time I want to compile it to get it to play nicely with Visual Studio to 
generate the proper bindings for the profiler.

Raul


On 02/05/2013 7:14 AM, Nathaniel Smith wrote:
> On Thu, May 2, 2013 at 6:26 AM, Arink Verma  wrote:
>> Yes, we need to ensure that..
>> Code generator can be made, which can create code for table of registered
>> dtype during build time itself.
> I'd probably just generate it at run-time on an as-needed basis.
> (I.e., use the full lookup logic the first time, then save the
> result.) New dtypes can be registered, which will mean the tables need
> to change size at runtime anyway. If someone does some strange thing
> like add float16's and float64's, we can do the lookup to determine
> that this should be handled by the float64/float64 loop, and then
> store that information so that the next time it's fast (but we
> probably don't want to be calculating all combinations at build-time,
> which would require running the full type resolution machinery, esp.
> since it wouldn't really bring any benefits that I can see).
>
> * Re: the profiling, I wrote a full oprofile->callgrind format script
> years ago: http://vorpus.org/~njs/op2calltree.py
> Haven't used it in years either but neither oprofile nor kcachegrind
> are terribly fast-moving projects so it's probably still working, or
> could be made so without much work.
> Or easier is to use the gperftools CPU profiler:
> https://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html
>
> Instead of linking to it at build time, you can just use ctypes:
>
> In [7]: profiler = ctypes.CDLL("libprofiler.so.0")
>
> In [8]: profiler.ProfilerStart("some-file-name-here")
> Out[8]: 1
>
> In [9]: # do stuff here
>
> In [10]: profiler.ProfilerStop()
> PROFILE: interrupts/evictions/bytes = 2/0/592
> Out[10]: 46
>
> Then all the pprof analysis tools are available as described on that webpage.
>
> * Please don't trust those random suggestions for possible
> improvements I threw out when writing the original description.
> Probably it's true that FP flag checking and ufunc type lookup are
> expensive, but one should fix what the profile says to fix, not what
> someone guessed might be good to fix based on a few minutes thought.
>
> * Instead of making a giant table of everything that needs to be done
> to make stuff fast first, before writing any code, I'd suggest picking
> one operation, figuring out what change would be the biggest
> improvement for it, making that change, checking that it worked, and
> then repeat until that operation is really fast. Then if there's still
> time pick another operation. Producing a giant todo list isn't very
> productive by itself if there's no time then to actually do all the
> things on the list :-).
>
> * Did you notice this line on the requirements page? "Having your
> first pull request merged before the GSoC application deadline (May 3)
> is required for your application to be accepted."
>
> -n
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Charles R Harris]

On Thu, May 2, 2013 at 7:14 AM, Nathaniel Smith  wrote:

> On Thu, May 2, 2013 at 6:26 AM, Arink Verma 
> wrote:
> > Yes, we need to ensure that..
> > Code generator can be made, which can create code for table of registered
> > dtype during build time itself.
>
> I'd probably just generate it at run-time on an as-needed basis.
> (I.e., use the full lookup logic the first time, then save the
> result.) New dtypes can be registered, which will mean the tables need
> to change size at runtime anyway. If someone does some strange thing
> like add float16's and float64's, we can do the lookup to determine
> that this should be handled by the float64/float64 loop, and then
> store that information so that the next time it's fast (but we
> probably don't want to be calculating all combinations at build-time,
> which would require running the full type resolution machinery, esp.
> since it wouldn't really bring any benefits that I can see).
>
> * Re: the profiling, I wrote a full oprofile->callgrind format script
> years ago: http://vorpus.org/~njs/op2calltree.py
> Haven't used it in years either but neither oprofile nor kcachegrind
> are terribly fast-moving projects so it's probably still working, or
> could be made so without much work.
> Or easier is to use the gperftools CPU profiler:
> https://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html
>
> Instead of linking to it at build time, you can just use ctypes:
>
> In [7]: profiler = ctypes.CDLL("libprofiler.so.0")
>
> In [8]: profiler.ProfilerStart("some-file-name-here")
> Out[8]: 1
>
> In [9]: # do stuff here
>
> In [10]: profiler.ProfilerStop()
> PROFILE: interrupts/evictions/bytes = 2/0/592
> Out[10]: 46
>
> Then all the pprof analysis tools are available as described on that
> webpage.
>
> * Please don't trust those random suggestions for possible
> improvements I threw out when writing the original description.
> Probably it's true that FP flag checking and ufunc type lookup are
> expensive, but one should fix what the profile says to fix, not what
> someone guessed might be good to fix based on a few minutes thought.
>
> * Instead of making a giant table of everything that needs to be done
> to make stuff fast first, before writing any code, I'd suggest picking
> one operation, figuring out what change would be the biggest
> improvement for it, making that change, checking that it worked, and
> then repeat until that operation is really fast. Then if there's still
> time pick another operation. Producing a giant todo list isn't very
> productive by itself if there's no time then to actually do all the
> things on the list :-).
>
> * Did you notice this line on the requirements page? "Having your
> first pull request merged before the GSoC application deadline (May 3)
> is required for your application to be accepted."
>

Where is that last requirement? It seems out of line to me. Arink now has a
pull request, but it looks intrusive enough and needs enough work that I
don't think we can just put it in.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Arink Verma]

Updating table at runtime, seems a good option. But then we have
maintain separate file for caching and storing.

I will see, op2calltree.py  and
gperftools  both.

>* Instead of making a giant table of everything that needs to be done
>to make stuff fast first, before writing any code, I'd suggest picking
>one operation, figuring out what change would be the biggest
>improvement for it, making that change, checking that it worked, and
>then repeat until that operation is really fast.
Working like that only, firstly optimizing sum operation specifically for
int scalar then will move to other.


>* Did you notice this line on the requirements page? "Having your
>first pull request merged before the GSoC application deadline (May 3)
>is required for your application to be accepted."
Thanks for reminding!
I was too busy with my university exams, I forgot to do that.
Does the merge has to be related to gsoc project, or any other improvement
can be consider?



On Thu, May 2, 2013 at 6:44 PM, Nathaniel Smith  wrote:

> On Thu, May 2, 2013 at 6:26 AM, Arink Verma 
> wrote:
> > Yes, we need to ensure that..
> > Code generator can be made, which can create code for table of registered
> > dtype during build time itself.
>
> I'd probably just generate it at run-time on an as-needed basis.
> (I.e., use the full lookup logic the first time, then save the
> result.) New dtypes can be registered, which will mean the tables need
> to change size at runtime anyway. If someone does some strange thing
> like add float16's and float64's, we can do the lookup to determine
> that this should be handled by the float64/float64 loop, and then
> store that information so that the next time it's fast (but we
> probably don't want to be calculating all combinations at build-time,
> which would require running the full type resolution machinery, esp.
> since it wouldn't really bring any benefits that I can see).
>
> * Re: the profiling, I wrote a full oprofile->callgrind format script
> years ago: http://vorpus.org/~njs/op2calltree.py
> Haven't used it in years either but neither oprofile nor kcachegrind
> are terribly fast-moving projects so it's probably still working, or
> could be made so without much work.
> Or easier is to use the gperftools CPU profiler:
> https://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html
>
> Instead of linking to it at build time, you can just use ctypes:
>
> In [7]: profiler = ctypes.CDLL("libprofiler.so.0")
>
> In [8]: profiler.ProfilerStart("some-file-name-here")
> Out[8]: 1
>
> In [9]: # do stuff here
>
> In [10]: profiler.ProfilerStop()
> PROFILE: interrupts/evictions/bytes = 2/0/592
> Out[10]: 46
>
> Then all the pprof analysis tools are available as described on that
> webpage.
>
> * Please don't trust those random suggestions for possible
> improvements I threw out when writing the original description.
> Probably it's true that FP flag checking and ufunc type lookup are
> expensive, but one should fix what the profile says to fix, not what
> someone guessed might be good to fix based on a few minutes thought.
>
> * Instead of making a giant table of everything that needs to be done
> to make stuff fast first, before writing any code, I'd suggest picking
> one operation, figuring out what change would be the biggest
> improvement for it, making that change, checking that it worked, and
> then repeat until that operation is really fast. Then if there's still
> time pick another operation. Producing a giant todo list isn't very
> productive by itself if there's no time then to actually do all the
> things on the list :-).
>
> * Did you notice this line on the requirements page? "Having your
> first pull request merged before the GSoC application deadline (May 3)
> is required for your application to be accepted."
>
> -n
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Arink
Computer Science and Engineering
Indian Institute of Technology Ropar
www.arinkverma.in
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Nathaniel Smith]

On Thu, May 2, 2013 at 6:26 AM, Arink Verma  wrote:
> Yes, we need to ensure that..
> Code generator can be made, which can create code for table of registered
> dtype during build time itself.

I'd probably just generate it at run-time on an as-needed basis.
(I.e., use the full lookup logic the first time, then save the
result.) New dtypes can be registered, which will mean the tables need
to change size at runtime anyway. If someone does some strange thing
like add float16's and float64's, we can do the lookup to determine
that this should be handled by the float64/float64 loop, and then
store that information so that the next time it's fast (but we
probably don't want to be calculating all combinations at build-time,
which would require running the full type resolution machinery, esp.
since it wouldn't really bring any benefits that I can see).

* Re: the profiling, I wrote a full oprofile->callgrind format script
years ago: http://vorpus.org/~njs/op2calltree.py
Haven't used it in years either but neither oprofile nor kcachegrind
are terribly fast-moving projects so it's probably still working, or
could be made so without much work.
Or easier is to use the gperftools CPU profiler:
https://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html

Instead of linking to it at build time, you can just use ctypes:

In [7]: profiler = ctypes.CDLL("libprofiler.so.0")

In [8]: profiler.ProfilerStart("some-file-name-here")
Out[8]: 1

In [9]: # do stuff here

In [10]: profiler.ProfilerStop()
PROFILE: interrupts/evictions/bytes = 2/0/592
Out[10]: 46

Then all the pprof analysis tools are available as described on that webpage.

* Please don't trust those random suggestions for possible
improvements I threw out when writing the original description.
Probably it's true that FP flag checking and ufunc type lookup are
expensive, but one should fix what the profile says to fix, not what
someone guessed might be good to fix based on a few minutes thought.

* Instead of making a giant table of everything that needs to be done
to make stuff fast first, before writing any code, I'd suggest picking
one operation, figuring out what change would be the biggest
improvement for it, making that change, checking that it worked, and
then repeat until that operation is really fast. Then if there's still
time pick another operation. Producing a giant todo list isn't very
productive by itself if there's no time then to actually do all the
things on the list :-).

* Did you notice this line on the requirements page? "Having your
first pull request merged before the GSoC application deadline (May 3)
is required for your application to be accepted."

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[David Cournapeau]

On Thu, May 2, 2013 at 11:26 AM, Arink Verma  wrote:
> Yes, we need to ensure that..
> Code generator can be made, which can create code for table of registered
> dtype during build time itself.

So dtypes can be registered at runtime as well. In an ideal world,
'native' numpy types would not be special cases. This is too big for a
GSoC, but we should make sure we don't make it worse.

>
> Also at present there lot of duplicate code that attempts to work around
> these slow paths, simplification of that code is also required.

That there is room for consolidation would be an understatement :)

David
>
> On Thu, May 2, 2013 at 10:12 AM, David Cournapeau 
> wrote:
>>
>> On Thu, May 2, 2013 at 5:25 AM, Arink Verma 
>> wrote:
>> > @Raul
>> > I will pull new version, and try to include that also.
>> > What is wrong with macros for inline function?
>> > Yes, time for ufunc is reduced to almost half, for lookup table, I am
>> > generating key from argument type and returning the appropriated
>> > value.[1]
>> >
>> > @Chuck
>> > Yes I did some profiling with oprofiler for "python -m timeit -n 100
>> > -s
>> > 'import numpy as np;x = np.asarray(1.0)' 'x+x'". see data sheet.[2]
>> >
>> > As every time a ufunc is invoked, the code has to check every single
>> > data
>> > type possible (bool, int, double, etc) until if finds the best match for
>> > the
>> > data that the operation is being performed on. In scalar, we can send
>> > best
>> > match, from pre-populated table. At present the implementation is not
>> > well-structured and support only addition for int+int and float+float.
>> > [1]
>>
>> You are pointing out something that may well be the main difficulty:
>> the code there is messy, and we need to ensure that optimisations
>> don't preclude later extensions (especially with regard to new dtype
>> addition).
>>
>> David
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> --
> Arink
> Computer Science and Engineering
> Indian Institute of Technology Ropar
> www.arinkverma.in
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[Arink Verma]

Yes, we need to ensure that..
Code generator can be made, which can create code for table of registered
dtype during build time itself.

Also at present there lot of duplicate code that attempts to work around
these slow paths, simplification of that code is also required.


On Thu, May 2, 2013 at 10:12 AM, David Cournapeau wrote:

> On Thu, May 2, 2013 at 5:25 AM, Arink Verma 
> wrote:
> > @Raul
> > I will pull new version, and try to include that also.
> > What is wrong with macros for inline function?
> > Yes, time for ufunc is reduced to almost half, for lookup table, I am
> > generating key from argument type and returning the appropriated
> value.[1]
> >
> > @Chuck
> > Yes I did some profiling with oprofiler for "python -m timeit -n 100
> -s
> > 'import numpy as np;x = np.asarray(1.0)' 'x+x'". see data sheet.[2]
> >
> > As every time a ufunc is invoked, the code has to check every single data
> > type possible (bool, int, double, etc) until if finds the best match for
> the
> > data that the operation is being performed on. In scalar, we can send
> best
> > match, from pre-populated table. At present the implementation is not
> > well-structured and support only addition for int+int and float+float.
> [1]
>
> You are pointing out something that may well be the main difficulty:
> the code there is messy, and we need to ensure that optimisations
> don't preclude later extensions (especially with regard to new dtype
> addition).
>
> David
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Arink
Computer Science and Engineering
Indian Institute of Technology Ropar
www.arinkverma.in
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSoC : Performance parity between numpy arrays and Python scalars

[David Cournapeau]

On Thu, May 2, 2013 at 5:25 AM, Arink Verma  wrote:
> @Raul
> I will pull new version, and try to include that also.
> What is wrong with macros for inline function?
> Yes, time for ufunc is reduced to almost half, for lookup table, I am
> generating key from argument type and returning the appropriated value.[1]
>
> @Chuck
> Yes I did some profiling with oprofiler for "python -m timeit -n 100 -s
> 'import numpy as np;x = np.asarray(1.0)' 'x+x'". see data sheet.[2]
>
> As every time a ufunc is invoked, the code has to check every single data
> type possible (bool, int, double, etc) until if finds the best match for the
> data that the operation is being performed on. In scalar, we can send best
> match, from pre-populated table. At present the implementation is not
> well-structured and support only addition for int+int and float+float. [1]

You are pointing out something that may well be the main difficulty:
the code there is messy, and we need to ensure that optimisations
don't preclude later extensions (especially with regard to new dtype
addition).

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion