Proposal to split out the "members" from coreQ (Was: Re: Philosophy of basic Q)

[David Berry]

Brian,

> > But there is no evidence of it in the interface, and does there need to
> > be?
>
> 	CoreQ has "getMembers()". The add/removeMember methods appear
> 	to be dropped from the 0.5 document, but that may be because the
> 	intention is to use "setValue(Obj,loc)", which I think is bad.

OK. Sorry - overlooked the getMembers() method. I seem to remember that
was one of those things we never agreed on but were going to come back to
once the document had been made public. But note that the Fig. 1 has no
indication of any concept of "members", and there is nothing in section
6.2.3 about members. I guess now is the time to attempt to get to the
bottom of this issue.


> > What benefits do your suggestions give us in terms of the actual *data
> > model* (as described by the interface) rather than in the specific form of
> > the serialisation you suggest in the doc?
>
> 	I have already described this. But here it is again, please read :

May be the confusion is caused by using terms introduced by the
serialisation, rather than by the interface. I presume in what follows you
are talking about the *interface* terms?

> 1. CoordsQuantity is a Q which holds other Q's (the dimensions/axes).

By "CoordsQuantity", do you mean the quantity returned by the
getCurrentCoordsQuantity() method? This method returns a CoreQ. So you are
just stating here that "A CoreQ has members". But that is the very
thing I am asking you to justify - *why* does a CoreQ need to have
members? Why not just have a n-dimensional Frame, with an n-dimensional
ValuesList or Mapping? This reflects clearly the model that "a CoreQ is
made up of a Frame and a Mapping".

> It doesn't hold values.. it holds only other Q's.

Why? Wont CoreQ used to describe axes usually contains a (Mapping
or ValuesList), to say how to get from the input coords to the output
coords?

> Therefore, even if it is currently called a CoreQ, it is a special one,
> which doesn't hold values (number/strings) but objects instead as its
> "data". A separate interface is probably the cleaner way to implement
this.

You asked me to "please read" - I am reading and I just do not understand!
A CoreQ contains an n-dimensional Frame which describes the coordinate
system spanning the space occupied by the Values of the coreQ, it also
contains a n-dimensional Mapping which will transform a supplied input
value (usually pixel values within the parent StdQ) into that
n-dimensional Frame. I just do not see how this relates to what you are
saying.

> 2. You can use CompositQ/Quantity to build tables and more complex Q's as
> (I anticipate) will be needed by other higher -level DM modelers.

Why can we not do this with the normal CoreQ and StdQ?

I *have* read and I still do not understand what members are or why we
need them.

David


----------------------------------------------------------------------
Dr David S. Berry    (dsb at ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX                                Tel. 01772 893733
                                             01257 273192