[QUANTITY] Why quantities sometimes have errors

[Martin Hill]

OK happy that using simple subclassing is inappropriate for the vast 
number of different quantities that there are (and apologies for not 
catching up with the backlog to have known this).

But it does sound as if you're going for an all-inclusive concept (?) - 
for example, if we're looking at quantities with or without units, 
surely we must consider quantites with or without errors?  And we should 
not be making a placeholder for these subcomponents if these subcompents 
are not always required... which is the point I was trying to make, even 
if my example seems to have diverted the issue.  I'm really not happy 
(from an OO design point of view) with including things that, by 
default, are not used.  It implies the relationships/concepts have not 
been though through properly.

Which takes me back to my original question on this: what is a 
[QUANTITY] for?  It sounds like we have lots of different quantities 
that don't really have anything in common.  Not even the term 'Value' in 
the diagram, which if it was typed would end up being entirely different 
between qantities ??  In which case shouldn't we be looking at these 
different things seperately (eg Measurement) which might have common 
components (eg Error) rather than trying to make an all-encompasing one?

Unless I have entirely the wrong end of the stick again...

MC

(Some points on complexity below)


Brian Thomas wrote:

> On Monday 17 November 2003 01:00 pm, Martin Hill wrote:
> 
>>So it makes sense to me (as a developer) that you have a quantity
>>without error, and a subclass that includes error.  Errors too will
>>require a heavy duty definition and no doubt a lot of discussion on this
>>forum...
> 
> 
> 	Martin, All,
> 
> 	If the class hierarchy is simple (e.g. linear) then I have no arguements
> 	with this point of view. In such a case, you can get a nice picture of
> 	one class inheriting, and adding functionality, onto another. So things 
> 	like quantityWithOutErrors leading to a child class quantityWithErrors
> 	exist.
> 
> 	But stop and think about all the possible permutaions that we are now
> 	looking at, e.g. data types (both primative and complex), numbers and
> 	strings, multi-dimensional quantitities, quantities with or without units,
> 	and you begin to see that your class hierarchy *isnt* even remotely linear.
> 
> 	And IF you insist that we dont consider these additional features (e.g. quantity
> 	has only *one* value, its a number always, its 0-dimensional, and we never ever 
> 	have an error or units) then we are really heading down a dead end because they 
> 	will be that  much harder to add later on.
> 	
> 	As an example of this, lets suppose that is the chosen route, to start with a 
> 	simpleQuantity. You will quickly see that as your simpleQuantity class is extended
> 	into child classes that you will *have* to have a mess of multiple parentages (e.g. 
> 	"quantity" inherits from "quantityWithErrorsOnly" and "quantityWithDimensions"
> 	and "quantityWithUnits", etc.). Making these multiple parentages not conflict with 
> 	one another, and  making it all work out right ("if I have a multiple dimension quantity 
> 	with units, am I treating the units in the manner that works correctly?" "are the units
> 	treated correctly in multi-dimension quantities") is a pure headache. More so, than
> 	if we had just considered the ensemble of capabilities to begin with. As an actual
> 	example of this problem, I point to the VOTable format. More complex proprosals 
> 	for table formats and treating it as some sort of abstract data container where rejected 
> 	at the time of its creation because they were deemed too complex. Now, we find that 
> 	we need that complexity, but it is rather difficult to add it in, e.g. the UType proposal).

This is a general management problem; do we design now for everything, 
or do we design now for what we need now, and 'refactor' later.  The 
first tends to take a huge initial effort, and creates huge unwieldy (or 
unpleasantly vague) products that cover most situations.  The second 
tends to create inflexible ones.

The first is usable by shoe-horning later requirements into the original 
design.  The second is usable by throwing it away and writing a new one 
that includes bits of it.  OO provides a nice route for this through 
interfaces (and for this VOTable is a bad example, as it's not OO or, 
really, XML!). There don't seem to be generally agreed advantages to 
either.  I happen to like the latter as it produces things quickly (and 
I like to produce things) but this is a matter of taste.

We *do* know what we want to include here: units, errors, etc so I'm 
considering those as requirements we know about now to be included now.

> 
> 	If I may be impolite enough to say so, I think of this design approach as "sticking 
> 	your head  in the sand". The complexity doesn't go away; we *will* need it later, 
> 	and it *will*  cause us much greater design problems later if we dont consider how 
> 	all these things work together (or not) at least somewhat now.
> 
> 	I think its far better for us to define an interface/abstract class for "quantity" and 
> 	simply require that implementers follow it. This means giving sensible answers
> 	for any of the things that might be in quantity. 
> 
> 	I have created such a possible interface, you may view it at:
> 
> 	http://nvo.gsfc.nasa.gov/QuantityDataModel/quantityInterface.png
> 
> 	The pink part is the core quantity. The yellow parts are also included in the
> 	basic quantity, BUT, except for the "default answers", are left to be defined
> 	later on. Default answers may very well be NULL, e.g.
> 	
> 	quantity->getAccuracy()  ===> "NULL".
> 
> 
> 	Regards,
> 
> 	=b.t.
> 

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