Prev: Which ode solver is the best for this problem? (Duffing oscillator)
Next: IOSTAT for input from sequential formatted files with ?"incomplete" final record
From: deltaquattro on 4 Feb 2010 13:05 Hi, when writing code which performs a numerical task such as for example interpolation, would you add the checks on the input data inside the sub itself, or would you demand it to other code to be called before the interpolation subroutine? For example, in 1D linear interpolation you have to lookup an ordered table for the position of a value x, before performing interpolation. Checking for x falling inside or outside the interval spanned by the table should be done inside or outside the interpolation sub? I'd say outside, but then when I reuse the code I risk forgetting the call to the checking sub... Best Regards deltaquattro
From: Paul van Delst on 4 Feb 2010 13:16 deltaquattro wrote: > Hi, > > when writing code which performs a numerical task such as for example > interpolation, would you add the checks on the input data inside the > sub itself, or would you demand it to other code to be called before > the interpolation subroutine? For example, in 1D linear interpolation > you have to lookup an ordered table for the position of a value x, > before performing interpolation. Checking for x falling inside or > outside the interval spanned by the table should be done inside or > outside the interpolation sub? I'd say outside, but then when I reuse > the code I risk forgetting the call to the checking sub... I think you answered your own question there. But, sans any other information, I would do the check within the code. For this sort of thing, in general, you should minimise the reliance on a series of operations having to be done in a particular order in your code, e.g. to do Y, you first have to do X. Why can't your interpolation subroutine, (i.e. Y), call the boundary checking routine (X)? cheers, paulv
From: deltaquattro on 4 Feb 2010 13:30 On 4 Feb, 19:16, Paul van Delst <paul.vande...(a)noaa.gov> wrote: > deltaquattro wrote: > > Hi, > > > when writing code which performs a numerical task such as for example > > interpolation, would you add the checks on the input data inside the > > sub itself, or would you demand it to other code to be called before > > the interpolation subroutine? For example, in 1D linear interpolation > > you have to lookup an ordered table for the position of a value x, > > before performing interpolation. Checking for x falling inside or > > outside the interval spanned by the table should be done inside or > > outside the interpolation sub? I'd say outside, but then when I reuse > > the code I risk forgetting the call to the checking sub... > > I think you answered your own question there. > > But, sans any other information, I would do the check within the code. For this sort of > thing, in general, you should minimise the reliance on a series of operations having to be > done in a particular order in your code, e.g. to do Y, you first have to do X. Why can't > your interpolation subroutine, (i.e. Y), call the boundary checking routine (X)? Excellent point, Paul. I considered the option but I'm prone to discarding it. If I move the IF...THEN...ELSE to a subroutine CheckIfXInside, called by LinearInterp, I end up with a sub which is basically as safe as LinearInterp was before, but has the added burden of calling another subroutine. So if we agree that's better to "force" checking and interpolation to "stay together", then I think it's more efficient to just leave the check inside LinearInterp. As for additional information on the problem, feel free to ask any information you thnik it's important for the choice. > > cheers, > > paulv Best Regards Sergio ps one of the reasons why I'm asking this is because I've seen a lot of interp sub in libraries which don't do any checks on input data, while mine are filled to the brim with checks, so I started doubting my coding practices :)
From: Richard Maine on 4 Feb 2010 13:37 deltaquattro <deltaquattro(a)gmail.com> wrote: > ps one of the reasons why I'm asking this is because I've seen a lot > of interp sub in libraries which don't do any checks on input data, > while mine are filled to the brim with checks, so I started doubting > my coding practices :) Yes, one sees lots of code that fails to do basic sanity checks. One also sees lots of examples of resulting failures. At times it seems like about half of the software security flaws out there boil down to failing to check such things. Buffer overrun, anyone? That's more often in C code, than in Fortran, but the principles apply. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Gordon Sande on 4 Feb 2010 13:40
On 2010-02-04 14:05:29 -0400, deltaquattro <deltaquattro(a)gmail.com> said: > Hi, > > when writing code which performs a numerical task such as for example > interpolation, would you add the checks on the input data inside the > sub itself, or would you demand it to other code to be called before > the interpolation subroutine? For example, in 1D linear interpolation > you have to lookup an ordered table for the position of a value x, > before performing interpolation. Checking for x falling inside or > outside the interval spanned by the table should be done inside or > outside the interpolation sub? I'd say outside, but then when I reuse > the code I risk forgetting the call to the checking sub... > > Best Regards > > deltaquattro It is called defensive programming! Check you inputs. Any usage error should be found as early and as definitively as possible. I have a sections in various code that carry the comment "Sanity checks". If anyone complains about the extra cost of the checks just reply that it is more than paid back by the savings not having to chase silly blunders. It also allows you to but your attention to where it belongs as if you should ever get it wrong it will be caught early and in the place where it makes most sense. I also put in heavy duty checks, where it is possible, that are under control of an DEBUG parameter in an IF statement. Leave them in as they are very handy later. Use a parameter and you can safely rely on the fact that most modern compilers will remove the resulting dead code very early in the compilation process so there is no cost other than a few milleseconds of compile time. I have found that working out what the heavy duty checks should be has often resulted in a better understanding of what was being checked. By leaving the checks in they will stay compiling cleanly when you modify the main code. There is nothing as annoying as enabling some conditionally compiled check and finding that there are now compilation errors to deal with. |