[vo-dml] Clarification on composition rule..

[David Berry]

Again - apologies for replying on the wrong thread!

David

On Tue, 10 Mar 2020 at 16:30, David Berry <d.berry at eaobservatory.org> wrote:
>
> 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