Morning David,
You've pre-empted me. While doing this COLLAPSE stuff I had concerns
about efficiency both when the collapse axis is effectively a linear
axis and the widths are equal, and dealing with two-dimensional arrays
skipping through the second axis faster than the first. I thought I'd
make a first brute-force pass to keep Remo happy, and then refine the
code while he's trying COLLAPSE.
Testing on 16x16x2048 data it's a couple of seconds for some estimators.
Less than I was expecting. I guess it's held in memory. Larger
datasets jumping through the second dimension may have swapping
implications.
On the second issue, that's the way Peter designed the CCDPACK
statistical routines for collapsing I suppose because his spatial
dimensionas were large and the collapse axis had relatively few
elements. Here the reverse holds.
Is seems to be the sense that AST likes (NPOINTS, NDIM). If you want
the NDIM co-ordinates for a point you have to traverse the array in
steps of NPOINTS. Is this because AST processes in C?
> 1) Since presumably the NDF may become large, using the full Mapping to
> transform every single pixel position could be very expensive. I would
> consider using AST_LINEARAPPROX to test if the Mapping is linear (which
Caught out again from having an older printout of SUN/210, and the OO
way of not having a classified list of routines. The CVS html version
doesn't have the Class Descriptions or the routines.
> presumably it usually will be), and then use the returned linear
> approximation if it is, falling back to the full-blown astTran
> approach if it is not.
I'll have to see how that integrates into the rest of the code, like not
passing another large array between various routines.
> 2) Beware that the method of sandwiching the base->current Mapping
> between a pair of PermMaps can produce unpleasant effects if the
> selected current Frame axis is not independent of the other axes.
I don't want to assume that the collapse axis co-ordinates are the same
at every other pixel position.
> The first PermMap will feed bad values into the non-selected base
> Frame axes and these can propagate to the selected output axis if the
> selected output axis depends on any of the unselected base Frame axes.
> The obvious case is if you select (say) an RA axis - since the Dec is
> unspecified the RA will also be unspecified (bad). Using
> AST_LINEARAPPROX will get round this if the patch of sky is
> sufficiently far from the poles to make the RA and Dec independent.
> The kpg1_astrm.f function takes another approach.
I had thought of using a n-D to n-D transformation and calling a KPG
routine to extract out the appropriate secion.
Thanks for the suggestions.
Malcolm
|