mchill at dial.pipex.com
Wed May 12 04:11:08 PDT 2004
I'll mostly agree with Brian on this one, assuming he's actually got the real
> 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...
AstroGrid @ ROE
Tel: +44 7901 55 24 66
More information about the dm