On Thu, 25 Nov 2010, Malcolm J. Currie wrote:

> Sorry to come to the party late.
>
>>  I think I understand the issue now. "Badness" is a concept that is not
>>  present in HDS - there are no references to VAL__BAD anywhere in HDS.
>
> Exactly.  HDS provides the basic hierarchical building blocks.  We devise 
> other conventions and construct standard structures upon it. Badness is once 
> such higher-level concept.  As far as I know the only place where the 
> flagged-value concept enters is for values where a type-conversion error has 
> occurred, but as David says these don't use PRIMDAT.

HDS and PRIMDAT explicitly agree on the definition of bad values without 
HDS depending on primdat (I think there is even a test for it).

HDS doesn't use VAL__BAD but it does use an internal global struct that 
defines the bad values for its own use. These are the values that are 
inserted when conversion fails so HDS does actually use bad values for the 
conversion as you state above AND they are assumed to be PRIMDAT 
equivalent.

So I think the feature-not-bug case is that someone using HDS has to worry 
that the bad value definition in HDS is not defined and its only when 
Starlink applications use HDS that the Starlink definition of bad value 
becomes relevant.

>
>>  So the fact that HDS does not convert bad pixel values is probably a
>>  feature rather than a bug.
>
> I agree.  Bad values were formally introduced in SGP/38 in 1987/8, then 
> implemented in PRIMDAT later in 1988.  Some older packages like EDRS had 
> supported bad pixels (if only for integers) for some years previously.
>

The problem is that if I map _INTEGER as a smaller type and 
_INTEGER has bad values in it then I'm guranteed to get a conversion 
error but I can't really tell whether it's an error I should be worried 
about or simply a bad value (which is guaranteed to be out of range of the 
smaller type).

So my choices are:

  1. Map as _INTEGER and write my own conversion code (using VEC but with a
     C interface)

  2. Assume that DAT__CONER errors can be ignored when I map a smaller type
     (effectively assuming that conversion errors are occurring because of
     bad values rather than unexpected out of range values). Note that
     these will contain perfectly valid PRIMDAT bad values.

  3. Add one if statement to HDS for the conversion error handling

#3 seems safest to me (even if I have to add that one line in quite a few 
places). #3 does not cover the case where you are mapping to a bigger type 
since there is no overflow handling code in there so I'd have to add many 
cases.

-- 
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj