[QUANTITY] Why quantities sometimes have errors

[Brian Thomas]

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).

	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.

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128