[QUANTITY] The discussion so far

DIDELON Pierre dide at discovery.saclay.cea.fr
Fri Oct 31 05:29:16 PST 2003


> From root Fri Oct 31 12:48:05 2003
> Date: Fri, 31 Oct 2003 11:48:03 +0000 (GMT)
> From: David Berry <dsb at ast.man.ac.uk>
> To: DIDELON Pierre <dide at discovery.saclay.cea.fr>
> cc: dm at ivoa.net, jcm at head-cfa.harvard.edu
> Subject: Re: [QUANTITY] The discussion so far
> MIME-Version: 1.0
> X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) 
>     *1AFXl5-0002fl-Vm*gqwZyap4WOw*
> 
> Pierre,
> 
> > Waouh! Big work, impresive summary.
> 
> Agreed!
> 
> > Array-1D OK,  ND flattened in 1D (like pat proposal) OK.
> > Otherwise we are no longer speaking of simple quantity but of
> > complex dataset, data collections, images or whatever.
> > I agree with doug email about hierachical data structure
> > (http://www.ivoa.net/forum/dm/0219.htm) and may be we have to agree
> > and try to define such a common (VO-DM) hierchy of data structure.
> 
> Is there really much difference between a 1-D array and an N-D array? Is
> it not just a case of the number of indices you need to locate an
> element within the array? If one is OK, why not the other? Allowing N-D
> does not really add much complication in my opinion, and does allow the
> structure (what ever we call it) to be of much wider use. It also removes
> the need for a another layer of structure, which would be needed to
> introduce N-D arrays if this basic structure was restricted to 1-D.

Having layer would allow to chose a level (layer) of complexity, without
having to tag (or add some informational data member/attribute, class functionality, 
sub casting,...) objects to define the level of complexity of an object. 

But nevertheless, we can do the other way round, in modelling, if you wish,
try ingto define a hierachy of data structure, (inspired perhaps, by the one
proposed by Doug, or any else departing point), and then if we can collpse it
in one big thing as a whole, without too much overhead for simplest
structure... why not.

> 
> 
> > I am in favor of having very simple class, firstly due to a general aspect,
> > that very simple class are very general and can be reuse more oftenly
> > without too much overhead. When you only need a value and his unit
> > would you be inclined to use (in your code apllication or even in your
> > appl definition) a class which contains a lot of other things you
> > really don't care about? I feel that scientist (even computer ones) often use ,
> > perhaps implictly, the Occam blade to throw away and suppress superfluity.
> 
> The sort of higher level N-D structure which I proposed ("DataContainer"
> in Jonathan's message - but I'm not comitted to any particular name) can
> be as simple as required since all components are optional. Ray also made
> this point in his requirements list. Defining a class which includes
> errors, quality, units, label, wcs, etc, is no burden in situations
> where simple structures are more appropriate, since you can simply omit
> the components which are not relevant. Let's have one structure which is
> exandable rather than lots of little rigid structures.
> 
an other point is that agreement would be reach faster on small classes
than on "the whole big thing in one". The actual discussion about
"who is what" seems to me a good illustration (imo).
I feel like if we are not able to keep Q as simple as possible, we will
go nowhere (but I may be wrong, hopefully).

Pierre



More information about the dm mailing list