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
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) :).
Hi, As a humble but happy SciPy user, I have some reservations about this project. I didn't notice the discussion before, so maybe I'm talking about points already discussed; however...
Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available.
I'd second that for sure. People should see what it is possible to do with scipy, not only see what is in scipy.
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.
This looks hellish to me. People have already (often) an hard time contributing to OSS projects, for varous reasons, time being one of the most scarce resources. Requiring them *not only* to write documentation (which is good and must be required) but to write an article too seems at risk of putting a lot of people off. Why description of algorithms etc. cannot be made inside official documentation/wiki/website?
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.
Why cannot this be done in a wiki/website/changelog?
b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals.
Why cannot this be done in a wiki/website?
c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here
Why having a journal will help developing clever new algorithms?
d) provide a peer-review publication opportunity for people who contribute to open-source software
This is probably the most interesting aspect. Are you willing to do an official, peer-reviewed academic journal that can be, for example, cited and that will be indexed by databases like PubMed, Scirus and ISI Web Of Science, for example? If yes, I second that (albeit I find a Scipy Journal an extremely small niche -perhaps a Python Scientific Programming Journal, extended to non-scipy projects, would be better). If not, I don't understand what's the point.
The SciPy Journal would be a great place to document both of these things while describing the spline interpolation design of scipy.interpolate
Why a well made wiki page cannot be a great place?
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).
That's exactly why I dislike the idea of a journal. Scientific research is beginning to move very slowly but steadily away from the classic "academic journal" idea. arXiv, PLoS and company are just the beginning. In the not-so-distant future probably most scientific debate and publishing will go purely web, on collaborative websites, with journals just being places where already done discussions etc. will be somehow officialized. So that's why I do not second the idea of a journal. It just makes sense no more. A well done, collaborative (wiki or wiki-like) web site would be much friendlier and better.
Comments and feedback is welcome.
Here is mine, even if not so positive :) m. -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: massimo.sandal@unibo.it tel: +39-051-2094388 fax: +39-051-2094387
c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here
Why having a journal will help developing clever new algorithms?
The purpose of research is developping new algorithms, having a journal which, hopefully, will be a "free" reference in a field will involve more people looking at Scipy, using Scipy and actually developping new algorithms. This is probably the most interesting aspect. Are you willing to do an
official, peer-reviewed academic journal that can be, for example, cited and that will be indexed by databases like PubMed, Scirus and ISI Web Of Science, for example?
If yes, I second that (albeit I find a Scipy Journal an extremely small niche -perhaps a Python Scientific Programming Journal, extended to non-scipy projects, would be better). If not, I don't understand what's the point.
Same here, as stated before. That's exactly why I dislike the idea of a journal. Scientific research
is beginning to move very slowly but steadily away from the classic "academic journal" idea. arXiv, PLoS and company are just the beginning. In the not-so-distant future probably most scientific debate and publishing will go purely web, on collaborative websites, with journals just being places where already done discussions etc. will be somehow officialized. So that's why I do not second the idea of a journal. It just makes sense no more. A well done, collaborative (wiki or wiki-like) web site would be much friendlier and better.
Here in France, publications in journals indicate how much money a lab will have. It is flawed approach, but we have to live with it. Moreover, students and researchers have to make publications in journals, the former so as to have a job in the near future, the latter so as to catch good elements for their lab. Having a journal will help scientists in discovering Python and scipy, and having such a journal will drag good scientists too, it's a virtuous circle, if it can be started. And having a good journal will be a good opportunity for scientists to make something different than a documentation, something they want to spend time for. Hindawi journals use a similar principle - although it is not free for publication, it is free for access - Matthieu
Matthieu Brucher ha scritto:
> c) hopefully clever new algorithms will be developed for SciPy by > people using Python > that could be show-cased here
Why having a journal will help developing clever new algorithms?
The purpose of research is developping new algorithms, having a journal which, hopefully, will be a "free" reference in a field will involve more people looking at Scipy, using Scipy and actually developping new algorithms.
But who would publish good purely algorithmic research on "Scipy J."? If you have a new, clever algorithm, you publish that on a computational science journal, I think, and you can show a scipy implementation in the article itself. Much more mainstream, and same visibility for scipy. Where am I wrong?
Here in France, publications in journals indicate how much money a lab will have. It is flawed approach, but we have to live with it. Moreover, students and researchers have to make publications in journals, the former so as to have a job in the near future, the latter so as to catch good elements for their lab.
Same here. The problem is, will someone publish it? Will it gain academic respectability? An academic journal revolving around a single software library seems very odd to me -is there a, let's say, "GLIBC Journal" somewhere? Maybe that's just me being ignorant. Also: what can be published on Scipy J. that couldn't be fit well in a)bioinformatics/astro-informatics/$DISCIPLINE-informatics journals b)computer science journals?
Having a journal will help scientists in discovering Python and scipy, and having such a journal will drag good scientists too, it's a virtuous circle, if it can be started. And having a good journal will be a good opportunity for scientists to make something different than a documentation, something they want to spend time for.
Yes, the problem is: can it ever be a decent journal? -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: massimo.sandal@unibo.it tel: +39-051-2094388 fax: +39-051-2094387
massimo sandal wrote:
Same here. The problem is, will someone publish it? Will it gain academic respectability? An academic journal revolving around a single software library seems very odd to me -is there a, let's say, "GLIBC Journal" somewhere? Maybe that's just me being ignorant.
Look at the "Journal of Statistical Software". Its name might as well be the "Journal of R". http://www.jstatsoft.org/ Note that we are intending the Scipy Journal to be freely published online, too. There is no question of finding someone to publish it for us. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern ha scritto:
massimo sandal wrote:
Same here. The problem is, will someone publish it? Will it gain academic respectability? An academic journal revolving around a single software library seems very odd to me -is there a, let's say, "GLIBC Journal" somewhere? Maybe that's just me being ignorant.
Look at the "Journal of Statistical Software". Its name might as well be the "Journal of R".
LOL. Still, I don't feel convinced it's a worthwile idea (J.Stat.Softw. doesn't look like one, either). However, if you want to do it, well, do it. :) It can also be possible I'll contribute to it in the future, if you take into consideration entries about software that uses SciPy. I'd also broaden the scope to take into account NumPy, Matplotlib and in general all science things doing Python. Another interesting requirement could be that algorithms, software etc. presented must show at least one open-source (as defined by OSI) implementation. The only thing I am really worried is the requirement of an article along with documentation for inclusion of code into SciPy. This can have drawbacks. m. -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: massimo.sandal@unibo.it tel: +39-051-2094388 fax: +39-051-2094387
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 (8)
-
Aldarion -
Alexander Michael -
Lou Pecora -
massimo sandal -
Matthieu Brucher -
Nicolas Pettiaux -
Robert Kern -
Travis Oliphant