Tuesday, August 9, 2011
Call for papers: KES-IIMSS 2012
The deadline for submitting papers to the 5th International Conference on Intelligent Interactive Multimedia Systems and Services (KES IIMSS 2012) is 1st December 2011. This conference will be held in Gifu, Japan, 23-25 May 2012, simultaneously with the 4th International Conference on Intelligent Decision Technologies.
Monday, August 8, 2011
Conference paper deadline: KES-IDT 2012
The deadline for submitting papers to the 4th International Conference on Intelligent Decision Technologies (KES-IDT 2012) is 1 December 2011. This conference will be held in Gifu, Japan, 23-25 May, 2012.
Friday, August 5, 2011
Call for papers: IEEE-IS
The deadline for submitting papers to the IEEE International Conference on Intelligent Systems (IEEE-IS) is 20 December 2011. This conference will be held in Sofia, Bulgaria, September 6-8, 2012.
Thursday, August 4, 2011
Reminder: paper deadline for Collective Intelligence 2012
A reminder that the deadline for papers submitted to the 2012 conference on Collective Intelligence is 4 November, 2011. This conference will be held in Cambridge, Massachusetts, April 18-20, 2012.
Tuesday, August 2, 2011
Reminder: Paper submission deadline for ICCIEA 2011
A reminder that the deadline for papers submitted to the International Conference on Computational Intelligence and Engineering Applications (ICCIEA) 2011 is 1 September 2011. This conference will be held in Bhubaneswar, India, 16-17 October, 2011.
Monday, August 1, 2011
Reminder: paper deadline for EAIS 2012
A reminder that the deadline for submitting papers to the IEEE Workshop on Evolving and Adaptive Intelligent Systems (EAIS) 2012 is 1 November 2011. This conference will be held in Madrid, Spain, 17-18 May, 2012.
Tuesday, July 26, 2011
Software development in science
There are fundamental differences in the way in which scientists and software engineers create software. Here are two posts on two separate blogs, arguing their respective cases about the difference between the software created by scientists and the software created by software engineers. The first argues that the differences are due to culture: scientists view software as a tool that just needs to work, so don't mind doing it quickly and in a less-than-maintainable manner. Software engineers see software as a product, and so spend the time and effort to make software that is maintainable. The second, on the other hand, argues that it is not a cultural difference, but an issue of reproducibility. Being able to reproduce results is extremely important in science - for example, a lack of reproducibility is in part how the fraudulent results of Jan Hendrik Schon were uncovered. Thus, software need to be reproducible and therefore, produce trustworthy results.
As both a software engineer and a working scientist, I tend to agree more with the second argument, but I think that the major problem is that some scientists who code are going too far outside of their area of expertise.
It takes education and a lot of experience to be able to write good code. I've been writing software for more than sixteen years now, and I think I am finally getting to the point that my coding skills are adequate. But that's after earning an honours degree in the field, after spending a couple of years working closely with a truly gifted programmer, and many more years writing software for a wide variety of applications. When I first started writing scientific software, the code I produced wasn't very good: it ran OK, and produced reasonable results, but it was pretty clunky, being very difficult to adapt to other projects. I learned very quickly after that to design code for modularity and replicability. Reusable code,of course, is superior to code that is purpose-built each time. Apart from making it easier and quicker to produce new software, it is far more reliable: bugs are more likely to have been noticed and fixed in the earlier software.
I often tell my co-workers (who are all very good ecologists) that it is very easy to write bad software and that writing good software is hard. So, even though I spend my days writing software to process the output of some fairly painful software (that was obviously written by non-engineers), even though it takes me more time than people think it should, I still spend the time to build it according to the principles I learned as a software engineer. And every time I do that, the effort pays off later on, because I am always able to adapt my code to a new application with minimal effort, even though that application had not even been thought of when I first wrote the code.
I know that this sounds terribly snobbish, even elitist, but I look at it this way: If you want to design a reliable bridge, you need a civil engineer. If you want to design a reliable car, you need a mechanical engineer. If you want to write reliable software, you need a software engineer.
I think this problem of scientists over-reaching into code writing occurs because writing code is so easy to do, and because software can fail in subtle ways. Building a bridge takes a lot of material and manpower, and if it is not designed properly, it falls down. Building a car takes a lot of time and components, and if it is not designed properly, it crashes (or doesn't run at all). With software, however, anyone can download and install a scripting language like Python or a package like R and knock out a script that seems to do what they want. It also means that anyone can knock out numbers that look reasonable but are in fact completely wrong.
If you want good software, you need a software engineer. It's an investment that pays off in the long run.
As both a software engineer and a working scientist, I tend to agree more with the second argument, but I think that the major problem is that some scientists who code are going too far outside of their area of expertise.
It takes education and a lot of experience to be able to write good code. I've been writing software for more than sixteen years now, and I think I am finally getting to the point that my coding skills are adequate. But that's after earning an honours degree in the field, after spending a couple of years working closely with a truly gifted programmer, and many more years writing software for a wide variety of applications. When I first started writing scientific software, the code I produced wasn't very good: it ran OK, and produced reasonable results, but it was pretty clunky, being very difficult to adapt to other projects. I learned very quickly after that to design code for modularity and replicability. Reusable code,of course, is superior to code that is purpose-built each time. Apart from making it easier and quicker to produce new software, it is far more reliable: bugs are more likely to have been noticed and fixed in the earlier software.
I often tell my co-workers (who are all very good ecologists) that it is very easy to write bad software and that writing good software is hard. So, even though I spend my days writing software to process the output of some fairly painful software (that was obviously written by non-engineers), even though it takes me more time than people think it should, I still spend the time to build it according to the principles I learned as a software engineer. And every time I do that, the effort pays off later on, because I am always able to adapt my code to a new application with minimal effort, even though that application had not even been thought of when I first wrote the code.
I know that this sounds terribly snobbish, even elitist, but I look at it this way: If you want to design a reliable bridge, you need a civil engineer. If you want to design a reliable car, you need a mechanical engineer. If you want to write reliable software, you need a software engineer.
I think this problem of scientists over-reaching into code writing occurs because writing code is so easy to do, and because software can fail in subtle ways. Building a bridge takes a lot of material and manpower, and if it is not designed properly, it falls down. Building a car takes a lot of time and components, and if it is not designed properly, it crashes (or doesn't run at all). With software, however, anyone can download and install a scripting language like Python or a package like R and knock out a script that seems to do what they want. It also means that anyone can knock out numbers that look reasonable but are in fact completely wrong.
If you want good software, you need a software engineer. It's an investment that pays off in the long run.
Thursday, July 21, 2011
Reminder: Paper deadline for IEEE CIFEr 2012
A reminder that the deadline for papers submitted to the IEEE Computational Intelligence in Financial Engineering and Economics Conference, 2012 (CIFEr 2012) is 21 October, 2011. This conference will be held in New York City, 30 March 2012.
Wednesday, July 20, 2011
Journal Article Submission Strategy
How do you go about submitting papers to academic journals? As space in journals becomes more restricted, and getting published becomes more competitive, I have developed certain strategies for selecting which journal to submit to.
First, write your paper. During the writing of your paper, you will be citing the relevant literature. By paying careful attention to where the most relevant articles you cite were published, you can then perform step two:
Create a shortlist of journals. You may have a journal in mind before you start work on the paper, as some topics are so specialised that they only fit one publication. This is fairly rare, however, as there are usually more than one journal that deals with a particular topic.
Find the impact factor (IF) of each journal. While you shouldn't base your submission venue solely on IF (many people I have spoken with think it's pretty bogus) funding agencies do unfortunately look at the IF of your publications when evaluating research proposals. You may alter your shortlist based on IF.
Contact the editor of each journal on your shortlist. Send them the title and the current abstract of the paper, and ask them if your paper will fit with their journal. The paper doesn't have to be completely ready at this point, but you do need a very good title and abstract. This is a good argument for writing the abstract before the rest of the paper, rather than leaving it as the last thing that you write.
This step does mean that you have to make a bit of an extra effort before submission, but it can save you a lot of time later on. Consider my experience: last Christmas holiday, I was up until 3am Christmas morning submitting a paper. I was sitting at my parent's kitchen table (in New Zealand), with my laptop, using dial-up Internet to upload the (large) images, cover letter and manuscript of my paper. The following day (Christmas day!) I was very tired, and really didn't have the energy to enjoy playing with my daughter and her cousins (my nephews and niece, who I see at most once a year). A few days later, the editor of the journal I submitted the paper to emailed me saying that the paper didn't really fit the journal and that he had rejected it without sending it to peer review. Although I had submitted to that journal on the advice of my co-authors, all of that time-wasting could have been avoided if I had just contacted the editor first.
Choose a journal to submit to. This choice is based on 1) the strength or enthusiasm of the responses you get from the editors you have contacted, and 2) the impact factor of the journal. When writing the cover letter, be sure to mention that you have contacted the editor and that they responded positively.
Finally, submit the paper. Make sure that you have carefully followed the formatting and submission instructions. Check these before submitting! Journals do sometimes change their formatting requirements, don't get caught out using an old format!
Of course, none of this will help if you have written a bad paper. See my previous post on minimum requirements for a computational intelligence paper for what I look for when reviewing a paper.
This post came out of a discussion I had with two of my colleagues at the University of Adelaide: Dr Thomas Prowse, and Dr Stephen Gregory. Thanks for the great discussion!
First, write your paper. During the writing of your paper, you will be citing the relevant literature. By paying careful attention to where the most relevant articles you cite were published, you can then perform step two:
Create a shortlist of journals. You may have a journal in mind before you start work on the paper, as some topics are so specialised that they only fit one publication. This is fairly rare, however, as there are usually more than one journal that deals with a particular topic.
Find the impact factor (IF) of each journal. While you shouldn't base your submission venue solely on IF (many people I have spoken with think it's pretty bogus) funding agencies do unfortunately look at the IF of your publications when evaluating research proposals. You may alter your shortlist based on IF.
Contact the editor of each journal on your shortlist. Send them the title and the current abstract of the paper, and ask them if your paper will fit with their journal. The paper doesn't have to be completely ready at this point, but you do need a very good title and abstract. This is a good argument for writing the abstract before the rest of the paper, rather than leaving it as the last thing that you write.
This step does mean that you have to make a bit of an extra effort before submission, but it can save you a lot of time later on. Consider my experience: last Christmas holiday, I was up until 3am Christmas morning submitting a paper. I was sitting at my parent's kitchen table (in New Zealand), with my laptop, using dial-up Internet to upload the (large) images, cover letter and manuscript of my paper. The following day (Christmas day!) I was very tired, and really didn't have the energy to enjoy playing with my daughter and her cousins (my nephews and niece, who I see at most once a year). A few days later, the editor of the journal I submitted the paper to emailed me saying that the paper didn't really fit the journal and that he had rejected it without sending it to peer review. Although I had submitted to that journal on the advice of my co-authors, all of that time-wasting could have been avoided if I had just contacted the editor first.
Choose a journal to submit to. This choice is based on 1) the strength or enthusiasm of the responses you get from the editors you have contacted, and 2) the impact factor of the journal. When writing the cover letter, be sure to mention that you have contacted the editor and that they responded positively.
Finally, submit the paper. Make sure that you have carefully followed the formatting and submission instructions. Check these before submitting! Journals do sometimes change their formatting requirements, don't get caught out using an old format!
Of course, none of this will help if you have written a bad paper. See my previous post on minimum requirements for a computational intelligence paper for what I look for when reviewing a paper.
This post came out of a discussion I had with two of my colleagues at the University of Adelaide: Dr Thomas Prowse, and Dr Stephen Gregory. Thanks for the great discussion!
Subscribe to:
Posts (Atom)
Posts
