I think the moderators understand that Software Engineers are quite knowledgeable on the topic of software. You're correct in that I would not know (much) about modelling ocean currents, but that's completely irrelevant for this discussion.
As a tiny, tiny, example: Your implementation might produce valid looking results for exactly one dataset, and you thus assume the code is good enough. It's then used, by you, six months later with additional data producing results that you publish.
Your implementation, however, didn't do a correct leap year calculation - which wasn't seen in your first run and only changes the end result by 2% for some values and you thus don't notice it.
It does however lower the confidence level of your published result close to the where statistical fluctuations could've produced the same values.... do you really want to pretend that fixing the above bug would be something a software developer wouldn't be able to do without knowing about ocean current modelling?:) Please.
If I write a program to model ocean currents, and it spits out a map of oceans very, very similar to what's been well observed in the ocean. I can assume my code is good enough.
No. As long as you believe that, you're not doing science.
Sorry, no. You're just displaying your ignorance above. You cannot look at the output and say that just because it fits with your preconceived notions it's therefor correct. You do not know if you have problems in a farhenheit to celcius conversion, a truncation when casting between units etc (yes, examples chosen on purpose). You might get a result that's in the right ballpark. You might believe you have four significant digits when you only have three. Your homebrewn statistical package might not have been audited by a statician etc.
You simply do not know all the things you claim above that you do know.
That's, again, a statement that displays ignorance as to how software development works. The fact that you have a model which should result in novel output has nothing to do with the testability of the software the model is implemented with.
I'm sorry, are you trying to say that it's ok to do shoddy science (yes, if you rely on bad software the science also becomes bad) just because your grants aren't large enough?
(I'm quite sure you wouldn't need more than 10% of someone's time though - it's not like you need a full time developer since the code currently isn't likely being done full time and a proper developer would need a lot less time to do it anyway)
You're confusing two different issues as being one and the same. The fact that your model might require domain knowledge does not invalidate the fact that your code (the specific implementation) should be verifyable as well. And no, there are many bugs that would not be immediately obvious especially if they're in the middle of calculations.
The good old "9999" for NaN when doing databases has a habit of suddenly being treated as a real value decades later by someone who's never experienced said usage.
In your case, you should have two different models that both should result in the same answer - that is one of the few ways you can test your core idea.
For the models, you could have two different implementations, and they should arrive at the same answer.
Now of course, I don't expect you to do that. You should however document enough of your thinking and release the code for your implementation. Someone else will do the other model, and/or the other implementation. That's reproducability.
Bar all of the above - someone could still check your original source code for errors. A code audit.
You know the above to be true, so why argue against it?
Yes - but the fact that there are classes of errors (specially those pertaining to the construction of the model) that would be hard to find without domain knowledge does not invalidate the fact that you'll be able to find other classes of errors.
On the contrary, I'm quite familiar with it. I'm a Software Engineer, a Mechanical Engineer and I work with Research. Do we need to put caps on more words?;)
Your field is not magic. Your field is not special. Your field can be aproached just as any other field.
Wrong. You're taking two separate issues and try to claim that since there are two one is irrelevant. Of course it's not - both are. However, verifying the model DOES take more domain knowledge than verifying the implementation. We're currently discussing verifying the implementation, which is still important.
If so, someone should've told you that you NEVER know for how long, by whom and for what your code will get used. If you have serious limitations, you document them (and thus it's no problem getting the code audited anyway).
You know why we have a Y2K problem? Coders who couldn't imagine there code still being around decades later, used for purposes they never imagined.
You still don't get it - which means that you might be brilliant in your field of science but you have no business whatsoever talking about source code - which would be one of my fields:)
You're simply not qualified, to use your own words.
You argument is void. A bug is a bug. Either it affects the outcome of the program run or it doesn't - and I still don't need to know anything about what it's supposed to do to verify that. You just need to re-run the program with a specified set of inputs and check the output - also known as verified against its own test suite.
Your comment clearly shows you know nothing about software. I'm able to audit your source code without having a slightest clue as to what domain it's meant to be run in.
Yes we have such ice cores*. We also know that gas diffusion in them is a problem, and thus what we have are ice cores showing smoothed levels and not spikes. It's therefore not proper science to compare the levels from those cores with atmospheric readings. Additionally, we know that CO2 is not well mixed in the atmosphere, complicating the comparison even further. We do have other ways of measuring CO2 over geological timescales, and when doing so there seems to be no correlaction at large between earth's climate and CO2 levels, and there seems to be no support whatsoever for any runaway scenarious since CO2 levels have been more than an order of magnitude higher before.
Further, CO2 absorption is logarithmic. Claiming that "CO2 is a greenhouse gas" is true, but irrelevant. The whole argument over whether we're at any risk of causing global warming with our carbon use is completely based on speculated positive feedbacks - and THOSE have no experimental and/or observation support. On the contrary, the observations that have been done show them to be negative.
Everything I've written above is Proper Science. I hope you like it.
*) Using the same ice cores, we know that we're currently not at all in the warmest period in the latest interglacial, and that we statistically should be on our way into deep freeze.
AGW is a hypothesis. We might debate our belief in it, but to claim that it has experimental and/or observational support is to lie. Most people don't know, understand or care - but if you claim you understand the scientific process you should.
It's mathematically impossible for every person on earth to burn this much oil, eat this much meat, and live on this much land.
Technological development, however, makes it mathematically possible for every person on earth (and a lot more) to have the equivalent of the life you describe.
Slashdot Mirror
I think the moderators understand that Software Engineers are quite knowledgeable on the topic of software. You're correct in that I would not know (much) about modelling ocean currents, but that's completely irrelevant for this discussion.
As a tiny, tiny, example: Your implementation might produce valid looking results for exactly one dataset, and you thus assume the code is good enough. It's then used, by you, six months later with additional data producing results that you publish.
Your implementation, however, didn't do a correct leap year calculation - which wasn't seen in your first run and only changes the end result by 2% for some values and you thus don't notice it.
It does however lower the confidence level of your published result close to the where statistical fluctuations could've produced the same values. ... do you really want to pretend that fixing the above bug would be something a software developer wouldn't be able to do without knowing about ocean current modelling? :) Please.
If I write a program to model ocean currents, and it spits out a map of oceans very, very similar to what's been well observed in the ocean. I can assume my code is good enough.
No. As long as you believe that, you're not doing science.
Sorry, no. You're just displaying your ignorance above. You cannot look at the output and say that just because it fits with your preconceived notions it's therefor correct. You do not know if you have problems in a farhenheit to celcius conversion, a truncation when casting between units etc (yes, examples chosen on purpose). You might get a result that's in the right ballpark. You might believe you have four significant digits when you only have three. Your homebrewn statistical package might not have been audited by a statician etc.
You simply do not know all the things you claim above that you do know.
That's, again, a statement that displays ignorance as to how software development works. The fact that you have a model which should result in novel output has nothing to do with the testability of the software the model is implemented with.
I'm sorry, are you trying to say that it's ok to do shoddy science (yes, if you rely on bad software the science also becomes bad) just because your grants aren't large enough?
(I'm quite sure you wouldn't need more than 10% of someone's time though - it's not like you need a full time developer since the code currently isn't likely being done full time and a proper developer would need a lot less time to do it anyway)
You're confusing two different issues as being one and the same. The fact that your model might require domain knowledge does not invalidate the fact that your code (the specific implementation) should be verifyable as well. And no, there are many bugs that would not be immediately obvious especially if they're in the middle of calculations.
The good old "9999" for NaN when doing databases has a habit of suddenly being treated as a real value decades later by someone who's never experienced said usage.
(I chose that example on purpose)
In your case, you should have two different models that both should result in the same answer - that is one of the few ways you can test your core idea.
For the models, you could have two different implementations, and they should arrive at the same answer.
Now of course, I don't expect you to do that. You should however document enough of your thinking and release the code for your implementation. Someone else will do the other model, and/or the other implementation. That's reproducability.
Bar all of the above - someone could still check your original source code for errors. A code audit.
You know the above to be true, so why argue against it?
Yes - but the fact that there are classes of errors (specially those pertaining to the construction of the model) that would be hard to find without domain knowledge does not invalidate the fact that you'll be able to find other classes of errors.
Errors as those detailed in the article.
Yes? Feel free to hire me and I'll show you how it's done.
(To start with, you break down the system into simpler systems, until you reach testable components)
On the contrary, I'm quite familiar with it. I'm a Software Engineer, a Mechanical Engineer and I work with Research. Do we need to put caps on more words? ;)
Your field is not magic. Your field is not special. Your field can be aproached just as any other field.
Then you shouldn't do the code, just as you shouldn't do any number of other irrelevant things for the science you're hired to produce.
I've got patents. Quite a few actually. I haven't written a single one of the actual patent applications.
I suggest letting the scientists do science - i.e the models - and let software engineers do the implementation.
I'm quite sure your scientisits don't go out and chop wood to produce their own desks and paper either, right?
(... and when the scientists want to do statistics, they should consult statisticians)
You're not doing science if you're not performing work that can be falsified (and replicability is a cornerstone in that).
I'd rather have you do science.
Wrong. You're taking two separate issues and try to claim that since there are two one is irrelevant. Of course it's not - both are. However, verifying the model DOES take more domain knowledge than verifying the implementation. We're currently discussing verifying the implementation, which is still important.
Do you have a degree in software?
If so, someone should've told you that you NEVER know for how long, by whom and for what your code will get used. If you have serious limitations, you document them (and thus it's no problem getting the code audited anyway).
You know why we have a Y2K problem? Coders who couldn't imagine there code still being around decades later, used for purposes they never imagined.
I'm sorry, you seem to want to claim that bad code and bad testing is ok in science.
It's not, of course.
You still don't get it - which means that you might be brilliant in your field of science but you have no business whatsoever talking about source code - which would be one of my fields :)
You're simply not qualified, to use your own words.
You argument is void. A bug is a bug. Either it affects the outcome of the program run or it doesn't - and I still don't need to know anything about what it's supposed to do to verify that. You just need to re-run the program with a specified set of inputs and check the output - also known as verified against its own test suite.
(Yes, I'm a Software Engineer by education)
Your comment clearly shows you know nothing about software. I'm able to audit your source code without having a slightest clue as to what domain it's meant to be run in.
Yes we have such ice cores*. We also know that gas diffusion in them is a problem, and thus what we have are ice cores showing smoothed levels and not spikes. It's therefore not proper science to compare the levels from those cores with atmospheric readings. Additionally, we know that CO2 is not well mixed in the atmosphere, complicating the comparison even further. We do have other ways of measuring CO2 over geological timescales, and when doing so there seems to be no correlaction at large between earth's climate and CO2 levels, and there seems to be no support whatsoever for any runaway scenarious since CO2 levels have been more than an order of magnitude higher before.
Further, CO2 absorption is logarithmic. Claiming that "CO2 is a greenhouse gas" is true, but irrelevant. The whole argument over whether we're at any risk of causing global warming with our carbon use is completely based on speculated positive feedbacks - and THOSE have no experimental and/or observation support. On the contrary, the observations that have been done show them to be negative.
Everything I've written above is Proper Science. I hope you like it.
*) Using the same ice cores, we know that we're currently not at all in the warmest period in the latest interglacial, and that we statistically should be on our way into deep freeze.
Is it? How come?
AGW is a hypothesis. We might debate our belief in it, but to claim that it has experimental and/or observational support is to lie. Most people don't know, understand or care - but if you claim you understand the scientific process you should.
CO2 is a known greenhouse gas and is the major causal agent behind the climate change we're seeing right now.
There are two statements above. One is true and one is a hypothesis with no experimental or observational support.
Do you know which is which? I assume, since you claim to be a biochemist, that you know what the scientific method means.
It's mathematically impossible for every person on earth to burn this much oil, eat this much meat, and live on this much land.
Technological development, however, makes it mathematically possible for every person on earth (and a lot more) to have the equivalent of the life you describe.
It doesn't support the mkv container, which it should, since it's now reconized by DivX (v7) and the PS3 is DivX certified.
http://www.divx.com/en/mkv
http://support.divx.com/faq/view/supportFAQen038/DivX%20on%20the%20Sony%20Playstation%203
Until included natively, PS3MediaServer is the best solution - real time transcoding as the GP said.
... and Mac