NeXus SDS

[Ray Osborn]

on 2000/1/11 4:59 PM, Eric Boucher at boucher at aps.anl.gov wrote:

> 
> So to sumarize we'll end up with something like that for a dataset stored
> with the C style, ie A is the slowest varying dimension and D is the fastest
> varying one.
> 
> signal[A     , B      , C      , D]
> ^       ^        ^        ^
> dim:     dim[0]   dim[1]   dim[2]   dim[3]
> NeXus:axis=4   axis=3   axis=2   axis=1
> HDF:  fakeDim0 fakeDim1 fakeDim2 fakeDim3  (will desapear)
> 
> Isn't it counter intuitive ?

Actually, I like the fact that axis=1 refers to the x-axis, axis=2 refers to
the y-axis etc.  That seems to me to be very intuitive, and indeed it's what
you assumed in your first post.  To quote :

>>> 
>>> What is the apropriate way to store NeXus SDS.
>>> Is it the C style   : array[z,y,x]
>>> or the fortran style: array[x,y,z]
>>> 

When you open a two-dimensional array in a generic browser, like the SciSpy
Browser, the data are arranged in the same way that you would plot them
(assuming the x-axis is horizontal and the y-axis vertical).  Of course, the
y-axis is inverted, but nothing's perfect.

My opinion is that the current choice is intuitive for non-programmers
(axis=1 means x-axis), but may be counter-intuitive for programmers (axis=1
means dim[rank]).  However, programmers are paid to think harder about these
things, so I think that's the right way around.

Anybody have any alternative views on this?

> I think it would be better not to mix the standards. Either use one or the
> other, and since the fortran style might not be supported in the future, why
> not choose the C style for the dimensions AND the axis attribute:
> The data set with the highest axis attribute corresponds to the fastest
> varying dimension.

I hope that I didn't give the impression that the Fortran API is not going
to be supported in the future.  I said that the NXbrowse F90 terminal
browser might disappear because I didn't want to have to maintain two
functionally identical programs.  However, we are definitely committed to
maintaining the Fortran API, since I don't believe that the use of Fortran
for numerical programming is going to disappear any time soon.  In fact,
programming in the F90 API is, in my very biased opinion, slightly easier
than in the C API, because of the use of generic functions and optional
parameters (However, that's definitely only my opinion, so please don't
start a religious war).

> 
> This will be a big help for our NeXus files because we can have different
> signal that could share the same axis data sets instead of duplicating them
> and giving them different axis info.
> 

I think you have raised some very important issues concerning the linking of
axes and data, even if I disagree with you on the axis attribute definition.
I intend to write another e-mail with an alternative proposal that may get
around your problem.  This one is already long enough.

Best regards,
Ray
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845