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: Richard Maine on 8 Feb 2010 12:00
deltaquattro <deltaquattro(a)gmail.com> wrote:

> I think it's safe to add the two out-of-range bins as 0 and n (with n
> being the length of xArr). The reason is that, because of the way xArr
> is declared, I know that the indices of xArr go from 1 to n, and that
> jl is forced to be between 1 and n-1, if x is not outside
> [min(xArr),max(xArr)]. So I can use 0 and n as out-of-range values.

I'd agree that sounds reasonable. In fact, I'd almost not even
categorize the 0 and n as flag values in that kind of case. They are the
fairly "natural" bondary case values. This doesn't seem to different
from truncating out-of-range input values and treating them as values
right on the border instead of returning an error. Depending on other
details, the calling routine might not even need special treatment for
these cases.

> Clearly, in general it's highly risky, or even downright impossible,
> to rely on out-of-range values to return an error flag from a
> function. How could I do that, without having to rewrite all my
> functions as subroutines, in order to allow for two output parameters?
> Which is the solution you choose in your codes? Do you define the
> function as a derived type? Thanks,

I find function usage in my codes to be rare. Yes, some exist, but they
are rare. Most things end up being subroutines. This is one reason.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Which ode solver is the best for this problem? (Duffing oscillator)
Next: IOSTAT for input from sequential formatted files with ?"incomplete" final record