On Accuracy

[Martin Hill]

I'll mostly agree with Brian on this one, assuming he's actually got the real 
reasons:

> 	I'd like to hear *why* people don't want errors/accuracy in Q's (??). So far, I
> 	hear stuff that falls into 1 of 3 camps which I just don't see as valid reasons :
> 
> 	1. Its hard to implement (!).
> 	I've just finished writing most of the Java code to prototype the Q,
> 	and accuracy was pretty trivial (since each accuracy object is itself a Q).
> 
We need to make sure that our models allow straightforward simple errors. 
Personally (obviously!) I'm not convinced that having errors subclass Quantities 
will make implementing them easier in the long term.  I'm sure it's fine if 
you're buried in the Quantity model (as Brian is) but it seems to add a lot of 
overhead to something that might be a simple +/-, or a percentage, or even a 
PSF, none of which have units, accuracies or frames (because they are they same 
as the Quantity) or individual UCDs .

> 	2. I don't want to write code that has to check for accuracies (and don't want to
> 	get null's  or errors or empty values back).> 	

>       IF you don't want to check for accuracies, then you don't
> 	have to worry about calling the method, no? If you design a Q package, its pretty
> 	trivial to write code that returns nulls/NoAccuracyDefined/throws an error (choice
> 	of which is still TBD by accuracy interface). Jeez, I can write the Java code to do this
> 	in about 10 min. Its just not that insanely hard.

However library implementors need to make it straightforward for users access 
values as well as value/error combinations.  Some tools (eg first-glance plots) 
might not care about errors when they're not significant - we don't want to 
*force* the *using* code to have to faff around with Accuracys if it doesn't 
want to.  (Even if we think it should :-)

> 
> 	3. Some data lack errors/accuracy.
> 
> 	For the last point : these data lack accuracy because of one of the following reasons:
> 	1. Laziness on the data creator 2. they are constants/definitions, or ??
> 	 I say the *appropriate* thing to do is to specify which of these cases apply. The default
> 	might be to return a "NoAccuracyBecauseNotSpecified" with the other option of 
> 	"NoAccuracyImConstantOrDefinitaionValue". And there might be other situations beyond
> 	that that need "no accuracy" definitions. 

I am really not happy with this.  If an object that we are modelling (eg HTM 
value) has no Accuracy, then the object model should reflect this.  Sticking 
flags onto the object requires an extra load of documentation to be maintained 
(and read) so that people know that the getAccuracy() method can't be used. 
This is not robust design or development.

I know there are occasions when this kind of flag is used (eg Composite patterns 
sometimes do this with isLeaf() and getChildren()) but this is only when there 
are a huge number of other advantages to the structure.

> 	What is the cost of not having accuracy? Pretty steep by comparison : you don't have
> 	scientific measurements. No errors, no science data. You also will lack the ability to
> 	decompose the higher level Q's into basic Q's. The cost for this is that searchability 
> 	of the Q becomes more difficult (for reasons outlined above).

We need Accuracy.  We just don't need it everywhere.  Therefore we should not be 
modelling it everywhere. This is just one problem with trying to make a Quantity 
work for everything, but follow up email to come cos I'm trying to understand 
all this composting ArrayQuantity approach...


-- 
Martin Hill
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org