How to deal with "missing points" in arrays
in [Fortran]
|
From: Dan on 9 Jun 2010 16:34 Assume you are using a default REAL type, x On my compiler, HUGE(x) is about 3.4x10**38 Would it be safe to assume that no interpolated value should ever be larger than, limit = 1x10**38 ?? If this is a safe assumption.... Do each interpolation as normal. For normal calculations, store your interpolated value in x. If you calculate some value that is larger than, limit, flag this calculation as an error or however you wish to handle it by setting x = 2x10**38 If there are no errors, but... for whatever reason (out of curve bounds), you do not wish to proceed with your interpolation calculation.. set this value to, x = 3x10**38 When looking back over your calculations, you can check for those 2 special values of x to know what went on earlier in your code. Of course, I imagine you need to choose your "flag" values of x carefully and not too close together to be confident that most compilers would handle the code without errors. Dan :-)
From: Richard Maine on 9 Jun 2010 16:43 Dan <dantex1(a)aol.com> wrote: > Would it be safe to assume that no interpolated value should ever be > larger than, limit = 1x10**38 ?? If this is a safe assumption.... I'll jump in and say that, no, it isn't. I have previously related here tales from my personal experience of serious errors that result from using in-band signalling like this. Such tales are ubiquitous. If you try to use that kind of signalling, then someday you will have your own tale to add to the list; I'd all but guarantee it. Somewhere, you will forget to test for a bad value. Or someone else that uses your code will fail to do so. Or you will manage to generate a value in the range that you had reserved for the flag values. The quote in my signature applies. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 9 Jun 2010 17:24 Richard Maine <nospam(a)see.signature> wrote: > Dan <dantex1(a)aol.com> wrote: >> Would it be safe to assume that no interpolated value should ever be >> larger than, limit = 1x10**38 ?? If this is a safe assumption.... > I'll jump in and say that, no, it isn't. I have previously related here > tales from my personal experience of serious errors that result from > using in-band signalling like this. Such tales are ubiquitous. If you > try to use that kind of signalling, then someday you will have your own > tale to add to the list; I'd all but guarantee it. > Somewhere, you will forget to test for a bad value. Or someone else that > uses your code will fail to do so. Or you will manage to generate a > value in the range that you had reserved for the flag values. Well, you can also forget to test with out-of-band signalling. Is it more likely? I don't know. Now, you could set the value to zero for the OOB case, but that could also cause problems. At some point you need to know the specific problem and the program to go with it. (As well as the possible failure modes.) -- glen
From: Gib Bogle on 9 Jun 2010 17:41 glen herrmannsfeldt wrote: > I don't recommend the LOGICAL variable method, unless it is > necessary to have all REAL values legal. If you need portability > to older compilers, you could do conditional compilation on a > test for NaN or 9.9999e30 (fits in single precision on most > machines), or 9.9999e99 (in double precision on many machines). Is 9.9999e30 exactly representable? Anyway, why not use 1.0e30, which definitely is? I like your idea of incrementally modifying true values that hit the "missing point" value.
From: Richard Maine on 9 Jun 2010 18:17
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > > Dan <dantex1(a)aol.com> wrote: > > >> Would it be safe to assume that no interpolated value should ever be > >> larger than, limit = 1x10**38 ?? If this is a safe assumption.... > > > I'll jump in and say that, no, it isn't. I have previously related here > > tales from my personal experience of serious errors that result from > > using in-band signalling like this. Such tales are ubiquitous. If you > > try to use that kind of signalling, then someday you will have your own > > tale to add to the list; I'd all but guarantee it. > > > Somewhere, you will forget to test for a bad value. Or someone else that > > uses your code will fail to do so. Or you will manage to generate a > > value in the range that you had reserved for the flag values. > > Well, you can also forget to test with out-of-band signalling. True. But at least when you do so, you don't destroy the flag. Thus if you test sometime later, you will at least see that there was a flagged value. If you use an in-band signal and you forget to test, then you will usually do some computation with the value and quite possibly end up with something that is no longer a flag value. You have garbage with no evidence that it is garbage. Been there. Done that. Am *NOT* going back. I maintain that in-band tests are inherently fragile and that this is inherent enough to be almost independent of the problem. Failures of in-band tests have happened enough times, including in enough cases where people thought it would be reliable, that I don't think it needs more data. There is lots of data. Start with C's in-band string termination. That alone has caused quite enough havoc for many lifetimes. Yes, I consider it comparable. NaNs do have the nice property that they don't go away when you do computations on them. In a way, they are also an in-band signal. Ok, I suppose more than just in a way. But the hardware understands them, so you can't very well forget about them. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |