[vo-dml] Clarification on composition rule..

[David Berry]

On Tue, 10 Mar 2020 at 12:31, Gerard Lemson <glemson1 at jhu.edu> wrote:
>
> Hi Dave and others
> I think the AST model is logical and clearly battle tested.
> Precisely what I miss in the current state of the transformation model are the representations of the Frame and possibly the Frameset and how Mappings work on these.

I was assuming that discussion of how Transforms are used within
higher level models is outside the remit of the Transform document
itself. Mark has made some proposals for how the Cube and Coords
models could be changed to allow them to be used to provide the
equivalent of an AST FrameSet. I'd been thinking of the Transform
model itself as a black-box that simply describes how to transform a
given anonymous input vector to create an anonymous output vector.
Principles of encapsulation suggest that identifying the "Frame" to
which each of these input and output vectors refer should be the
responsibility of the higher level model (Coords/Cube/FrameSet). I.e.
if a parent object owns a set of child objects, the parent should
define how the child objects work together - each child object should
be independent of the other child objects.

> I tried sketching a domain model for this in the attached diagram. In the sketch a FrameSet is a collection of Frame-s with Mappings between them.
> A Mapping is a relation *from* one frame *to* another.

That's all as in the AST data model.

>I think a compound mapping could be expressed as a frameset with appropriate number of frames and mappings
> and is easily able to capture a situation say as in your figure 2 in https://arxiv.org/pdf/1602.06681.pdf.

Here we depart. Can you say what benefit you see from using a FrameSet
to describe a compound Mapping, rather than a compound mapping just
being a collection of Mappings? If a compound Mapping is described by
a FrameSet containing frames joined by atomic mappings we would be
storing lots of intermediate Frame information that is not needed, and
may be hard to describe. The job of adding a Frame description at
every intermediate step along a possibly long series of atomic
mappings could be serious hard work, and I can't see immediately what
benefit it would give us. Also, atomic mappings and compound mappings
would then be fundamentally different (i.e. one would have associated
frame info and the other would not).  Joining two compound Mappings
together would also be problematic since the compatibility of the
frames would need to be considered. But maybe I have misunderstood
what you are suggesting.

> To represent the datils of the Mapping I represent the Frame as a collection of axes (bit of a denormalization of the coordframe in cords model).
> Here I assume a mapping is a collection of axismappings that transform one or more (x) axes from the "from" Frame to a single (y) axis in the "to" frame.

Describing an intrinsically 2->2 mapping like a spherical projection
as two 2->1 AxisMappings seems strange - each AxisMapping would
presumably contain exactly the same parameter values (tangent point,
axis scalings etc), as would any AxisMappings used to describe the
inverse. So a Mapping used to describe a spherical projection would
end up with four identical  parameter lists (2 forward, 2 inverse)

> I.e. for simplicity I assume an *explicit* functional operation, rather than an implicit function relating the "from" and "to" axes. I think this is assumed in the transformation model as well. If necessary such implicit mappings could be handled as well.

I'm not sure I understand what you mean by "explicit" and "implicit".

> The AxisMapping also defines an operation, which is the most atomic expression of the mapping.
> In many cases this could be a mathematical equation, expressed as y=f(x1,..,xn), where y refers to the toAxis and the fromAxis collection defines how to interpret x1,..,xn and f is some function. Maybe a standardized syntax for this might be an option as I wondered in my previous email. Maybe the parameter description standard may have suggestions here as well.

Again, interpreting the inputs and outputs should probably be seen as
the responsibility of a higher level class.

> I understand that people might wish to represent the operation using some type hierarchy, but I think it is a different one than the hierarchy you referred to as being required for the compound mappings.

Can you say what the benefit would be of using different type
hierarchies for compound and atomic operations? It seems very
counter-intuitive to me. A Mapping of any type describes how to
transform a set of input values into a set of output values. Whether,
internally, this is done in a single atomic operation or as a result
of applying a series of atomic operations is an implementation detail
of each individual Mapping that should be hidden from the caller. Why
should it matter to the caller *how* a Mapping performs the
transformation?

> Polynomials can be expressed easily in such a math expression, or can be expressed as datatypes with attributes with Open ended multiplicities.

We tried using a string description for transformations back in the
1980's  (see section 2.2. of the AST paper
https://arxiv.org/pdf/1602.06681.pdf). We found that string
descriptions were difficult to use for transformation that use
iterative methods and for extremely complicated algebraic expressions
such as spherical projections that have various corner cases that need
to be trapped. The more complex an expression, the more error-prone
and difficult is its creation. That's why we went for a hierarchy of
classes that provide pre-packaged transformations, each defined a by a
small number of free parameters.

