histograms

histograms

[Brian Gough]

I am planning to simplify gsl histograms to use linear scales in their
coordinates, dropping support for nonlinear scales (the observations
can be transformed nonlinearly instead).  If anyone sees a need to
keep nonlinear histogram scales let me know.

Re: histograms

[Christopher R. Gabriel]

    Brian> I am planning to simplify gsl histograms to use linear
    Brian> scales in their coordinates, dropping support for nonlinear
    Brian> scales (the observations can be transformed nonlinearly
    Brian> instead).  If anyone sees a need to keep nonlinear
    Brian> histogram scales let me know.

Hi Brian. Have you looked at Simone Piccardi's stuff about histograms?

-- 
Christopher  R. Gabriel  -- http://www.linux.it/~cgabriel/

"Le donne odiavano il jazz, e non si capisce il motivo" 
			      P. Conte

Re: histograms

[Brian Gough]

   Hi Brian. Have you looked at Simone Piccardi's stuff about histograms?

Thanks, yes. I am thinking of using the uniformly-binned gsl_histogramfix 
module from Simone's patch [1] as a replacement for gsl_histogram.

Advantages (as described in the README): less memory, faster, simpler,
occurs more in practice

With uniformly-binned histograms in the library it would not be
necessary to have separate code for variable-scaled histograms. The
user could get the same result by applying the equivalent
transformation to their data coordinates and storing it in a
uniformly-binned histogram.  I prefer this approach because it keeps
the library simple.

[1] http://www.firenze.linux.it/~piccardi/histfix.tar.gz

Re: histograms

[Craig P Prescott]

Hi;

I read Simon Piccardi's READMEs in his histfix patch, and would be
very excited to see ntuple support in the GSL.

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?

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.

Finally, I am wondering about a portable binary data format for GSL
histograms.  Is something like that envisioned to be part of the GSL?

I realize that these kinds of things might be thought to be outside
the scope of the GSL, or just plain bloat.  But I am thinking that
having the GSL provide some of this functionality might be a "Good
Thing", as in less very similar code in GSL apps developed by
different people.  And if there was an "official" GSL portable binary
format, I can imagine powerful data analysis and visualization tools
supporting it, and even being built around the entire GSL.

Anyway, I'm rambling.  I'm guessing all this has been thought about
before, and I am just curious about the GSL developer's thoughts on
the subject.

I very much enjoy using the GSL in my project, and I'd like to thank
the developers of it for putting in the hard work to make such a
powerful toolkit.

Cheers,
Craig
---
Craig Prescott                                (352) 846-3145 (Phone)
2011 New Physics Building                     (352) 392-8863 (Fax)
University of Florida, Gainesville, FL 32611  prescott@phys.ufl.edu

Re: histograms

[Simone Piccardi]

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!"

Re: histograms

[Brian Gough]

Hi,

GSL philosophy is to provide "raw" functions that other applications
can build on top of, analogous to the low-level i/o functions in the
standard C-library.

So the fprint/fwrite functions only dump out the data part and leave
it to the user to deal with metadata in the way that is appropriate
for their application. 

As with GSDV there could be libraries built on top of GSL that would
assist the user in writing GSL data types in different formats
(e.g. gslxdr, gslhdf, etc). Designing a library for portable IO would
be a project in itself though.

regards
Brian Gough



   Date: Wed, 11 Oct 2000 06:41:58 -0400
   From: Craig P Prescott <prescott@phys.ufl.edu>

   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?

Re: histograms

[Simone Piccardi]

Brian Gough wrote:
> 
> I am planning to simplify gsl histograms to use linear scales in their
> coordinates, dropping support for nonlinear scales (the observations
> can be transformed nonlinearly instead).  If anyone sees a need to
> keep nonlinear histogram scales let me know.
More than for the nonlinear scales, the variable range histogram could
be useful when you have to specify a choice of a different size binning
based in some pratical issue. I had to do something like this on data
analysis to have a "comparable" statistics on each bin and to take in to
account the different selections used in different range (due to the
usefulness of some detector data). 

But as you said having both the two kind of histogram will grow the
complexity of the library. The problem is that I'm working also on
"profile" histograms, to represent 2D distributions; and this will lead
to another kind of histogram.

A solution for the fix/variable ranges could be to provide a
"linearization function" automatically generated from a set of ranges
(it's only a guess, I never thinked in this direction), but this cannot
solve the problem for the profile histograms.

The other one is to use some sort of abstraction layer (gnome has such
an architecture) for histograms. I'm thinking about this (Christopher
Gabriel suggested me to use GtkObject, but it seems to me an overkill
for what I need and I would like something simpler). Let me know what
you think about this.

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

Re: histograms

[Christopher R. Gabriel]

    Simone> The other one is to use some sort of abstraction layer
    Simone> (gnome has such an architecture) for histograms. I'm
    Simone> thinking about this (Christopher Gabriel suggested me to
    Simone> use GtkObject, but it seems to me an overkill for what I
    Simone> need and I would like something simpler). Let me know what
    Simone> you think about this.

Actually, AFAIK, the object system of Gtk is moving into glib
(GObject), so you don't have the X dependency of Gtk/Gdk. It's
everything in the unstable branch of glib/gtk, I think that could be
useful for our stuff (the only issue is that we don't know when it's
going to stable, so developers must upgrade to unstable to use the
library).

-- 
Christopher R. Gabriel

Re: histograms

[Craig P Prescott]

Hi, Simone and Brian;

Thanks for your thoughtful replies.

I completely understand the goal of not wanting to clutter the GSL up
with non-essential (for its purposes) stuff.

GSDV sounds interesting.  I would be glad to hear of (and perhaps
contribute to) projects which might help the user read/write GSL data
types in various formats.

Cheers,
Craig
---
Craig Prescott                                (352) 846-3145 (Phone)
2011 New Physics Building                     (352) 392-8863 (Fax)
University of Florida, Gainesville, FL 32611  prescott@phys.ufl.edu