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

[Martin Hill]

Brian Thomas wrote:
> On Monday 17 November 2003 03:21 pm, Martin Hill wrote:
> 
>>>   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.
> 
> 	I think you read to obliquely into my statements. I was speaking of 
> 	the need to appropriately cut, paste, sort quantities. Cut n paste of
> 	any old object is not adequate. We need to do these things appropriately
> 	(and in a scientific manner) for numbers (and I would add, strings)
> 	as well. 

I just think the dividing line is not at quantity.  If you want to be 
able to do very general things it will be at a more abstract level than 
quantity; if you want to do more specific things, it will be at a more 
concrete level.  For example, sorting is something that will depend very 
much on what you are sorting, and 'quantity' is too general.  If you can 
think of specific examples I'm all for it!

> 
> 	Granted all objects and quantities have values, but the similarity ends
> 	there. Quantities hold things which need (if we are to be scientific) values with
> 	units and some type of accuracy. Even in the cases where these dont
> 	appear to be needed, they actually are, and are implied (as per my reponse
> 	to Pat about the parabola). 

Here we just have a fundemental disagreement!  I don't see any implied 
requirement to attaching a 'dummy' error to the 2 in x = y^2... 
Particularly since number sets are defined discretely (as I understand 
it!).

> 
> 
>>>   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. 
> 
> 
> 	This might be true if you never compare measurements with calculations,
> 	or simulations with calculations or so on. But that isnt the case, is it? 
> 	We have a very real need to compare measurements with calculations or with 
> 	"declared values" (such as a theorist defining the speed of light to be "1").
> 
> 	Give me a use-case or two where you need to limit the use of the quantity
> 	by it origin AND how that would change the calculation (or a cut, paste op).
> 

I think we're back to the sources of values not the values (and perhaps 
the cross-purposes of our discussion).  You can simulate a star, and you 
will get a flux (I presume without an error unless you're simulating a 
sample of stars or you're building errors in specifically?).  Or you can 
observe a star, and get a flux.  Both fluxes are the same 'type' and you 
can compare fluxes.  You can't compare the position of the star with the 
simulated flux, and there should be *no way* of representing such a 
comparison in our data models without some big flag coming up and 
hitting the developer over the head.  Nor can you compare measured flux 
and measured position.  You should not be able to cut and paste a flux 
into a position plot.  You will want to be able to serialise both - but 
you'll want to serialise a lot of things that aren't quantities.

And what I'm trying to say is: I don't think there is anything common 
between the type 'flux' and the type 'position' that merits having a 
'quantity'.

I'm beginning to think 'Measurement' is a bad idea for a quantity... 
unless something can be a Measurement as well as something else.  ie, 
you can have a Measured Flux, a Simulated Flux, a Measured Position... 
I'm not sure what that gives you though.  Error I suppose?

Cheers,

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