Hi everybody, I'm sorry for the cross posting, but I wanted to reach a wide audience and I know not everybody subscribes to all the lists. I've been thinking more about the "SciPy Journal" that we discussed before and I have some thoughts. 1) I'd like to get it going so that we can push out an electronic issue after the SciPy conference (in September) 2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available. 3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used. 4) The purpose of the journal as I see it is to a) provide someplace to document what is actually done in SciPy and related software. b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals. c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here d) provide a peer-review publication opportunity for people who contribute to open-source software 5) We obviously need associate editors and people willing to review submitted articles as well as people willing to submit articles. I have two articles that can be submitted within the next two months. What do other people have? As an example of the kind of thing a SciPy Journal would be useful for. I have recently over-hauled the interpolation.py file for SciPy by incorporating the B-spline stuff that is partly in fitpack. In the process I noticed two things: 1) I have (what seems to me) a different recursive algorithm for calculating derivatives of B-splines than I could find in fitpack. 2) I have developed a different way to determine the K-1 extra degrees of freedom for Kth-order spline fitting than I have seen before. The SciPy Journal would be a great place to document both of these things while describing the spline interpolation design of scipy.interpolate It is true that I could submit this stuff to other journals, but it seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet. Given the open nature of most scientific research, it is remarkable that getting access to the information is not as easy as it should be with modern search engines (if your internet domain does not subscribe to the e-journal). Comments and feedback is welcome. -Travis
On 31/05/07, Travis Oliphant <oliphant.travis@ieee.org> wrote:
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
I think there's a place for code that doesn't fit in scipy itself but could be closely tied to it - scikits, for example, or other code that can't go in for license reasons (such as specialization).
3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.
I don't think that's a good idea. It raises the barrier to contributing code (particularly for non-native English speakers), which is not something we need. Certainly every major piece of code warrants a journal article, or at least a short piece, and certainly the author should have first shot, but I think it's not unreasonable to allow the code to go in without the article being written. But (for example) I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it. Anne M. Archibald
Anne Archibald wrote:
On 31/05/07, Travis Oliphant <oliphant.travis@ieee.org> wrote:
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
I think there's a place for code that doesn't fit in scipy itself but could be closely tied to it - scikits, for example, or other code that can't go in for license reasons (such as specialization).
I did mention scikits, but your point is well taken.
3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.
I don't think that's a good idea. It raises the barrier to contributing code (particularly for non-native English speakers), which is not something we need. Certainly every major piece of code warrants a journal article, or at least a short piece, and certainly the author should have first shot, but I think it's not unreasonable to allow the code to go in without the article being written. But (for example) I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it.
What I envision is multiple "levels" of artciles, much like you see full papers and correspondences in the literature. Something like this should take no more than a 1-4 page letter that describes the algorithm used and references available literature. I still would like to see it though as a means to document what is in SciPy. Of course, I'd like to see more code, but right now we have a problem in deciding what code should go into SciPy and there seems to be no clear way to transition the code from the sandbox into SciPy. This would help in that process I think. I'm always open to help somebody who may have difficulty with English. -Travis
Anne Archibald wrote:
I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it.
It could be a very short article that refers the seminal papers in the existing literature -- that would still be very helpful.
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits.
I don't see any reason to limit it -- honestly, the problem is more likely to be too few articles than too many! Anything that would make sense at the SciPy conference should be fair game. We might want to have a clear structure that isolates the NumPy/SciPy/SciKits articles though. -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.Barker@noaa.gov
Christopher Barker wrote:
Anne Archibald wrote:
I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it.
It could be a very short article that refers the seminal papers in the existing literature -- that would still be very helpful.
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits.
I don't see any reason to limit it -- honestly, the problem is more likely to be too few articles than too many! Anything that would make sense at the SciPy conference should be fair game. We might want to have a clear structure that isolates the NumPy/SciPy/SciKits articles though.
I'm persuaded by this. Yes, we could handle this by the structure so that the code-explaining articles are clear. Perhaps two sections or two publication lists. -Travis
I think this Journal sounds like an excellent idea. I have some python code that calculates the Lyapunov Characteristic Exponents (all of them), for a dynamical system that I would be willing to write about and contribute. Do you envision the articles including applications of the algorithms/ ideas discussed, or simply the presentation and discussion of the algorithms/ideas themselves? ~Luke On May 31, 10:34 am, Travis Oliphant <oliph...@ee.byu.edu> wrote:
Christopher Barker wrote:
Anne Archibald wrote:
I implemented the Kuiper statistic and would be happy to contribute it to scipy (once it's seen a bit more debugging), but it's quite adequately described in the literature already, so it doesn't seem worth writing an article about it.
It could be a very short article that refers the seminal papers in the existing literature -- that would still be very helpful.
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits.
I don't see any reason to limit it -- honestly, the problem is more likely to be too few articles than too many! Anything that would make sense at the SciPy conference should be fair game. We might want to have a clear structure that isolates the NumPy/SciPy/SciKits articles though.
I'm persuaded by this. Yes, we could handle this by the structure so that the code-explaining articles are clear. Perhaps two sections or two publication lists.
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discuss...@scipy.orghttp://projects.scipy.org/mailman/listinfo/numpy-discussion
Luke, I'd love to see that code and the associated article. I do a lot of NLD. --- Luke <hazelnusse@gmail.com> wrote:
I think this Journal sounds like an excellent idea. I have some python code that calculates the Lyapunov Characteristic Exponents (all of them), for a dynamical system that I would be willing to write about and contribute.
-- Lou Pecora, my views are my own. --------------- Great spirits have always encountered violent opposition from mediocre minds. -Albert Einstein ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/
Hi, 1) I'd like to get it going so that we can push out an electronic issue
after the SciPy conference (in September)
That would be great for the "fame" of numpy and scipy :) 2) I think it's scope should be limited to papers that describe
algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
3) I'd like to make a requirement for inclusion of new code in SciPy
that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.
For this point, I have the same opinion as Anne : - having an equivalence between cde and article is raising the entry level, but as Anne said, some code could be somehow too trivial ? - a peer-review process implies that an article can be rejected, so the code is accepted, but not the article and vice-versa ? - perhaps encouraging new contributors to propose an article would be a solution ? 4) The purpose of the journal as I see it is to
a) provide someplace to document what is actually done in SciPy and related software. b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals. c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here d) provide a peer-review publication opportunity for people who contribute to open-source software
+1 for everything, very good idea. 5) We obviously need associate editors and people willing to review
submitted articles as well as people willing to submit articles. I have two articles that can be submitted within the next two months. What do other people have?
I could talk about the design I proposed for generic optimizer, and hopefully I'll have some other generic modules that could be exposed. But it's not in scipy, and it's not an official scikit at the moment. How long should it be - some journals have limits in size, so... - ? I think I could propose one in three months - English is not my mother-tongue and I have a pressing article deadline before - It is true that I could submit this stuff to other journals, but it
seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet.
Given the open nature of most scientific research, it is remarkable that getting access to the information is not as easy as it should be with modern search engines (if your internet domain does not subscribe to the e-journal).
Same for me, I have a hard time figuring why the prices are so high, and that closes the door to very good articles :( Matthieu
Matthieu Brucher wrote:
For this point, I have the same opinion as Anne : - having an equivalence between cde and article is raising the entry level, but as Anne said, some code could be somehow too trivial ? - a peer-review process implies that an article can be rejected, so the code is accepted, but not the article and vice-versa ?
I would like to avoid that. In my mind the SciPy Journal should reflect code that is actually available in the PyLab world. But, I could see having code that is not written about in the journal (the current state, for example...)
- perhaps encouraging new contributors to propose an article would be a solution ?
I could talk about the design I proposed for generic optimizer, and hopefully I'll have some other generic modules that could be exposed. But it's not in scipy, and it's not an official scikit at the moment. How long should it be - some journals have limits in size, so... - ?
In my mind, we electronically publish something every 6 months to start with and then go from there. The "publication" process amounts to a peer-review check on the work, a basic quality check on the type-setting (we will require authors to do their own typesetting), and then a listing of the articles for the specific edition. Page size is not as important as "file size." Each article should be under a few MB. -Travis
2007/5/31, Travis Oliphant <oliphant.travis@ieee.org>:
1) I'd like to get it going so that we can push out an electronic issue after the SciPy conference (in September)
Such a journal is a very good idea indeed. This would also support the credibility of python/scipy/numpy for an academic audience that legitimates scientific productions mostly by articles in journals.
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
More generally, examples of uses of scipy / numpy ... would be interesting in such a journal, as well as simply the proceedings of the scipy conferences.
It is true that I could submit this stuff to other journals, but it seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet.
having *one* main place where much information and documentation, with peer reviewed validation, could be found is IMHO very interesting. Regards, Nicolas -- Nicolas Pettiaux - email: nicolas.pettiaux@ael.be Utiliser des formats ouverts et des logiciels libres - http://www.passeralinux.org
I agree with this idea. Very good. Although I also agree with Anne Archibald that the requirement of an article in the journal to submit code is not a good idea. I would be willing to contribute an article on writing C extensions that use numpy arrays. I already have something on this on the SciPy cookbook, but I bet it would reach more people in a journal. I also suggest that articles on using packages like matplotlib/pylab for scientific purposes also be included. -- Lou Pecora, my views are my own. --------------- Great spirits have always encountered violent opposition from mediocre minds. -Albert Einstein ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
Lou Pecora wrote:
I agree with this idea. Very good. Although I also agree with Anne Archibald that the requirement of an article in the journal to submit code is not a good idea. I would be willing to contribute an article on writing C extensions that use numpy arrays. I already have something on this on the SciPy cookbook, but I bet it would reach more people in a journal.
I also suggest that articles on using packages like matplotlib/pylab for scientific purposes also be included. and Ipython(Ipython1) :).
On 5/31/07, Travis Oliphant <oliphant.travis@ieee.org> wrote:
Hi everybody,
I'm sorry for the cross posting, but I wanted to reach a wide audience and I know not everybody subscribes to all the lists.
I've been thinking more about the "SciPy Journal" that we discussed before and I have some thoughts.
1) I'd like to get it going so that we can push out an electronic issue after the SciPy conference (in September)
2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used.
4) The purpose of the journal as I see it is to
a) provide someplace to document what is actually done in SciPy and related software. b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals. c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here d) provide a peer-review publication opportunity for people who contribute to open-source software
5) We obviously need associate editors and people willing to review submitted articles as well as people willing to submit articles. I have two articles that can be submitted within the next two months. What do other people have?
As an example of the kind of thing a SciPy Journal would be useful for. I have recently over-hauled the interpolation.py file for SciPy by incorporating the B-spline stuff that is partly in fitpack. In the process I noticed two things:
1) I have (what seems to me) a different recursive algorithm for calculating derivatives of B-splines than I could find in fitpack. 2) I have developed a different way to determine the K-1 extra degrees of freedom for Kth-order spline fitting than I have seen before.
The SciPy Journal would be a great place to document both of these things while describing the spline interpolation design of scipy.interpolate
It is true that I could submit this stuff to other journals, but it seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet.
Given the open nature of most scientific research, it is remarkable that getting access to the information is not as easy as it should be with modern search engines (if your internet domain does not subscribe to the e-journal).
Comments and feedback is welcome.
An implementation oriented journal/newsletter in the vain of RNews (<http://cran.r-project.org/doc/Rnews/>) would be great. [Note: I remember seeing some mentions of the R project in various comments, but I am not sure anyone brought RNews as a model. Please excuse me if it was already brought up.] About R News R News is the newsletter of the R project for statistical computing and features short to medium length articles covering topics that might be of interest to users or developers of R, including * Changes in R: new features of the latest release * Changes on CRAN: new add-on packages, manuals, binary distributions, mirrors,... * Add-on packages: short introductions to or reviews of R extension packages * Programmer's Niche: nifty hints for programming in R (or S) * Hints for newcomers: Explaining sides of R that might not be so obvious from reading the manuals and FAQs. * Applications: Examples of analyzing data with R Of course, any write-up of library code should also be distributed with/in the code (doc strings) as well. Such a publication would provide a great outlet for people to write about how they implemented their research and would make a great companion to the publication of the analysis and results. Additionally, the development of a good document template and commendable examples from other contributors would likely encourage better communication as with leading journals. A lot of the material could be culled from the mailing lists and should be written up in a way (and in a format) that would allow it to be dropped into the wiki (e.g. the cookbook page) as well as included in the publication.
participants (10)
-
Aldarion -
Alexander Michael -
Anne Archibald -
Christopher Barker -
Lou Pecora -
Luke -
Matthieu Brucher -
Nicolas Pettiaux -
Travis Oliphant -
Travis Oliphant