From: deltaquattro on
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
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
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
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
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.