Perry Greenfield wrote:

Hi Travis,

Who is helping organize this year's conference besides you. I'm thinking I may want to help, particularly in involving the astronomical community more. The next month isn't that good for me but I'd like to be involved if that is of interest to you (i.e., with the program and such). If you are interested, what is your schedule of activities for planning the conference?

Thanks, Perry Hey Perry (and anyone else interested in helping),

I'm open to any help we can get to organize the conference (thus the cross-post to scipy-dev)--thanks for the willingness to pitch in. It's probably useful to give a breakdown of all the tasks (at least the one's I can think of right now): Abstracts Review/Speaker Recruitment & Acceptance ------------------------------------------------- This has traditionally been under the purview of the co-sponsors, represented by me, Eric Jones, Michael Aivazis and Michel Sanner. If anyone would like to participate, let us know and we'll organize a committee to do this with more rigor. I think there's a lot of potential in this area that, frankly, has gone untapped. Organize Auxiliary Sessions --------------------------- Several things to do here, particularly in accommodating the various sub-communities like astronomy, biology, etc. This may be a good area for you to pitch in, Perry.: - Organize Sprint projects - Organize Tutorials - Initiate and moderate conversation about BOF interests and organize BOF meeting times. Marketing the Conference ------------------------ We have largely relied on the usual mailing lists to get the word out about the conference. We could definitely have a broader campaign here. I think we could reasonably accommodate 50% more attendees and still have a nice collaborative environment. Some things that come immediately to mind are: - A prominent announcement on the python.org home page & encouraging other PSF involvement (sponsorship of a speaker(s), a sprint, student attendees?) - Announce/articles on other sites/blogs. - Better follow-up reminders for registration. - Targeting particular folks in various Organizations/Universities/Labs to spread the word internally. - Pitch in on keeping the scipy site updated, graphics, etc. - Any other ideas? Sponsorship/Encouragement of Student Participation -------------------------------------------------- There has been some discussion about ways to encourage more students to attend the meeting. Because of our goal of keeping registration costs low, we don't have funds to physically bring students to the conference. We could possibly waive student registration fees, or recruit organizations to sponsor student attendance. We could organize Sprints/Tutorials/BOFs specifically for this sort of group. Of course there's also the issue of getting the word out and targeting interested students. Any ideas? Event Planning -------------- The wonderful folks at CalTech handle this superbly. All planning for meals, meeting rooms, A/V, parking, nametags, check-in, etc. are pretty much taken care of by them--an amazing thing, really. So, not much to do here (thankfully). Ideas? ------ We're interested in any ideas to make this a compelling, productive time--I'm sure I'm forgetting/missing some things. Now, to actually answer your question about the schedule for the Conference planning. Here are some dates: --Between now and June, we should try to build a schedule of tutorials and sprint projects. We should follow up with threads for this. I've created wiki stubs to hold the results: http://www.scipy.org/SciPy2006/TutorialSessions http://www.scipy.org/SciPy2006/CodingSprints -- June 30,2006: Arbitrary target date for preliminary Sprint & Tutorial Schedule --manage 'registration' of tutorial and sprint attendees-- July 7, 2006: Presentation Abstracts Due --week of reviewing abstracts and defining the schedule-- July 14, 2006: Accept/announce presentation schedule July 14, 2006: Early registration deadline --Figure out a BOF schedule sometime in August and announce at the Conference-- We're a bit flexible on this, so suggestions are welcome. Thanks again, Perry. Travis

We've noticed that in numpy that the where() function behaves differently than for numarray. In numarray, where() (when used with a mask or condition array only) always returns a tuple of index arrays, even for the 1D case whereas numpy returns an index array for the 1D case and a tuple for higher dimension cases. While the tuple is a annoyance for users when they want to manipulate the 1D case, the benefit is that one always knows that where is returning a tuple, and thus can write code accordingly. The problem with the current numpy behavior is that it requires special case testing to see which kind return one has before manipulating if you aren't certain of what the dimensionality of the argument is going to be. I'd like to raise the issue of whether or not numpy should change the behavior. We often deal with both 1D and 2D arrays so it is an inconvenience for us. How many others deal with this and have an opinion on which way it should work. There is no difference in using the result for where() as an index in any case. Tuples are handled transparently, even for the 1-d case. For example (for numarray):

...

...

x = arange(10) ind = where(x > 6) print x[ind] [7 8 9] print ind (array([7, 8, 9]),)

So to access the actuall index array, one must index the tuple, e.g.: ind[0][:2] Thoughts? Perry