[QUANTITY] Quantity "arguments"

[Ed Shaya]

Dave

>I have no trouble at all with binned values since that is the only
>thing we *ever* have. 
>
Not so.  There are quantities that refer to the value of a phenomena at 
a specific point in a space.
Even flux is sometimes referred to at flux at a given frequency with no  
binning over a frequency range.
One can fit a spectrum and then extract  the flux at specific 
frequencies.  Not all measurements are done on a  continuous space.  
Measurement of anything done on  objects at different specific 
temperatures or pressure, etc.  The Quantity object should be general 
enough to describe any scatterplot as well as
any histogram as well as any image.

>>But, one should not go too
>>far in this direction because we should not dictate that a particular
>>set of axis values cannot be used because it may be transformed to some
>>other.  For instance, if one has calculated, from an image, a flux
>>versus projected distance in parsecs from a planetary nebula, we can't
>>insist that this be primarily expressed as a pixel array just because
>>someone else may want it in centimeters.  This is clearly a case where
>>one has a FluxQ with Argument ProjectedDistanceQ in parsec.  If you want
>>centimeters, then that is an external process.  We do however need to
>>carefully express the radial bin sizes used.
>>    
>>
>
>Afraid I disagree again. The example you give fits exactly into our
>model. If you have a radial profile, how else are you going to store it
>other than as some form of pixel array? I do not see any other option. The
>ValueList in the Quantity will contain a list of flux values (="pixels"),
>with indices (="pixel coord") running from 1 (or 0 - for Brian!) to say,
>100. The WCS component will contain a 1-D Frame representing distance in
>parsecs, and a Mapping (probably just a simple linear Mapping) which
>converts a pixel coords into a distance in parsecs. I do agree however,
>that converting parsecs to centimetres would be an external process,
>unless of course the centimetres measure distance on the telescope focal
>plane instead of distance from the centre of the nebula. In this case you
>could simply have an extra Frame in the WCS FrameSet to describe
>centimetres in the focal plane.
>  
>
Well, here is another option
FluxQ
    Argument
        ProjectedDistanceQ
             ValueList
                   0.1  0.7  1.4  0.3 3.6 6.8
             Units
                   parsecs
    ValueList
          23.2 12.3 5.3 15.7 33.3 5.6
    Units
         ergs/s/cm2/hz

This may convey all of the information that I have or want to convey.  I 
see no reason here to mess with mappings or algorithms or frames or 
pixels.   Again, these may be binned or may not be binned, perhaps they 
are the fluxes of globules at these specific radii.

On the other hand often we do want to generate axes by algorithm. Then 
one needs an index object that is to mapped.  And, when working with the 
special case of  continuous curvilinear coordinates,
we want to use Arguments of the type developed in WCS.  WCS is a 
subclass of Argument
in which the independent variable needs to begin with a pixelMapQ 
(perhaps tuple to express X,Y)  that
is mapped to the physical coordinates.  The frame0  is a subclass of Q 
that generates that pixelMap.
Frame0 is mapped by the appropriate WCSMapping.  And  Frame1 is the 
input into this Mapping.
The following fits into your world view as I understand it, but perhaps 
does not nest the way that
you prefer.  However, it allows for a much more general world view.
Quantity
       <values>
       <units>
       WCS:Argument
           Frame0_Q
                WCS:Mapping
                   Input
                       Frame1

Frame0_Q is a special quantity that provides a shorthand for the following
if we want tuple. Although, we may decide it is best to use a 1-d index 
number. That depends on the specific algorithm to be used.

PixelMapQ
       Index NAxis1*NAxis2...
       Mapping
          ToTupleAlgorithm
                Input
                   NAxis1
                   NAxis2
                      ...
   

Mapping may also be applied separately on the upper Quantity values.  
For instance to Map to new units:

Quantity
      ValueList
      Units
      Mapping
          ToNewUnits
              Input
                  Jansky
      WCS:Argument
          same as before

This Mapping has nothing to do with the coordinates  so  why should it 
be in the Argument part?

I can have several WCS:Arguments that would then be separate dimensional 
extensions of the space.
And, I can intermix with these ordinary Arguments in which the 
"coordinate" values are explicitly listed.
For instance images of the same object taken by various spacecraft can 
have Arguments with  the
names of the spececraft or PI or filterName as the independent 
variable.  Indeed, Arguments take
Qs, and Qs can have complex Arguments (pressure depends on the T and T 
depends on RA,DE, but the
ordering of the P is by Temperature).

Ed