[Obscore1.1] WD comments

Laurent MICHEL laurent.michel at astro.unistra.fr
Sat Oct 31 03:25:55 CET 2015


To be honest I've (we) never been happy with *_dim which, even in 
French, refers to a number of axes. Unfortunately, we (including native 
speakers) didn' find a better word which is agnostic (neutral) enough: 
Pixels make us thinking about a camera, length make us think about meters...
In such situation a solution could be to define an acronym or to use an 
obfuscating abbreviation.
That is why I support your proposal of using *_nbr which

About time, I do not remind whether the scale is free: to be checked.

LM

Le 31/10/2015 02:54, Arnold Rots a écrit :
> Along a new thread, the _dim items had escaped my notice.
> As discussed, the word "dimension" is confusing in this context
> and people started wondering about units.
> It is defined in the text as "number of samples".
> It seems to me that better choices for "dim" would be:
> len[gth], nsamp, num, nbr, or even npix (most samples will be pixels).
>
> I also noticed that the time scale is completely missing from the
> time axis. Anyone interested in accurate timing might want to know
> what timescale the resource is using - TT, TDB, TAI, UTC, GPS, ...
>
> Cheers,
>
>    - Arnold
>
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1
> 617 495 7356
> Cambridge, MA 02138 arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>
> USA http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------------------------------------------
>
>
> On Wed, Jul 15, 2015 at 9:43 AM, Arnold Rots <arots at cfa.harvard.edu
> <mailto:arots at cfa.harvard.edu>> wrote:
>
>     This may get complicated.
>     In principle, I agree, but some axes may actually be binned, such as
>     chip coordinates and pulse height...
>
>        - Arnold
>
>     -------------------------------------------------------------------------------------------------------------
>     Arnold H. Rots                                          Chandra
>     X-ray Science Center
>     Smithsonian Astrophysical Observatory                   tel: +1 617
>     496 7701 <tel:%2B1%20617%20496%207701>
>     60 Garden Street, MS 67                                      fax: +1
>     617 495 7356 <tel:%2B1%20617%20495%207356>
>     Cambridge, MA 02138 arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>
>     USA http://hea-www.harvard.edu/~arots/
>     --------------------------------------------------------------------------------------------------------------
>
>
>     On Mon, Jul 13, 2015 at 8:45 AM, Laurent MICHEL
>     <laurent.michel at astro.unistra.fr
>     <mailto:laurent.michel at astro.unistra.fr>> wrote:
>
>         Hello,
>
>         I do not think that t_dim is better suited than e_dim or s_dim
>         to specify the number of events. Finally, an event is just a
>         point within a 4dims space (S1/S2/E/T) and none of these axes
>         has a special role.
>         Considering that, I think the number of events should be
>         reported in all *_dim columns. The ambiguity about binned axes
>         or not is removed by the appropriate "dataproduct_type" value.
>
>         Laurent
>
>
>         Le 25/06/2015 03:06, Douglas Tody a écrit :
>
>             On Wed, 24 Jun 2015, CresitelloDittmar, Mark wrote:
>
>                 pg 25: Axes dimensions
>                   Outside of the pixelated image context, what values do
>                 these hold?
>                   For example, the sparse cube (ie: event list).  do
>                 each of these hold
>                   the #events? or are s_dim1,s_dim2 ==  the span along
>                 that axis? and
>                   if so, in what frame?
>                   It seems that #events is closest to the description as
>                 the number of
>                 samples.
>
>
>             For event data which is not imaged, such as an event list,
>             probably the
>             best one can do is have t_dim specify the number of events.
>             The spatial
>             coverage would be specified with s_fov and the spectral
>             coverage with
>             em_min/max.  The binning on the spatial and spectral axes is
>             meaningless
>             and should be zero.  If a precomputed image for the
>             observation is also
>             provided, that would have all the dim values and would share
>             the same
>             obs_id.
>
>                   - Doug
>
>
>         --
>         ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>               Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>               11 Rue de l'Universite      Mail
>         laurent.michel at astro.unistra.fr
>         <mailto:laurent.michel at astro.unistra.fr>
>               67000 Strasbourg (France)   Web
>         http://astro.u-strasbg.fr/~michel
>         ---
>
>
>

-- 
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---


More information about the dm mailing list