4 ms·

It is much harder to peer review for errors than code.

jpadkins 13y ago
Not really. You start from the solution cells and work backwards. It might be easier than reviewing a functional programming language that does the same work. Think about all the accounting and financial decisions that is reviewed in excel. They are vitally important to get correct.
- DanBC 13y ago
  The European Spreadsheet Risk Interest Group[1] has a list of spreadsheet errors. (http://www.eusprig.org/horror-stories.htm http://www.eusprig.org/horror-stories.htm) There are lots of errors in accounting and financial spreadsheets. It's vitally important that traders enter the correct numbers when making trades, but 'fat finger errors' happen pretty often. Ray Panko has a lot of useful research about spreadsheets. Part of the problems he identifies are difficulties in auditing and finding errors. [1] (http://www.eusprig.org/ http://www.eusprig.org/) [2] (http://panko.shidler.hawaii.edu/ssr/ http://panko.shidler.hawaii.edu/ssr/) My internet is flaky, and none of the links I find work.
- salman89 13y ago
  Going cell by cell in a backwards fashion seems to be a tedious way of checking for errors, and goes against your normal logical flow (forwards).
  - rayiner 13y ago
    If you're a a programmer in a typical imperative language, sure. If your familiarity is with data flow or functional languages, you work backwards all the time (or rather, you work top down, from the highest level of generality to the lowest level of detail).
tbrownaw 13y ago
I thought code written for science papers was generally crap (from a maintenance/review perspective, because the people who write it are scientists first and programmers second), and often not published anyway? The idea behind not publishing being that if someone tries to reproduce your work, it's best to make certain the won't reproduce your coding bugs by copying (and also that publishing crap code is embarrassing)...
rayiner 13y ago
I disagree. Excel has several features that make it easier to review: 1) You can generally count on built-in formulas to be correct, which might have to be recreated in a different language; 2) Excel programs have a highly stylized control flow that's so simple that you don't even really have to explicitly consider it--you just look at the data flow and assume the engine gets the control flow right; 3) Excel has built in visual aids to help you catch off-by-one errors and the like, as well as charting capabilities to help you see if intermediate variables are behaving the way they ought to behave. And have you ever seen say a Matlab script written by a researcher? Researchers outside CS (and many researchers inside CS) write terrible code, because that's not their job. I'd much rather debug an Excel file written by an economist than a Matlab program.
- enjo 13y ago
  You can generally count on built-in formulas to be correct, which might have to be recreated in a different language;* At one point, at least, this wasn't true. At Quickoffice we ran into all sorts of problems implementing functions as our results didn't match what Excel would display. It was fascinating. Ours were mathematically correct, but "Excel correct" is what our users wanted. Most of the errors where inherited from very early versions of Excel. Instead of fixing the formula, they would just replicate the bug to keep everything consistent. I'm straining to remember the specific examples (there were many), but it's been quite a few years since I was around that stuff.
  - brodney 13y ago
    Those stories always make for a good read. I'm interested in examples if you can think of any.
  - pseut 13y ago
    Some examples here for Excel 2007: http://blog.meteorit.co.uk/2007/10/02/excel-2007-bug-shows-wrong-answers-to-simple-multiplications/ http://blog.meteorit.co.uk/2007/10/02/excel-2007-bug-shows-w... one example from the post: 425 * 154.2 was displayed as 100,000 and treated as 100000 for some calculations but not others. I remember older versions of Excel having similar (but not exactly the same) problems in basic mathematical operations too, but can't remember exactly what they were.

Not really. You start from the solution cells and work backwards. It might be easier than reviewing a functional programming language that does the same work. Think about all the accounting and financial decisions that is reviewed in excel. They are vitally important to get correct.

DanBC 13y ago
The European Spreadsheet Risk Interest Group[1] has a list of spreadsheet errors. (http://www.eusprig.org/horror-stories.htm http://www.eusprig.org/horror-stories.htm) There are lots of errors in accounting and financial spreadsheets. It's vitally important that traders enter the correct numbers when making trades, but 'fat finger errors' happen pretty often. Ray Panko has a lot of useful research about spreadsheets. Part of the problems he identifies are difficulties in auditing and finding errors. [1] (http://www.eusprig.org/ http://www.eusprig.org/) [2] (http://panko.shidler.hawaii.edu/ssr/ http://panko.shidler.hawaii.edu/ssr/) My internet is flaky, and none of the links I find work.
salman89 13y ago
Going cell by cell in a backwards fashion seems to be a tedious way of checking for errors, and goes against your normal logical flow (forwards).
- rayiner 13y ago
  If you're a a programmer in a typical imperative language, sure. If your familiarity is with data flow or functional languages, you work backwards all the time (or rather, you work top down, from the highest level of generality to the lowest level of detail).

tbrownaw 13y ago

I thought code written for science papers was generally crap (from a maintenance/review perspective, because the people who write it are scientists first and programmers second), and often not published anyway? The idea behind not publishing being that if someone tries to reproduce your work, it's best to make certain the won't reproduce your coding bugs by copying (and also that publishing crap code is embarrassing)...

rayiner 13y ago

I disagree. Excel has several features that make it easier to review: 1) You can generally count on built-in formulas to be correct, which might have to be recreated in a different language; 2) Excel programs have a highly stylized control flow that's so simple that you don't even really have to explicitly consider it--you just look at the data flow and assume the engine gets the control flow right; 3) Excel has built in visual aids to help you catch off-by-one errors and the like, as well as charting capabilities to help you see if intermediate variables are behaving the way they ought to behave. And have you ever seen say a Matlab script written by a researcher? Researchers outside CS (and many researchers inside CS) write terrible code, because that's not their job. I'd much rather debug an Excel file written by an economist than a Matlab program.

enjo 13y ago
You can generally count on built-in formulas to be correct, which might have to be recreated in a different language;* At one point, at least, this wasn't true. At Quickoffice we ran into all sorts of problems implementing functions as our results didn't match what Excel would display. It was fascinating. Ours were mathematically correct, but "Excel correct" is what our users wanted. Most of the errors where inherited from very early versions of Excel. Instead of fixing the formula, they would just replicate the bug to keep everything consistent. I'm straining to remember the specific examples (there were many), but it's been quite a few years since I was around that stuff.
- brodney 13y ago
  Those stories always make for a good read. I'm interested in examples if you can think of any.
- pseut 13y ago
  Some examples here for Excel 2007: http://blog.meteorit.co.uk/2007/10/02/excel-2007-bug-shows-wrong-answers-to-simple-multiplications/ http://blog.meteorit.co.uk/2007/10/02/excel-2007-bug-shows-w... one example from the post: 425 * 154.2 was displayed as 100,000 and treated as 100000 for some calculations but not others. I remember older versions of Excel having similar (but not exactly the same) problems in basic mathematical operations too, but can't remember exactly what they were.