Quantity - where does it fit?

[David Berry]

Martin,

> > My perception of the Q in the document is that it is a general purpose
> > building brick which is intended to be used *inside* other models, as
> > necessary, to hold and describe n-d arrays of homoegenous values for a
> > single (possibly compound) phenomenon. Are you saying that your perception
> > of the doc is that it suggests that other data models should be created as
> > *sub-classes* of Quantity? If so, I think the doc should be changed to
> > clarify this.
>
> Yes that is my perception!  If it's *not* the case then I shall breath a
> partial sigh of relief.

This obviously needs to be cleared up - Jonathan?


> But discussion on this mailing list seems to
> reinforce the idea that not just 'leaf' items on the data model are to
> be Quantities, but also that complex compound objects such as SEDs are
> to subtype Quantities, ie:

Is that trailing "ie:" meant to imply that what I later suggest about
using a Quantity to store a passband seems to contradict what I said
above? I suppose there are at least two options:

1) Define a separate PassBand model. This would then "use" a CoreQ as a
"building-brick" to store the transmission values. But there then seems
little point in having a separate PassBand model if the only thing it
contains is a single CoreQ.

2) Just use the CoreQ *directly* as the passand object in some higher
level model. Say I define a model of a mangelwurzel and I decide my model
needs to include a passband. The MangleWurzel model has several
components, each with a type and a name:

MangleWurzel {
   ...
   ...
   CoreQuantity passband;
   ...
   ...
}

So here I *use* a CoreQuantity to store the passband, but there is no
sub-classing going on. This is what I mean by using Quantity as a building
block. Of course, if a passband needs anything in addition to the
definition of its transmission values, then you may need a separate
PassBand model to aggregate them together. My point is that if your house
consists of a single brick and nothing else, then you may as well call it
a brick rather than a house!

David



> >
> >
> >>But some filters/passbands are based on formulae rather than a set of
> >>points.  So we need to make sure an SED can handle some Passbands that
> >>are defined by an equation - the whole SED might be a mix of point
> >>measures and formuale.  Trying to squeeze all this into a generalised
> >>Quantity is going to hurt.
> >
> >
> > A CoreQuantity used to hold a passband could define the passband either by
> > storing a list of explicit transmission values, or by storing a Mapping
> > which takes (say) wavelength as input and produces transmission value as
> > output. So CoreQ should be able to handle the "formulae" case.
> >
> > David
>
>
> --
> Martin Hill
> www.mchill.net
> 07901 55 24 66
>

----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX                                Tel. 01772 893733
                                             01257 273192