Re: histograms

[Simone Piccardi <piccardi at fi dot infn dot it>]

Craig P Prescott wrote:
> 
> Hi;
> 
> I read Simon Piccardi's READMEs in his histfix patch, and would be
> very excited to see ntuple support in the GSL.
It's extremely preliminary. And need a lot of work on the user side (on
the definition of the ntuple structure data, and in the selection and
values functions). I would like to have some sort of automatization (my
idea was to use some preprocessor macros, but I was not capable to
implement anything usable). 
> 
> Speaking of histograms, I've got a question or two, and maybe a couple
> ideas.
> 
> I want to have many histograms in the same file, which I may want to
> read in again with another (or the same) GSL-aware app.  What do
> developers using the GSL do to accomplish this?  It seems the
> developer must write their own header for each histogram so you know
> what kind of histogram it is and what its dimensions are.  Should the
> GSL *_fread/fwrite *_fprintf/fscanf take care of this for us?
> 
The routines for the fixed size histograms just write the histogram into
a file; when I wrote them I was just thinking to write an histogram in a
single file. It is also possible to recreate the histogram from the
file, without the need of a previous knoweldge of its size from the
developer (I added this function just because the size of the histogram
is written on the file, and I found useful to do the whole thing
automatically). 

Writing more than one histograms in the same file it's probably already
done; its just matter of using the same file pointer when writing, and
the same is true when reading, but this give you only a sequential
access (and a complete mess in case of errors). A seek function (to go
to the N-th histo in a sequential scan) doesn't seems too complex to do,
something more complex can be done, at the price of complexity, and I
would like to take things as simple as possible in this layer.

> Similarly, it would be nice to be able to give a histogram a title, so
> when we read it back in we know something about it.  Maybe some axis
> labels, too.  And an identifier of some kind would also be great;
> i.e., say I only want to read in a certain histogram or certain set of
> them.  Maybe some other metadata, too.
This is how the hbook package works; it's part of the cernlibs (see at
http://wwwinfo.cern.ch/asd/cernlib/) and I took a lot of ideas from
there (now cernlibs are GPL, so if someone like fortran and spaghetti
code can also take something more than ideas). In my opinion this is
outside GSL; I prefer to avoid to put too many things inside an
histogram data structure; we are doing some work (with Cristopher
Gabriel) to produce a set of visualization routines that use GSL
histogram as base for histogram storing (the project is called GSDV, GNU
Scientific Data Visualization library but it's in a very early stage),
this should be the more appropriate place where to put labels and other
visualization related data, but probably some sort of identifier could
be useful when written in to a file.

> 
> Finally, I am wondering about a portable binary data format for GSL
> histograms.  Is something like that envisioned to be part of the GSL?
> 
This is an issue that should be implemented; if you stay inside GSL it's
probably just matter of taking into account the endianess and the
histogram data types using some sort of header at the beginning of the
file. 

Bye
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"