[QUANTITY] Why quantities always have errors (Was: Re: [QUANTIT] Use-cases, role in larger scheme)

[Martin Hill]

>> Quantities do not need to be
>>measured, they can be defined, calculated, simulated ....  And even if they
>>are measured, they may not be susceptible to an error value.
> 
> 
>    Hmm. how useful is it to have separate classes for these types of quantities?
> 
>    I believe that quantities are framed by their *usage*, not their *origin*. IF we need to have 
>    a universal atom that we can pass around, clip apart/rebuild, and search for, 
>    then we don't care if something is a measurement, or a simulation or not. We
>    need to lump all of the types of error together in the interface in order to be able
>    to compare, clip, paste, parts which are measured, defined, calculated values.

I think that's rather the point - there doesn't appear to be a universal 
atom to pass around.  Not one that you would want to compare/etc blindly 
with any other.  Any universal operations (clone, clip, paste, store, 
etc) are based on a much higher abstract class (eg 'Object' in java) or 
similarly high level/simple interfaces.

> 
>    Having separate classes for measurement, calculation, simulation quantities
>    doesn't get you much (or anything).

These are sources of values rather than types (classes) of values...?

I think having distinct types is actually quite useful, as you can be 
sure you're comparing only things that are sensible to compare - the 
sensibleness being defined by those particular classes.  It also means 
you always know 'what you've got' - you don't find some strange type of 
value sneaking into your quantity while it's being passed about.  And 
you can validate better - if a particular quantity should have an error, 
you can say so and throw (program) errors if one is not present.

Cheers,

Martin

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