> Note that because now we have Frames explicitly expressed, and the Mapping explicitly states which is the "from" and which the "to" Frame, and the AxisMapping explicitly specifies the toAxis and fromAxes, there is not really a need to indicate a forward or inverse mapping.
> This is obvious from the assignment. If you want you can have  axismapping-s corresponding to both forward and inverse operations in a single Mapping, as you do in AST I believe. Or you could choose to only have forward axismappings and have two Mappings for a given pair of Frame-s, each once being a 'from' and once being a 'to'.

If someone was supplied with an object such as you describe, and that
object contained a pair of AxisMappings that describe how to go "from"
pixel coords "to" (ra,dec), should they also be able to use that same
object to transform an (ra,dec) position into pixel coordinates?

If I give you a simple Mapping from X to Y, like  "Y = X**2 + 1" I can
obviously use it to transform an input (X) value into an output (Y)
value. But if my implementation library is worth its salt, I could
also use it to transform an output (Y) value into an input (X) value
without needing any further information to be stored in the model.
Obviously, there are some classes of Mapping for which the inverse may
not easily be defined, but if the inverse *is* easily defined, then it
should not be necessary to store any extra information in the model to
describe it.

> This to me would solve the original issue Mark had. It makes the input/output of a mapping explicit and it isolates the actual operations that express one axis in terms of another.

That's not really how I understood Mark's problem. I though it was to
do with the technical point that vo-dml disallows two or more classes
from composing the same ObjectType.  For myself, I had in mind a much
simpler model in which each class of atomic mapping
(Shift,Scale,Permute,Polynomial,etc) was a direct subclass of the
abstract base Mapping class. A "CompoundMap" class, also a direct
subclass of Mapping, would be the one and only class that composes
Mapping, in that it would contain two or more Mappings. Then there
would be three subclass of CompoundMap:

ConcatenateMap - which combines the component Mappings in parallel
ComposeMap - which combines the component Mappings in series
BiDirectionMap (or TransMap?) - which is limited to exactly two
component Mappings  - one used to define the inverse transformation
and the other the forward transformation.

In this model, all Mappings - whether atomic or compound - are
subclasses of the same base Mapping class and so can they can all be
used interchangeably (no distinctions between compound and atomic
classes). Each subclass defines a forward transformation, and in some
cases will also define an inverse (whether a particular subclass
defines an inverse is included in the definition of the paricular
sub-class).

David





> It may need some more work for the lookup operation. Since datatype-s allow references, a lookup table might still be represented as an objecttype that such a function references.
> I think most, hopefully all of the choices in the current transformation model can be transferred to this structure as Pat was in a sense suggesting.
>
>
> Cheers
>
> Gerard
>
>
> > -----Original Message-----
> > From: David Berry <d.berry at eaobservatory.org>
> > Sent: Tuesday, March 10, 2020 12:21
> > To: Gerard Lemson <glemson1 at jhu.edu>
> > Cc: Laurent MICHEL <laurent.michel at astro.unistra.fr>; dm at ivoa.net
> > Subject: Re: [vo-dml] Clarification on composition rule..
> >
> > On Tue, 10 Mar 2020 at 10:54, Gerard Lemson <glemson1 at jhu.edu> wrote:
> >
> > > As to the case that started this discussion, I am still wondering whether the
> > issue could be resolved more elegantly once an explicit representation of the
> > things that are being mapped/transferred is added to the model.
> >
> > From the point of view of working with a similar system (AST) for many years, it
> > has been very useful to separate the representation of the variables being
> > transformed  ("Frames") from the representation of the transformation itself
> > ("Mappings") . Doing so means that you can combine Mapping objects together
> > into compound Mappings in various ways without needing to worry about  the
> > associated Frames. Most real world Mappings are formed by combining lots of
> > simpler atomic mappings together into a compound Mapping. If each atomic
> > Mapping included a description of the associated input and output variables,
> > you would end up with a large amount of redundant information in the
> > compound Mapping.
> >
> > Of course, at the end of the day you need the variable descriptions to be stored
> > some where. We have found it useful to define a higher level "FrameSet" class
> > for this purpose, which contains a tree structure of related Frames connected
> > together by (potentially compound) Mappings.
> > So for instance a FITS WCS header could be described by a FrameSet that
> > contained separate Frames describing pixel coordinates, WCS coordinates,
> > focal plane coordinates, CCD coordinates, etc, together with Mappings that
> > transform positions between each of these coordinate systems.
> >
> > David