norm() cannot be run on the output of tran() about starlink-pyast

[timj]

If any of the package was in python it would have been easier to have a norm=True keyword argument for tran(). Since it's all in C that would probably be tricky. It's a bit silly to add that to Atl. It is a problem that the arrangement of the numpy arrays returned from tran() are different to the numpy arrangement accepted by norm().

The reason tran() doesn't do that by default is that AST doesn't want to waste time normalising the coordinates when those coordinates may well be transformed again anyhow.

[parejkoj]

It's fine that tran() doesn't default to that: no disagreement there. But it is very awkward to actually normalize the output of tran. Having some method that can be directly applied to the tran() output is the idea here.

[dsberry]

I suppose we could provided an overloaded implementation of the norm method within pyast that check the type of its arguments to see if it is provided with a single array of floating point values, or an array of arrays and does the appropriate thing. But in addition you can also use the existing NormMap class to normalise the output from tran:

(a,b) = wcsinfo.tran( [[100.0,150.0],[200.0,250.0]] )
(c,d) = Ast.NormMap( wcsinfo ).tran( [a,b] )

The reason for not performing normalisation by default within tran is partly, as Tim says, to avoid unnecessary work. But it is also because there are some occasions when you do not want to perform the normalisation - e.g. when dealing with cylindrical projections such as CAR when you need to know if a transformed point has gone out of the domain of the projection.