Re: [Numpy-discussion] memory allocation at assignment
Yes it does. If you want to avoid this extra copy, and have a
pre-existing output array, you can do:
np.add(a, b, out=c)
('+' on numpy array's is just a synonym for np.add; np.add is a ufunc,
and all ufunc's accept this syntax:
http://docs.scipy.org/doc/numpy/reference/ufuncs.html
)
Is the creation of the tmp as expensive as creation of a new numpy
array or is it somewhat lighter weight (like being just a data
buffer). I sometimes use the c[:] syntax thinking I might benefit from
numpy.array re-use. But now I think that was misguided.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Created NumPy 1.7.x branch
On Jun 27, 2012, at 1:18 AM, Fernando Perez wrote:
On Tue, Jun 26, 2012 at 11:02 PM, Travis Oliphant tra...@continuum.io wrote:
I just want to speak up for the people who are affected by API breakage who
are not as vocal on this list.
Certainly! And indeed I bet you that's a community underrepresented
here: those of us who are on this list are likely to be up to speed on
what's happening with the API and can therefore adjust to changes
quickly, simply because we know they have occurred. Random J. User
who gets an upstream update and all of a sudden finds previously
working code to break is unlikely to be active here and will be very,
very unhappy
If anything, the lesson is: for a project that's so deep in the
dependency tree as numpy is, A{P,B}I stability is a paramount concern,
with a cost that gets higher the more successful the project is. This
means AXIs should evolve only in backwards-compatible ways when at all
possible, with backwards-compatibility being broken only in:
- clearly designated points that are agreed upon by as many as possible
- with clear explanations of how old codes need to be adapted to the
new interface to continue working
- if at all possible with advance warnings, and even better, a system
for 'future' loading.
This is a good reminder. I agree with your views here. I've not been able
to communicate very well my attitudes on this and I've been saddened at how
eager some seem to pick apart my words to find problems with them. My
discussion about the ABI and API breakage should not be taken as an assertion
that I don't recognize that ABI breakage is bad and has consequences. I'm a
little surprised that people assume I haven't been listening or paying
attention or something.But, I recognize that I don't always communicate
clearly enough. I do understand the consequences of ABI breakage.I also
understand the pain involved.I have no plans to break the ABI.
There is a certain group who is affected by ABI breakage and another group
*more* affected by API breakage. It feels like this list is particularly
populated with people who feel pain by ABI breakage whereas the people who feel
pain with API breakage are not as vocal, don' t track this list, etc. But,
their stories are just as compelling to me. I understand the pain they feel
as well when the NumPy API breaks. It's just as important that we take them
into consideration.That's my only point.
Right now, though, arguing over the relative importance of ABI or API breakage
is moot.I was simply pointing out my perspective that I think a single ABI
breakage in 1.5.0 would have been better than the API and use-case breakages
that have been reported (I know these are only very weakly correlated so it's
just an analogy). If you disagree with me, that's fine. Just understand
that any frustration you feel about the thought of ABI breakage is the same as
the frustration I feel about changes that cause working code to break for
people.I also understand that it's not quite the same thing because the
phrase changes that cause working code to break is too strong. Some code
that works has work-arounds and hacks and assumptions about APIs. In
other word, it is possible that some NumPy-dependent code out there works
accidentally.
Of course, what is a hack or an accidental usage is not at all clear. I
can't define it. It takes judgment to make a decision. This judgment
requires an awareness of the intention of the original code, how big the
user-base is of the group that is making the hack. How difficult it is to
remedy the situation, etc. These are hard problems. I don't claim to
understand how to solve all of them. I don't claim that I won't make serious
mistakes.All I can do is offer my experience, my awareness of the code
history (including the code history of Numeric and Numarray), and my
interactions with many downstream users.We need good judgment from as many
NumPy developers as possible. That judgment must be colored with empathy for
as many users of NumPy as possible.
Best,
-Travis
Python in fact has the __future__ imports that help quite a bit for
people to start adapting their codes. How about creating a
numpy.future module where new, non-backward-compatible APIs could go?
That would give the adventurous a way to play with new features (hence
getting them better tested) as well as an easier path for gradual
migration to the new features by everyone.
This may have already been discussed before, forgive me if I'm
repeating well-known material.
This is a
Cheers,
f
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
[Numpy-discussion] Meta: help, devel and stackoverflow
Hi List, this has been brought up several times, and the response has been generally positive but it has fallen through the cracks. So here are a few repeat requests. Am keeping it terse just for brevity i) Split the list into [devel] and [help] and as was mentioned recently [rant/flame]: some request for help get drowned out during active development related discussions and simple help requests pollutes more urgent development related matters. ii) Stackoverflow like site for help as well as for proposals. The silent majority has been referred to a few times recently. I suspect there does exist many lurkers on the list who do prefer one discussed solution over the other but for various reasons do not break out of their lurk mode to send a mail saying I prefer this solution. Such an interface will also help in keeping track of the level of support as compared to mails that are larges hunks of quoted text with a line or two stating ones preference or seconding a proposal. One thing I have learned from traffic accidents is that if one asks for a help of the assembled crowd, no one knows how to respond. On the other hand if you say hey there in a blue shirt could you get some water you get instant results. So pardon me for taking the presumptuous liberty to request Travis to please set it up or delegate. Splitting the lists shouldn't be hard work, setting up overflow might be more work in comparison. Best -- srean ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] memory allocation at assignment
Le 28/06/2012 02:34, Nathaniel Smith a écrit : Yes it does. If you want to avoid this extra copy, and have a pre-existing output array, you can do: np.add(a, b, out=c) And is there a temporary copy when using inplace operators like: c = a.copy() c += b Is there a temporary (c+b) array which is then assigned to c, or is it really an inplace assignment as the operator += would suggest ? Pierre signature.asc Description: OpenPGP digital signature ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
We try to support numpy questions on http://scicomp.stackexchange.com, which is a StackOverflow site dedicated towards technical computing issues that gets a fair amount of traffic from mathematicians and computational scientists. We could always use more questions and answerers :) A On Thu, Jun 28, 2012 at 6:38 AM, srean srean.l...@gmail.com wrote: Hi List, this has been brought up several times, and the response has been generally positive but it has fallen through the cracks. So here are a few repeat requests. Am keeping it terse just for brevity i) Split the list into [devel] and [help] and as was mentioned recently [rant/flame]: some request for help get drowned out during active development related discussions and simple help requests pollutes more urgent development related matters. ii) Stackoverflow like site for help as well as for proposals. The silent majority has been referred to a few times recently. I suspect there does exist many lurkers on the list who do prefer one discussed solution over the other but for various reasons do not break out of their lurk mode to send a mail saying I prefer this solution. Such an interface will also help in keeping track of the level of support as compared to mails that are larges hunks of quoted text with a line or two stating ones preference or seconding a proposal. One thing I have learned from traffic accidents is that if one asks for a help of the assembled crowd, no one knows how to respond. On the other hand if you say hey there in a blue shirt could you get some water you get instant results. So pardon me for taking the presumptuous liberty to request Travis to please set it up or delegate. Splitting the lists shouldn't be hard work, setting up overflow might be more work in comparison. Best -- srean ___ 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] memory allocation at assignment
Yes, the creation of the tmp *is* the creation of a new NumPy array. So, it
is as expensive.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jun 28, 2012, at 12:44 AM, srean srean.l...@gmail.com wrote:
Yes it does. If you want to avoid this extra copy, and have a
pre-existing output array, you can do:
np.add(a, b, out=c)
('+' on numpy array's is just a synonym for np.add; np.add is a ufunc,
and all ufunc's accept this syntax:
http://docs.scipy.org/doc/numpy/reference/ufuncs.html
)
Is the creation of the tmp as expensive as creation of a new numpy
array or is it somewhat lighter weight (like being just a data
buffer). I sometimes use the c[:] syntax thinking I might benefit from
numpy.array re-use. But now I think that was misguided.
___
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] Meta: help, devel and stackoverflow
There are some good ideas here. I propose splitting this list into devel and users lists. This might best be done by creating a new list for users and using this list for development. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jun 27, 2012, at 11:38 PM, srean srean.l...@gmail.com wrote: Hi List, this has been brought up several times, and the response has been generally positive but it has fallen through the cracks. So here are a few repeat requests. Am keeping it terse just for brevity i) Split the list into [devel] and [help] and as was mentioned recently [rant/flame]: some request for help get drowned out during active development related discussions and simple help requests pollutes more urgent development related matters. ii) Stackoverflow like site for help as well as for proposals. The silent majority has been referred to a few times recently. I suspect there does exist many lurkers on the list who do prefer one discussed solution over the other but for various reasons do not break out of their lurk mode to send a mail saying I prefer this solution. Such an interface will also help in keeping track of the level of support as compared to mails that are larges hunks of quoted text with a line or two stating ones preference or seconding a proposal. One thing I have learned from traffic accidents is that if one asks for a help of the assembled crowd, no one knows how to respond. On the other hand if you say hey there in a blue shirt could you get some water you get instant results. So pardon me for taking the presumptuous liberty to request Travis to please set it up or delegate. Splitting the lists shouldn't be hard work, setting up overflow might be more work in comparison. Best -- srean ___ 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] memory allocation at assignment
-- Travis Oliphant (on a mobile) 512-826-7480 On Jun 28, 2012, at 1:20 AM, Pierre Haessig pierre.haes...@crans.org wrote: Le 28/06/2012 02:34, Nathaniel Smith a écrit : Yes it does. If you want to avoid this extra copy, and have a pre-existing output array, you can do: np.add(a, b, out=c) And is there a temporary copy when using inplace operators like: c = a.copy() c += b Is there a temporary (c+b) array which is then assigned to c, or is it really an inplace assignment as the operator += would suggest ? It really is inplace. As Nathaniel mentioned --- all ufuncs take an out keyword. The inplace mechanism uses this so that one input and the output are the same. Travis Pierre ___ 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] Non-deterministic test failure in master
Hi Nathaniel, On Wed, Jun 27, 2012 at 11:22 AM, Nathaniel Smith n...@pobox.com wrote: According to the Travis-CI build logs, this code produces non-deterministic behaviour in master: a = np.arange(5) a[:3] = a[2:] assert_equal(a, [2, 3, 4, 3, 4]) Sometimes 'a' is [2, 3, 4, 3, 4], and sometimes it is [4, 3, 4, 3, 4]. The latter is what you get if the assignment is done 'backwards', like: a[2] = a[4] a[1] = a[3] a[0] = a[2] For example, in this build the above test failed on Python 3.2 (but passed on all other versions): http://travis-ci.org/#!/numpy/numpy/jobs/1676766 while in this build, it failed on Python 2.5 (but passed on all other versions): http://travis-ci.org/#!/numpy/numpy/jobs/1722121 Looks like we have a memcpy somewhere that should be a memmove? I also noticed this failure a few days ago. What do you think is the best way to debug this? I don't know how to reproduce it. Any ideas? Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
Hi Travis, On Thu, Jun 28, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? I think it would depend on 1.7 state. I am unwilling to drop support for 2.4 in 1.8 unless we make 1.7 a LTS, that would be supported up to 2014 Q1 (when RHEL5 stops getting security fixes - RHEL 5 is the one platform that warrants supporting 2.4 IMO) In my mind, it means 1.7 needs to be stable. Ondrej (and others) work to make sure we break neither API or ABI since a few releases would help achieving that. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-deterministic test failure in master
Hi Nathaniel, Le 27/06/2012 20:22, Nathaniel Smith a écrit : According to the Travis-CI build logs, this code produces non-deterministic behaviour in master: You mean non-deterministic across different builds, not across different executions on the same build, right ? I just ran a small loop : N = 1 N_good = 0 for i in range(N): a = np.arange(5) a[:3] = a[2:] if (a == [2,3,4,3,4]).all(): N_good += 1 print 'good result : %d/%d' % (N_good, N) and got 100 % good replication. Best, Pierre signature.asc Description: OpenPGP digital signature ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] memory allocation at assignment
Hi Nathaniel,
Thanks for the clearing my understand. This is exactly what i needed.
Thanks,
Nathaniel Smith wrote:
On Thu, Jun 28, 2012 at 12:38 AM, astronomer shailendra.vi...@gmail.com
wrote:
Hi All,
I am wondering if there any difference in memory overhead between the
following code.
a=numpy.arange(10)
b=numpy.arange(10)
c=a+b
and
a=numpy.arange(10)
b=numpy.arange(10)
c=numpy.empty_likes(a)
c[:]=a+b
Does the later code make a temproray array for the result of (a+b) and
then
copy it to c. I beleive it does that, but i wanted to make sure.
Yes it does. If you want to avoid this extra copy, and have a
pre-existing output array, you can do:
np.add(a, b, out=c)
('+' on numpy array's is just a synonym for np.add; np.add is a ufunc,
and all ufunc's accept this syntax:
http://docs.scipy.org/doc/numpy/reference/ufuncs.html
)
-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
View this message in context:
http://old.nabble.com/memory-allocation-at-assignment-tp34083731p34084248.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
The project/environment we work with already targets Python 2.7, so it'd be fine for us and our collaborators. But it's hard to comment in a more altruistic way without knowing the impact of the change. Is it possible to summarise the benefits? (e.g. Simplifies NumPy codebase; allows better support for XXX under 2.5+; ...) On 28 June 2012 13:25, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? -Travis ___ 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] Meta: help, devel and stackoverflow
+1 for a numpy-users list without dev noise. -=- Olivier 2012/6/28 Travis Oliphant tra...@continuum.io There are some good ideas here. I propose splitting this list into devel and users lists. This might best be done by creating a new list for users and using this list for development. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jun 27, 2012, at 11:38 PM, srean srean.l...@gmail.com wrote: Hi List, this has been brought up several times, and the response has been generally positive but it has fallen through the cracks. So here are a few repeat requests. Am keeping it terse just for brevity i) Split the list into [devel] and [help] and as was mentioned recently [rant/flame]: some request for help get drowned out during active development related discussions and simple help requests pollutes more urgent development related matters. ii) Stackoverflow like site for help as well as for proposals. The silent majority has been referred to a few times recently. I suspect there does exist many lurkers on the list who do prefer one discussed solution over the other but for various reasons do not break out of their lurk mode to send a mail saying I prefer this solution. Such an interface will also help in keeping track of the level of support as compared to mails that are larges hunks of quoted text with a line or two stating ones preference or seconding a proposal. One thing I have learned from traffic accidents is that if one asks for a help of the assembled crowd, no one knows how to respond. On the other hand if you say hey there in a blue shirt could you get some water you get instant results. So pardon me for taking the presumptuous liberty to request Travis to please set it up or delegate. Splitting the lists shouldn't be hard work, setting up overflow might be more work in comparison. Best -- srean ___ 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] Dropping support for Python 2.4 in NumPy 1.8
2012/6/28 David Cournapeau courn...@gmail.com Hi Travis, On Thu, Jun 28, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? I think it would depend on 1.7 state. I am unwilling to drop support for 2.4 in 1.8 unless we make 1.7 a LTS, that would be supported up to 2014 Q1 (when RHEL5 stops getting security fixes - RHEL 5 is the one platform that warrants supporting 2.4 IMO) In my mind, it means 1.7 needs to be stable. Ondrej (and others) work to make sure we break neither API or ABI since a few releases would help achieving that. David As a user stuck with Python 2.4 for an undefined period of time, I would definitely appreciate a long-term support release that would retain Python 2.4 compatibility. -=- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Le jeudi 28 juin 2012 15:33:07, Travis Oliphant a écrit : There are some good ideas here. I propose splitting this list into devel and users lists. This might best be done by creating a new list for users and using this list for development. I second that idea. As one of the silent users of the list, with not (so) much interest in the details of the development (and even less in the public display of personal dislikes , I'd be happy to switch to a more users-oriented list. Éric. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jun 27, 2012, at 11:38 PM, srean srean.l...@gmail.com wrote: Hi List, this has been brought up several times, and the response has been generally positive but it has fallen through the cracks. So here are a few repeat requests. Am keeping it terse just for brevity i) Split the list into [devel] and [help] and as was mentioned recently [rant/flame]: some request for help get drowned out during active development related discussions and simple help requests pollutes more urgent development related matters. ii) Stackoverflow like site for help as well as for proposals. The silent majority has been referred to a few times recently. I suspect there does exist many lurkers on the list who do prefer one discussed solution over the other but for various reasons do not break out of their lurk mode to send a mail saying I prefer this solution. Such an interface will also help in keeping track of the level of support as compared to mails that are larges hunks of quoted text with a line or two stating ones preference or seconding a proposal. One thing I have learned from traffic accidents is that if one asks for a help of the assembled crowd, no one knows how to respond. On the other hand if you say hey there in a blue shirt could you get some water you get instant results. So pardon me for taking the presumptuous liberty to request Travis to please set it up or delegate. Splitting the lists shouldn't be hard work, setting up overflow might be more work in comparison. Best -- srean ___ 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 -- Un clavier azerty en vaut deux -- Éric Depagnee...@depagne.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
On Thu, Jun 28, 2012 at 7:25 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? As a tangential point, MPL is dropping support for python2.4 in it's next major release. As such we have put a lot of effort in making our upcoming point release extremely stable since it is likely to be the last 2.4 release. Our next major release, either designated 1.2 or 2.0 TBT) will have python3 support, and it seemed to much to try and support python versions from 2.4 on up. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
Hi Travis, On Thu, Jun 28, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? I think it would depend on 1.7 state. I am unwilling to drop support for 2.4 in 1.8 unless we make 1.7 a LTS, that would be supported up to 2014 Q1 (when RHEL5 stops getting security fixes - RHEL 5 is the one platform that warrants supporting 2.4 IMO) +1 for the LTS requirement. There are many people out there who cannot/wantnot install their own python just to support a new NumPy release. Unless, of course, there's compelling reasons to drop support for Python 2.4 (almost) immediately. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Similar to http://scicomp.stackexchange.com there is http://meta.programmers.stackexchange.com/ intended for programmers. Darn it, there are choices involved! I had proposed http://meta.programmers.stackexchange.com/ on this mailing list earlier and no-one seemed interested, but maybe now the time is right. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Did you mean http://programmers.stackexchange.com? The meta sites on *. stackexchange.com are used (as one might guess) for meta discussions on the site. A On Thu, Jun 28, 2012 at 4:58 PM, Cera, Tim t...@cerazone.net wrote: Similar to http://scicomp.stackexchange.com there is http://meta.programmers.stackexchange.com/ intended for programmers. Darn it, there are choices involved! I had proposed http://meta.programmers.stackexchange.com/ on this mailing list earlier and no-one seemed interested, but maybe now the time is right. Kindest regards, Tim ___ 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] Dropping support for Python 2.4 in NumPy 1.8
On Thu, Jun 28, 2012 at 4:44 PM, Olivier Delalleau sh...@keba.be wrote: 2012/6/28 David Cournapeau courn...@gmail.com Hi Travis, On Thu, Jun 28, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? I think it would depend on 1.7 state. I am unwilling to drop support for 2.4 in 1.8 unless we make 1.7 a LTS, that would be supported up to 2014 Q1 (when RHEL5 stops getting security fixes - RHEL 5 is the one platform that warrants supporting 2.4 IMO) In my mind, it means 1.7 needs to be stable. Ondrej (and others) work to make sure we break neither API or ABI since a few releases would help achieving that. David As a user stuck with Python 2.4 for an undefined period of time, I would definitely appreciate a long-term support release that would retain Python 2.4 compatibility. Hi, I have an honest question for you (and other 2.4 users). Many packages have long since dropped 2.4 compatibility. IPython and scikit-learn require 2.6 as a minimum, scikits-image and statsmodels 2.5. So what do you do about those packages, not use them at all, or use an older version? All those packages are improving (in my opinion) at a much faster rate than numpy. So if you do use them, up-to-date versions of those are likely to be more useful than a new version of numpy. In that light, does keeping 2.4 support really add significant value for you? Regards, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dot() function question
Warren Weckesser warren.weckes...@enthought.com writes: In [6]: a = array([1, -2, 3]) In [7]: outer(a, a) Out[7]: array([[ 1, -2, 3], [-2, 4, -6], [ 3, -6, 9]]) Warren Thanks, It is much nicer then my method of adding a zero column. Petro. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dropping support for Python 2.4 in NumPy 1.8
2012/6/28 Ralf Gommers ralf.gomm...@googlemail.com On Thu, Jun 28, 2012 at 4:44 PM, Olivier Delalleau sh...@keba.be wrote: 2012/6/28 David Cournapeau courn...@gmail.com Hi Travis, On Thu, Jun 28, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? I think it would depend on 1.7 state. I am unwilling to drop support for 2.4 in 1.8 unless we make 1.7 a LTS, that would be supported up to 2014 Q1 (when RHEL5 stops getting security fixes - RHEL 5 is the one platform that warrants supporting 2.4 IMO) In my mind, it means 1.7 needs to be stable. Ondrej (and others) work to make sure we break neither API or ABI since a few releases would help achieving that. David As a user stuck with Python 2.4 for an undefined period of time, I would definitely appreciate a long-term support release that would retain Python 2.4 compatibility. Hi, I have an honest question for you (and other 2.4 users). Many packages have long since dropped 2.4 compatibility. IPython and scikit-learn require 2.6 as a minimum, scikits-image and statsmodels 2.5. So what do you do about those packages, not use them at all, or use an older version? All those packages are improving (in my opinion) at a much faster rate than numpy. So if you do use them, up-to-date versions of those are likely to be more useful than a new version of numpy. In that light, does keeping 2.4 support really add significant value for you? I just don't use any package that is not Python 2.4-compatible. The application I currently work with requires numpy, scipy and theano. I might not need new features from newer numpy versions (not sure), but fixes for bugs and future compatibility issues that may come up would be nice. -=- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
You are correct, I meant http://programmers.stackexchange.com/ And on a site like stackexchange I could actually edit my post instead of my mistake being permanent. :-) Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] memory allocation at assignment
Hi, Le 28/06/2012 15:35, Travis Oliphant a écrit : It really is inplace. As Nathaniel mentioned --- all ufuncs take an out keyword. The inplace mechanism uses this so that one input and the output are the same. Thanks for the feedback about inplace assignment. On the other hand, just like srean mentionned, I think I also misused the c[:] = a+b syntax. I feel it's a bit confusing since this way of writing the assignment really feels likes it happens inplace. Good to know it's not the case. Best, Pierre signature.asc Description: OpenPGP digital signature ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
A little more research shows that we could have a http://numpy.stackexchange.com. The requirements are just to have people involved. See http://area51.stackexchange.com/faq for more info. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
If I remember correctly there used to be a stackexchange site at ask.scipy.org. It might be good to learn from that experience. I think handling with spam was a significant problem, but am not sure whether that is the reson why it got discontinued. Best srean On Thu, Jun 28, 2012 at 11:36 AM, Cera, Tim t...@cerazone.net wrote: A little more research shows that we could have a http://numpy.stackexchange.com. The requirements are just to have people involved. See http://area51.stackexchange.com/faq for more info. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] memory allocation at assignment
On Thu, Jun 28, 2012 at 9:06 AM, Pierre Haessig On the other hand, just like srean mentionned, I think I also misused the c[:] = a+b syntax. I feel it's a bit confusing since this way of writing the assignment really feels likes it happens inplace. Good to know it's not the case. well, c is being modified in place -- it's the a+b that is creating a new array. so if you have a c around for another purpose (other than to store the result of a+b -- it might make sense to use this approach. Though a little faster might be: c[:] = a c += b -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR (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] dot() function question
On Wed, Jun 27, 2012 at 2:38 PM, x.pi...@gmail.com wrote: How how can I perform matrix multiplication of two vectors? (in matlab I do it like a*a') np.outer is a bit cleaner, I suppose, but you can exactly the same thing you do with matlab if a is a column (single column 2-d array): In [40]: a = np.arange(4).reshape((-1,1)) In [41]: a Out[41]: array([[0], [1], [2], [3]]) In [42]: np.dot(a,a.T) Out[42]: array([[0, 0, 0, 0], [0, 1, 2, 3], [0, 2, 4, 6], [0, 3, 6, 9]]) or, of course, 2 arrays to begin with: In [13]: a = np.arange(4).reshape((4,1)) In [14]: b = np.arange(4).reshape((1,4)) In [15]: np.dot(a,b) Out[15]: array([[0, 0, 0, 0], [0, 1, 2, 3], [0, 2, 4, 6], [0, 3, 6, 9]]) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR (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] memory allocation at assignment
On Thu, Jun 28, 2012 at 7:04 PM, Chris Barker chris.bar...@noaa.gov wrote: On Thu, Jun 28, 2012 at 9:06 AM, Pierre Haessig On the other hand, just like srean mentionned, I think I also misused the c[:] = a+b syntax. I feel it's a bit confusing since this way of writing the assignment really feels likes it happens inplace. Good to know it's not the case. well, c is being modified in place -- it's the a+b that is creating a new array. so if you have a c around for another purpose (other than to store the result of a+b -- it might make sense to use this approach. Though a little faster might be: c[:] = a c += b That should be faster than c[:] = a + b, but still slower than np.add(a, b, out=c). -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-deterministic test failure in master
On Thu, Jun 28, 2012 at 7:13 AM, Pierre Haessig pierre.haes...@crans.org wrote: Hi Nathaniel, Le 27/06/2012 20:22, Nathaniel Smith a écrit : According to the Travis-CI build logs, this code produces non-deterministic behaviour in master: You mean non-deterministic across different builds, not across different executions on the same build, right ? I just ran a small loop : N = 1 N_good = 0 for i in range(N): a = np.arange(5) a[:3] = a[2:] if (a == [2,3,4,3,4]).all(): N_good += 1 print 'good result : %d/%d' % (N_good, N) and got 100 % good replication. Yes, the current hypothesis is that there is one particular Travis-CI machine on which memcpy goes backwards, and so the test fails whenever the build gets assigned to that machine. (Apparently this is actually faster on some CPUs, and new versions of glibc are known to exploit this.) https://github.com/numpy/numpy/pull/324 -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Non-deterministic test failure in master
On Thu, Jun 28, 2012 at 8:06 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Jun 28, 2012 at 7:13 AM, Pierre Haessig pierre.haes...@crans.org wrote: Hi Nathaniel, Le 27/06/2012 20:22, Nathaniel Smith a écrit : According to the Travis-CI build logs, this code produces non-deterministic behaviour in master: You mean non-deterministic across different builds, not across different executions on the same build, right ? I just ran a small loop : N = 1 N_good = 0 for i in range(N): a = np.arange(5) a[:3] = a[2:] if (a == [2,3,4,3,4]).all(): N_good += 1 print 'good result : %d/%d' % (N_good, N) and got 100 % good replication. Yes, the current hypothesis is that there is one particular Travis-CI machine on which memcpy goes backwards, and so the test fails whenever the build gets assigned to that machine. (Apparently this is actually faster on some CPUs, and new versions of glibc are known to exploit this.) see also this: https://bugzilla.redhat.com/show_bug.cgi?id=638477 David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi,
On Thu, Jun 28, 2012 at 7:42 AM, Olivier Delalleau sh...@keba.be wrote:
+1 for a numpy-users list without dev noise.
Moderately strong vote against splitting the mailing lists into devel and user.
As we know, this list can be unhappy and distracting, but I don't
think splitting the lists is the right approach to that problem.
Splitting the lists sends the wrong signal. I'd rather that we show
by example that the developers listen to all voices, and that the
users should expect to become developers. In other words that the
boundary between the user and developer is fluid and has no explicit
boundaries.
As data points, I make no distinction between scipy-devel and
scipy-user, nor cython-devel and cython-user. Policing the
distinction ('please post this on the user mailing list') is a boring
job and doesn't make anyone more cheerful.
I don't believe help questions are getting lost any more than devel
questions are, but I'm happy to be corrected if someone has some data.
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
That is really funny. Looking through the posts, there wasn't any spam (could have been deleted), but it wasn't used as much as I would think. Have to attract people who answer questions. Early on the registration seemed to be a problem. Solace, the software behind ask.scipy.org looks pretty nice, EXCEPT that the last commit was in 2009. On the other have it could be that it has reached perfection. :-) Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
On 6/28/12 2:46 PM, Cera, Tim wrote: That is really funny. Looking through the posts, there wasn't any spam (could have been deleted), but it wasn't used as much as I would think. Have to attract people who answer questions. Early on the registration seemed to be a problem. Solace, the software behind ask.scipy.org http://ask.scipy.org looks pretty nice, EXCEPT that the last commit was in 2009. On the other have it could be that it has reached perfection. :-) I'll just note that askbot.org provides a nice platform for ask.sagemath.org (last commit to askbot was yesterday :). I think it's as easy as 'pip install askbot' [1] Jason [1] http://askbot.org/doc/install.html ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Created NumPy 1.7.x branch
On Thu, Jun 28, 2012 at 5:50 AM, Travis Oliphant tra...@continuum.io wrote: Python in fact has the __future__ imports that help quite a bit for people to start adapting their codes. How about creating a numpy.future module where new, non-backward-compatible APIs could go? That would give the adventurous a way to play with new features (hence getting them better tested) as well as an easier path for gradual migration to the new features by everyone. This may have already been discussed before, forgive me if I'm repeating well-known material. This is a Did you mean to finish a sentence here and hit 'send' earlier than planned? :) Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
In case this changes your mind (or assuages fears) just wanted to
point out that many open source projects do this. It is not about
claiming that one is more important than the other, nor does it
reinforce the idea that developers and users live in separate silos,
but more of directing the mails to different folders. No policing is
required as well, just reply to the author and to the appropriate
list.
Right now reading numpy-discussion@scipy.org feels a lot like drinking
from a fire hydrant when a couple of threads become very active.
This is just anecdotal evidence, but I have had mails unanswered when
there is one or two threads that are dominating the list.
People are human and there will be situations where the top responders
will be overburdened and I think the split will mitigate the problem
somewhat. For whatever reasons, answering help requests are handled
largely by a small set of star responders, though I suspect the answer
is available more widely even among comparitively new users. I am
hoping (a) that with a separate ask for help such enlightened new
users can take up the slack (b) the information gets better organized
(c) we do not impose on users who are not so interested in devel
issues and vice versa. I take interest in devel related issues (apart
from the distracting and what at times seem petty flamewars) and like
reading the numpy source, but dont think every user have similar
tastes neither should they.
Best
Srean
On Thu, Jun 28, 2012 at 2:42 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Thu, Jun 28, 2012 at 7:42 AM, Olivier Delalleau sh...@keba.be wrote:
+1 for a numpy-users list without dev noise.
Moderately strong vote against splitting the mailing lists into devel and
user.
As we know, this list can be unhappy and distracting, but I don't
think splitting the lists is the right approach to that problem.
Splitting the lists sends the wrong signal. I'd rather that we show
by example that the developers listen to all voices, and that the
users should expect to become developers. In other words that the
boundary between the user and developer is fluid and has no explicit
boundaries.
As data points, I make no distinction between scipy-devel and
scipy-user, nor cython-devel and cython-user. Policing the
distinction ('please post this on the user mailing list') is a boring
job and doesn't make anyone more cheerful.
I don't believe help questions are getting lost any more than devel
questions are, but I'm happy to be corrected if someone has some data.
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 1:42 PM, srean srean.l...@gmail.com wrote: In case this changes your mind (or assuages fears) just wanted to point out that many open source projects do this. It is not about claiming that one is more important than the other, nor does it reinforce the idea that developers and users live in separate silos, but more of directing the mails to different folders. No policing is required as well, just reply to the author and to the appropriate list. Yes, I know this split is common, but I don't think it works very well. I see that sympy, for example, has only one mailing list, and that works extremely well. I'd be interested to hear from the Cython and IPython guys as to whether they feel the user / devel split has helped or hurt. Ferando? Dag? And I continue to think it sends the wrong message. My impression is that, at the moment, we numpy-ers are trying to work out what kind of community we are. Are we a developer community, or are we some developers who are users of a library that we rely on, but do not contribute to? The split between a 'user' and a 'developer' carries an idea that is very important - exactly now. So, I (personally) think that exactly now we should not do this. Maybe later when we've really confronted the - ideas - that are the source of the current trouble. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Am 28.06.2012 um 23:07 schrieb Matthew Brett: Hi, On Thu, Jun 28, 2012 at 1:42 PM, srean srean.l...@gmail.com wrote: In case this changes your mind (or assuages fears) just wanted to point out that many open source projects do this. It is not about claiming that one is more important than the other, nor does it reinforce the idea that developers and users live in separate silos, but more of directing the mails to different folders. No policing is required as well, just reply to the author and to the appropriate list. Yes, I know this split is common, but I don't think it works very well. I see that sympy, for example, has only one mailing list, and that works extremely well. I'd be interested to hear from the Cython and IPython guys as to whether they feel the user / devel split has helped or hurt. Ferando? Dag? And I continue to think it sends the wrong message. My impression is that, at the moment, we numpy-ers are trying to work out what kind of community we are. Are we a developer community, or are we some developers who are users of a library that we rely on, but do not contribute to? The split between a 'user' and a 'developer' carries an idea that is very important - exactly now. So, I (personally) think that exactly now we should not do this. Maybe later when we've really confronted the - ideas - that are the source of the current trouble. Let me share the point of view of a typical(?) lurker on this list. I have raised a few questions quite a while back that were very much in user land. I will probably (unfortunately) never actively contribute to the development of numpy but I like to know what's going on. As long as the bulk of postings are technical discussions I am quite happy to receive (and often delete) long threads that are totally above my head. However every once in a while there are these rather personal exchanges (I am loath to call them discussions) that basically clutter up everyones inbox. In principle, I would be happy to just delete them after a very cursory reading like almost all other posts, however, I have to admit they scare me, because this list was a place where even beginning users like myself could ask questions and get very helpful replies. The change in tone due to those discussions is discouraging to post simple questions (at least to me). So if this rather harsh tone of personal arguments is going to continue, I would very much favour a user and a developer list just because it reduces the barrier of asking stupid questions for new users. I would, however, very much prefer this list to go back to the previous style of being very technical with a supposting tone. Then I could still follow the discussions regarding the development of numpy and see some user questions mixed in... Cheers, Hanno ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 2:30 PM, Hanno Klemm kl...@phys.ethz.ch wrote: Am 28.06.2012 um 23:07 schrieb Matthew Brett: Hi, On Thu, Jun 28, 2012 at 1:42 PM, srean srean.l...@gmail.com wrote: In case this changes your mind (or assuages fears) just wanted to point out that many open source projects do this. It is not about claiming that one is more important than the other, nor does it reinforce the idea that developers and users live in separate silos, but more of directing the mails to different folders. No policing is required as well, just reply to the author and to the appropriate list. Yes, I know this split is common, but I don't think it works very well. I see that sympy, for example, has only one mailing list, and that works extremely well. I'd be interested to hear from the Cython and IPython guys as to whether they feel the user / devel split has helped or hurt. Ferando? Dag? And I continue to think it sends the wrong message. My impression is that, at the moment, we numpy-ers are trying to work out what kind of community we are. Are we a developer community, or are we some developers who are users of a library that we rely on, but do not contribute to? The split between a 'user' and a 'developer' carries an idea that is very important - exactly now. So, I (personally) think that exactly now we should not do this. Maybe later when we've really confronted the - ideas - that are the source of the current trouble. Let me share the point of view of a typical(?) lurker on this list. I have raised a few questions quite a while back that were very much in user land. I will probably (unfortunately) never actively contribute to the development of numpy but I like to know what's going on. As long as the bulk of postings are technical discussions I am quite happy to receive (and often delete) long threads that are totally above my head. However every once in a while there are these rather personal exchanges (I am loath to call them discussions) that basically clutter up everyones inbox. In principle, I would be happy to just delete them after a very cursory reading like almost all other posts, however, I have to admit they scare me, because this list was a place where even beginning users like myself could ask questions and get very helpful replies. The change in tone due to those discussions is discouraging to post simple questions (at least to me). So if this rather harsh tone of personal arguments is going to continue, I would very much favour a user and a developer list just because it reduces the barrier of asking stupid questions for new users. I would, however, very much prefer this list to go back to the previous style of being very technical with a supposting tone. Then I could still follow the discussions regarding the development of numpy and see some user questions mixed in... Yes, I think everyone wants the tone to be better. My very clear impression is that these arguments are signs of stress about real and significant issues, and that when we get down to those issues, and resolve them, then we will be in a better place than we were before. I guess I'm hoping that we can be patient enough to see the shape of the problem that keeps making this stuff happen, Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
On Thu, Jun 28, 2012 at 2:07 PM, Matthew Brett matthew.br...@gmail.com wrote: I see that sympy, for example, has only one mailing list, and that works extremely well. I'd be interested to hear from the Cython and IPython guys as to whether they feel the user / devel split has helped or hurt. Ferando? Dag? There's evidence that projects can work successfully in either mode (single/dual lists), so I don't think this is a completely clear-cut question with a 'right' and a 'wrong' answer. What matters most is finding for each project and community what works best, and I think the main factor should be how truly disjoint are the topics and typical threads of the two lists. Before talking about IPython, we can consider Python itself, where there's a very clear division between the general and dev lists, and even the dev list has been recently split with a new 'ideas' list where more exploratory threads can take place, so that -dev can remain 100% focused on active, concrete development work on the main Python repo. And that strong separation of lists (which python-dev enforces strictly by calmly but firmly redirecting threads to other lists as soon as they seem off-topic for the narrow python-dev focus), seems to work pretty well for them. As far as IPython, I personally do prefer the separated lists, and I think it works quite well for us. IPython is a project often used by python beginners for simple learning of basic programming, and they just want to know how to tab-complete or how to get plots to run in non-blocking mode. Our -dev list is relatively high-traffic and with a weird mix of topics, given the rather eclectic nature of IPython: we have qt discussions, parallel computing, low-level networking/zeromq, javascript/web issues, protocol API threads, etc. All that can be overwhelming for novices (though obviously one hopes that novices would gradually learn from that and become interested in being developers). I think this is how I'd summarize it: - having two lists is friendlier to beginners, as it gives them an environment in which to ask questions that they may feel more comfortable in, because the level of the discussions tends to be not as complex as what happens in a -dev list. - but the cost it has is that it insulates users a bit more from the development ideas, perhaps lowering the likelihood that they will catch on to the development conversations and dig deeper into the project. My cartoon view of it would be: a. novice person | user list || dev list b. novice person || combined list where the | bars indicate 'barriers': in (a), a novice has a low barrier to become a good user, but a higher barrier to transfer into developer. With (b), there is no clear barrier to becoming a developer, but it's more intimidating for new users to join. I have heard (but I only have anecdotal evidence) of users saying that they feel more comfortable asking questions in user-only lists because of the level of the discussion, and that they can read all messages and learn something without having to filter threads that are way over their heads. Long answer, I know... But in short, I'm happy having two lists for IPython: I prefer to have the first transition (gaining active users) to be the easiest to make, because I think once users have become confident, the cost of digging deeper into development is actually pretty low. But I'm sure other projects can and have successfully made the opposite choice. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 2:57 PM, Fernando Perez fperez@gmail.com wrote: On Thu, Jun 28, 2012 at 2:07 PM, Matthew Brett matthew.br...@gmail.com wrote: I see that sympy, for example, has only one mailing list, and that works extremely well. I'd be interested to hear from the Cython and IPython guys as to whether they feel the user / devel split has helped or hurt. Ferando? Dag? There's evidence that projects can work successfully in either mode (single/dual lists), so I don't think this is a completely clear-cut question with a 'right' and a 'wrong' answer. What matters most is finding for each project and community what works best, and I think the main factor should be how truly disjoint are the topics and typical threads of the two lists. Before talking about IPython, we can consider Python itself, where there's a very clear division between the general and dev lists, and even the dev list has been recently split with a new 'ideas' list where more exploratory threads can take place, so that -dev can remain 100% focused on active, concrete development work on the main Python repo. And that strong separation of lists (which python-dev enforces strictly by calmly but firmly redirecting threads to other lists as soon as they seem off-topic for the narrow python-dev focus), seems to work pretty well for them. As far as IPython, I personally do prefer the separated lists, and I think it works quite well for us. IPython is a project often used by python beginners for simple learning of basic programming, and they just want to know how to tab-complete or how to get plots to run in non-blocking mode. Our -dev list is relatively high-traffic and with a weird mix of topics, given the rather eclectic nature of IPython: we have qt discussions, parallel computing, low-level networking/zeromq, javascript/web issues, protocol API threads, etc. All that can be overwhelming for novices (though obviously one hopes that novices would gradually learn from that and become interested in being developers). I think this is how I'd summarize it: - having two lists is friendlier to beginners, as it gives them an environment in which to ask questions that they may feel more comfortable in, because the level of the discussions tends to be not as complex as what happens in a -dev list. - but the cost it has is that it insulates users a bit more from the development ideas, perhaps lowering the likelihood that they will catch on to the development conversations and dig deeper into the project. My cartoon view of it would be: a. novice person | user list || dev list b. novice person || combined list where the | bars indicate 'barriers': in (a), a novice has a low barrier to become a good user, but a higher barrier to transfer into developer. With (b), there is no clear barrier to becoming a developer, but it's more intimidating for new users to join. I have heard (but I only have anecdotal evidence) of users saying that they feel more comfortable asking questions in user-only lists because of the level of the discussion, and that they can read all messages and learn something without having to filter threads that are way over their heads. Long answer, I know... But in short, I'm happy having two lists for IPython: I prefer to have the first transition (gaining active users) to be the easiest to make, because I think once users have become confident, the cost of digging deeper into development is actually pretty low. But I'm sure other projects can and have successfully made the opposite choice. Fernando - you told me a week or so ago that you'd come across a blog post or similar advocating a single list - do you remember the reference? Thanks, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
And I continue to think it sends the wrong message. Maybe if you articulate your fears I will be able to appreciate your point of view more. My impression is that, at the moment, we numpy-ers are trying to work out what kind of community we are. Are we a developer community, or are we some developers who are users of a library that we rely on, but do not contribute to? I think it is fair to extrapolate that all of us would want the numpy community to grow. If that be so at some point not all of the users will be developers. Apart from ones own pet projects, all successful projects have more users than active developers. What I like about having two lists is that on one hand it does not prevent me or you from participating in both, on the other hand it allows those who dont want to delve too deeply in one aspect or the other, the option of a cleaner inbox, or the option of having separate inboxes. I for instance would like to be in both the lists, perhaps mostly as a lurker, but still would want to have two different folders just for better organization. To me this seems a win win. There is also a chance that more lurkers would speak up on the help list than here and I think that is a good thing. Best srean ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Could not have said this better even if I tried, so thank you for your long answer. -- srean On Thu, Jun 28, 2012 at 4:57 PM, Fernando Perez fperez@gmail.com wrote: Long answer, I know... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
On Thu, Jun 28, 2012 at 3:03 PM, Matthew Brett matthew.br...@gmail.com wrote: Fernando - you told me a week or so ago that you'd come across a blog post or similar advocating a single list - do you remember the reference? Found it after some digging: http://www.kitware.com/blog/home/post/263 and upon rereading it, it doesn't really advocate anything specific about mailing lists, just talking in general about a project considering all of its constituents as a single community, rather than two groups. And in that view, one can even argue that a single community can still benefit from multiple lists, much like the python developers have agreed to have python-dev and python-ideas as a way of triaging exploratory discussions form day-to-day work. But that's the post I had mentioned to you: I probably read it thinking about mailing lists as I went, which is why I think I misquoted it somewhat to you. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 3:06 PM, srean srean.l...@gmail.com wrote: And I continue to think it sends the wrong message. Maybe if you articulate your fears I will be able to appreciate your point of view more. Ah - I'm afraid I don't know how to say what I mean more clearly :( I can repeat myself, more or less, to say that this split both encapsulates a distinction that I think we should not make, and distracts from the fundamental issues at stake behind the recent discussions. I suppose I'd add that it does some harm to seek technical solutions for fundamental societal problems. The technical solution may be more or less neutral in effect, but it takes the focus off the problem we should be dealing with. The joke about the drunk under a lamp post looking for his keys. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
On Thu, Jun 28, 2012 at 3:06 PM, srean srean.l...@gmail.com wrote: What I like about having two lists is that on one hand it does not prevent me or you from participating in both, on the other hand it allows those who dont want to delve too deeply in one aspect or the other, the option of a cleaner inbox, or the option of having separate inboxes. I for instance would like to be in both the lists, perhaps mostly as a lurker, but still would want to have two different folders just for better organization. I just want to mention that even as a project leader, I benefit from this: when I'm swamped, I simply ignore the user list. Not a nice thing to do, perhaps, but given the choice between moving the project forward and helping a new user, with often very limited time, I think it's the best solution possible. Of course I do help in the user list when I can, but I mostly encourage more experienced users to help new ones, so that our small dev team can spend its limited time moving the project forward. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 3:20 PM, Fernando Perez fperez@gmail.com wrote: On Thu, Jun 28, 2012 at 3:03 PM, Matthew Brett matthew.br...@gmail.com wrote: Fernando - you told me a week or so ago that you'd come across a blog post or similar advocating a single list - do you remember the reference? Found it after some digging: http://www.kitware.com/blog/home/post/263 and upon rereading it, it doesn't really advocate anything specific about mailing lists, just talking in general about a project considering all of its constituents as a single community, rather than two groups. And in that view, one can even argue that a single community can still benefit from multiple lists, much like the python developers have agreed to have python-dev and python-ideas as a way of triaging exploratory discussions form day-to-day work. I'm not on the python mailing lists, but my impression is that python is in a different space from numpy. I mean, I have the impression (I may be wrong) that python already has a clear idea about how work gets done and how decisions are made. There's a mature PEP process and clear precedent for the process of working through difficult decisions. Numpy lacks this, and more fundamentally, does not appear to be sure to what extent it is a community project in the sense that I've understood it from other projects around us - like - say - IPython, sympy, and so on. So, it may not make sense to think in terms of a model that works for Python, or even, IPython. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
I'm not on the python mailing lists, but my impression is that python is in a different space from numpy. I mean, I have the impression Indeed one could seek out philosphical differences between different projects. No two projects are the same but they can and often do have common issues. About the issues that Fernando mentioned I can say that they are real, they do apply and this I say from a from the experience of being on the numpy mailing list. I think that many silent numpy users will thank the creation of a low barrier, low noise (noise is context sensitive) forum where they can ask for help with what they feel are simple questions with easy answers. I still do not have a tangible grasp of what your fears are. It seems you are unhappy that this will split the community. It wont, its just two lists for the same community where mails have been sorted into different folders. It also seems the notion of developers and users is disagreeable to you and you are philosophically hesitant about accepting/recognizing that such a difference exists. I may be wrong, I do not intend to speak for you, I am only trying to understand your objections. First let me assure you they are labels on (temporary) roles not on a person (if that is what is making you uncomfortable). Different people occupy different states for different amounts of time. A question about how to run length decode an array of integers is very different from a question on which files to touch to add reduceat( ) support to the numexpression engine and how. It would be strange to take the position that there is no difference between the nature of these questions. Or to take the position that the person who is interest in the former is also keen to learn about the former (note: some would be, example: yours sincerely. I know the former ot the latter ) or at the least keen on receiving mails on extended discussion on the topic of lesser interest. It seems to me, that sorting these mails into different bins only improves the contextual signal to noise ratio, which the recipient can use as he/she feels fit. The only issue is if there will be enough volume for each of these bins. My perception is yes but this can certainly be revisited. In anycase it does not prevent nor hinder any activity, but allows flexible organization of content should one want it. So, it may not make sense to think in terms of a model that works for Python, or even, IPython. I do not want to read too much into this, but this I do find kind of odd and confusing: to proactively solicit input from other related projects but then say that do do not apply once the views expressed werent in total agreement. This thread is coming close to veer into the non-technical/non-productive/argumentative zone. The type that I am fearful off, so I will stop here. But I would encourage you to churn these views in your mind, impersonally, to see if the idea of different lists have any merit and to seek out what are the tangible harm that can come out of it. I think this request has come before (hasten to add not initiated by me) and the response had been largely been in favor, but nothing has happened. So I would welcome information on: if indeed two lists are to be made, who gets to create those lists Best, srean ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
On Thu, Jun 28, 2012 at 3:23 PM, Fernando Perez fperez@gmail.comwrote: On Thu, Jun 28, 2012 at 3:06 PM, srean srean.l...@gmail.com wrote: What I like about having two lists is that on one hand it does not prevent me or you from participating in both, on the other hand it allows those who dont want to delve too deeply in one aspect or the other, the option of a cleaner inbox, or the option of having separate inboxes. I for instance would like to be in both the lists, perhaps mostly as a lurker, but still would want to have two different folders just for better organization. I just want to mention that even as a project leader, I benefit from this: when I'm swamped, I simply ignore the user list. Not a nice thing to do, perhaps, but given the choice between moving the project forward and helping a new user, with often very limited time, I think it's the best solution possible. Of course I do help in the user list when I can, but I mostly encourage more experienced users to help new ones, so that our small dev team can spend its limited time moving the project forward. I'm okay with having two lists as it does filtering for me, but this seems like a sub-optimal solution. Observation: Some people would like to apply labels to incoming messages. Reality: Email was not really designed for that. We can hack it by using two different email addresses, but why not just keep this list as is and make a concentrated effort to promote the use of 2.0 technologies, like stackoverflow/askbot/etc? There, people can put as many tags as desired on questions: matrix, C-API, iteration, etc. Potentially, these tags would streamline everyone's workflow. The stackoverflow setup also makes it easier for users to search for solutions to common questions, and know that the top answer is still an accurate answer. [No one likes finding old invalid solutions.] The reputation system and up/down votes also help new users figure out which responses to trust. As others have explained, it does seem that there are distinct types of discussions that take place on this list. 1) There are community discussiuons/debates. Examples are the NA discussion, the bug tracker, release schedule, ABI/API changes, matrix rank tolerance too low, lazy evaluation, etc. These are clearly mailing-list topics. If you look at all the messages for the last two(!) months, it seems like this type of message has been the dominate type. 2) There are also standard questions. Recent examples are memory allocation at assignment, dot() function question, not expected output of fill_diagonal, silly isscalar question. These messages seem much more suited to the stackoverflow environment. In fact, I'd be happy if we redirected such questions to stackoverflow. This has the added benefit that responses to such questions will stay on topic. Note that if a stackoverflow question seeds a discussion, then someone can start a new thread on the mailing list which cite the stackoverflow question. tl;dr Keep this list the same, and push user questions to stackoverflow instead of pushing them to a user list. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] PyArray_FILLWBYTE dangerous doc
Hi, The doc of PyArray_FILLWBYTE here http://docs.scipy.org/doc/numpy/reference/c-api.array.html is this PyArray_FILLWBYTE(PyObject* obj, int val) Fill the array pointed to by obj —which must be a (subclass of) bigndarray—with the contents of val (evaluated as a byte). In the code, what it does is call memset: numpy/core/include/numpy/ndarrayobject.h #define PyArray_FILLWBYTE(obj, val) memset(PyArray_DATA(obj), val, \ PyArray_NBYTES(obj)) This make it ignore completely the strides! So the easy fix would be to update the doc, the real fix is to test the contiguity before calling memset, if not contiguous, call something else appropriate. Fred ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
I like this solution and I think ask.scipy.org can be revived to take over that role, but this will need some policing to send standard questions there and also some hangout time at ask.scipy.org. I love the stackoverflow model but it requires more active participation of those who want to answer questions as compared to mailing lists. This because questions not only do not come to you by default but they also get knocked off the top page as more questions come in. Something to watch out for though I believe it wont be as bad as the main SO site. Meta^2 I have been top posting with abandon here. Not sure what is preferred here, top or bottom. Best srean On Thu, Jun 28, 2012 at 8:52 PM, T J tjhn...@gmail.com wrote: On Thu, Jun 28, 2012 at 3:23 PM, Fernando Perez fperez@gmail.com wrote: I'm okay with having two lists as it does filtering for me, but this seems like a sub-optimal solution. Observation: Some people would like to apply labels to incoming messages. Reality: Email was not really designed for that. We can hack it by using two different email addresses, but why not just keep this list as is and make a concentrated effort to promote the use of 2.0 technologies, like stackoverflow/askbot/etc? There, people can put as many tags as desired on questions: matrix, C-API, iteration, etc. Potentially, these tags would streamline everyone's workflow. The stackoverflow setup also makes it easier for users to search for solutions to common questions, and know that the top answer is still an accurate answer. [No one likes finding old invalid solutions.] The reputation system and up/down votes also help new users figure out which responses to trust. As others have explained, it does seem that there are distinct types of discussions that take place on this list. 1) There are community discussiuons/debates. Examples are the NA discussion, the bug tracker, release schedule, ABI/API changes, matrix rank tolerance too low, lazy evaluation, etc. These are clearly mailing-list topics. If you look at all the messages for the last two(!) months, it seems like this type of message has been the dominate type. 2) There are also standard questions. Recent examples are memory allocation at assignment, dot() function question, not expected output of fill_diagonal, silly isscalar question. These messages seem much more suited to the stackoverflow environment. In fact, I'd be happy if we redirected such questions to stackoverflow. This has the added benefit that responses to such questions will stay on topic. Note that if a stackoverflow question seeds a discussion, then someone can start a new thread on the mailing list which cite the stackoverflow question. tl;dr Keep this list the same, and push user questions to stackoverflow instead of pushing them to a user list. ___ 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] Meta: help, devel and stackoverflow
Hi, On Thu, Jun 28, 2012 at 7:50 PM, srean srean.l...@gmail.com wrote: I like this solution and I think ask.scipy.org can be revived to take over that role, but this will need some policing to send standard questions there and also some hangout time at ask.scipy.org. Sounds like a good idea to me too. If someone points me at it when the time comes, I'm happy to do hangout duty too. I love the stackoverflow model but it requires more active participation of those who want to answer questions as compared to mailing lists. This because questions not only do not come to you by default but they also get knocked off the top page as more questions come in. Something to watch out for though I believe it wont be as bad as the main SO site. Meta^2 I have been top posting with abandon here. Not sure what is preferred here, top or bottom. Me I prefer posting under the relevant stuff, but I don't think you'll get any flak either way. Cheers, matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
