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!
Monday, July 18, 2011
Call for papers: SEAL 2012
The deadline for submitting papers to the 9th International Conference on Evolution and Learning (SEAL) 2012 is 1 May 2012. This conference will be held in Hanoi, Vietnam, 16-19 December, 2012.
Friday, July 15, 2011
IEEE Computational Intelligence Society social media presence expands
The IEEE Computational Intelligence Society now has presences on several more social media sites. This expansion is due to the ongoing work of the Social Media Subcommittee.
The first of the new sites is the CIS blog: http://ieee-cis.blogspot.com/. This is the source of and archive for news and announcements from the society. When a new post is published on the blog, it is automatically distributed to the other social media presences, using the methods described in this report.
The major social media sites are:
Twitter: http://twitter.com/#!/ieeecis
Facebook: http://www.facebook.com/IEEE.CIS
LinkedIn: http://www.linkedin.com/groups?mostPopular=&gid=75152
Newer presences are now up at the following sites:
Identica: http://identi.ca/ieeecis
Plurk: http://www.plurk.com/ieeecis
Qaiku: http://www.qaiku.com/home/ieeecis/
Jaiku: http://ieeecis.jaiku.com/
Tumblr: http://ieeecis.tumblr.com/
Shoutitout: http://shoutitout.shoutem.com/ieeecis
More expansions are planned for the near future. I will blog about them when they happen.
The first of the new sites is the CIS blog: http://ieee-cis.blogspot.com/. This is the source of and archive for news and announcements from the society. When a new post is published on the blog, it is automatically distributed to the other social media presences, using the methods described in this report.
The major social media sites are:
Twitter: http://twitter.com/#!/ieeecis
Facebook: http://www.facebook.com/IEEE.CIS
LinkedIn: http://www.linkedin.com/groups?mostPopular=&gid=75152
Newer presences are now up at the following sites:
Identica: http://identi.ca/ieeecis
Plurk: http://www.plurk.com/ieeecis
Qaiku: http://www.qaiku.com/home/ieeecis/
Jaiku: http://ieeecis.jaiku.com/
Tumblr: http://ieeecis.tumblr.com/
Shoutitout: http://shoutitout.shoutem.com/ieeecis
More expansions are planned for the near future. I will blog about them when they happen.
Wednesday, July 13, 2011
Conference paper deadline: ICONIP 2012
The paper submission deadline for the International Conference on Neural Information Processing (ICONIP) 2012 is May 15, 2012. This conference will be held in Doha, Qatar, November 26-29, 2012.
Saturday, July 9, 2011
Call for papers: PPSN 2012
The deadline for submitting papers to the 12th International Conference on Parallel Problem Solving from Nature (PPSN) 2012 is March 15 2012. This conference will be held in Taormina, Italy, September 1-5, 2012.
Friday, July 8, 2011
Call for papers: ICARIS 2012
The deadline for submitting papers to the 11th International Conference on Artificial Immune Systems (ICARIS) 2012 is 1 March 2012. This conference will be held in Taormina, Italy, 28-21 July, 2012.
Thursday, July 7, 2011
Call for papers: AAMAS 2012
The deadline for submission of abstracts to the 11th International Conference on Autonomous Agents and Multiagent Systems (AAMAS) 2012 is 7 October 2011, with full papers due 12 October 2011. This conference will be held in Valencia, Spain, 4-8 June 2012.
Conference paper deadline: ISSNIP 2011
The deadline for submitting papers to the Seventh International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP) 2011 is 31 July 2011. This conference will be held in Adelaide, Australia, 6-9 December, 2011.
Wednesday, July 6, 2011
Conference paper deadline: ICFSNC 2012
The deadline for papers submitted to the International Conference on Fuzzy Systems and Neural Computing (ICFSNC) 2012 is 30 November 2011. This conference will be held in Barcelona, Spain, April 11-13, 2012.
Monday, July 4, 2011
Universities are Important
I'm going a little bit off the topic of this blog in this post, but since most of the research in computational intelligence is done at universities it's still relevant. In a post at the Forbes.com blog, Nathan Furr discusses four myths on why universities don't matter anymore (they do). The most salient are the top three:
1) You can teach yourself everything
2) You can teach yourself everything online
3) I don't use anything I learned at college
In regards to 1) and 2), from my own experience some students do think that: one comment on a course evaluation for the data processing course I taught in 2003 was along the lines of "this course doesn't teach anything that an enterprising student couldn't learn online". The counterpoint to that is that if they hadn't done my course, they wouldn't know what they would need to teach themselves. In other words, they wouldn't know that they didn't know.
In regards to number 3, people who say that probably just don't realise that they are using stuff they learned at university. In my own case, my undergraduate education is in software engineering and systems development, my PhD is in computational intelligence, and now I do research in ecological modelling. With every project I do in ecological modelling, I have been able to apply what I learned as either an undergrad or during my PhD.
I've spent my professional life working at universities, and I will be the first to admit that, like every human enterprise, they have their flaws: I've seen people promoted because of their political skill rather than their research, teaching skill, or managerial ability, only to have them run their departments into the ground. I've seen people build entire careers on a single piece of research, then spend the rest of their lives giving the same talk over and over again. But universities do far more useful things than bad things, so they are worth keeping around.
1) You can teach yourself everything
2) You can teach yourself everything online
3) I don't use anything I learned at college
In regards to 1) and 2), from my own experience some students do think that: one comment on a course evaluation for the data processing course I taught in 2003 was along the lines of "this course doesn't teach anything that an enterprising student couldn't learn online". The counterpoint to that is that if they hadn't done my course, they wouldn't know what they would need to teach themselves. In other words, they wouldn't know that they didn't know.
In regards to number 3, people who say that probably just don't realise that they are using stuff they learned at university. In my own case, my undergraduate education is in software engineering and systems development, my PhD is in computational intelligence, and now I do research in ecological modelling. With every project I do in ecological modelling, I have been able to apply what I learned as either an undergrad or during my PhD.
I've spent my professional life working at universities, and I will be the first to admit that, like every human enterprise, they have their flaws: I've seen people promoted because of their political skill rather than their research, teaching skill, or managerial ability, only to have them run their departments into the ground. I've seen people build entire careers on a single piece of research, then spend the rest of their lives giving the same talk over and over again. But universities do far more useful things than bad things, so they are worth keeping around.
Saturday, July 2, 2011
Call for papers: WSDM 2012
The deadline for submitting abstracts to the Fifth ACM International Conference on Web Search and Data Mining (WSDM) 2012 is 4 August 2011, while the deadline for submitting full papers is 11 August 2011. This conference will be held in Seattle, Washington, February 8-12 2012.
Call for papers: SIAM SDM 12
The deadline for submitting papers to the SIAM International Conference on Data Mining (SDM) 2012 is 14 October 2011. This conference will be held in Anaheim, California, April 26-28, 2012.
Friday, July 1, 2011
Call for papers: ISNN 2012
The deadline for submitting papers to the 2012 International Symposium on Neural Networks (ISNN 2012) is 15 January 2012. This symposium will be held in Shenyang, China, July 11-14, 2012.
I visited Shenyang in 2005 and found it to be energetic but also very friendly. Shenyang is easily my favourite city in China and I look forward to visiting again.
I visited Shenyang in 2005 and found it to be energetic but also very friendly. Shenyang is easily my favourite city in China and I look forward to visiting again.
Wednesday, June 29, 2011
Teaching Materials Online
I have just made lecture materials from my undergraduate computational intelligence course available online. The lectures cover rule-based systems, fuzzy logic, artificial neural networks, evolutionary algorithms and hybrid systems. The lectures are available at: http://mike.watts.net.nz/Teaching/
These lectures were presented in the course INFO 331, Intelligent Information Systems, during my time at the Department of Information Science at the University of Otago, New Zealand. Also available at the above address are lectures I presented for the course INFO 233, Data Processing.
These lectures were presented in the course INFO 331, Intelligent Information Systems, during my time at the Department of Information Science at the University of Otago, New Zealand. Also available at the above address are lectures I presented for the course INFO 233, Data Processing.
Tuesday, June 28, 2011
Deadline extended: AI 2011
The deadline for papers submitted to the 24th Australasian Joint Conference on Artificial Intelligence (AI 2011) has been extended from 28 June 2011 to 15 July 2011. This conference will be held in Perth, Western Australia, 5th to 8th December, 2011.
Subscribe to:
Posts (Atom)
Posts
