Quantity - where does it fit?
dsb at ast.man.ac.uk
Fri May 14 04:59:43 PDT 2004
> > 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:
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!
> >>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
> 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
More information about the dm