I agree with Joanne that I prefer option (b) for the geometry. I would
suggest that we try to develop some formal description for dealing with
file evolution, possibly writting a human readable version and some kind
of checksum into the header.

In the JAS and hep.lcd code we use doubles exclusively, but that doesnt
mean that SIO needs to output the numbers as doubles. I tend to favour
float for IO since it gives more than adequate resolution for all the
quantities we write out and saves space.

Tony

> -----Original Message-----
> From: Joanne Bogart [mailto:[log in to unmask]]
> Sent: Wednesday, November 10, 1999 9:10 AM
> To: [log in to unmask]
> Cc: [log in to unmask]
> Subject: Re: Introducing SIO
> 
> 
> 
> 
> [log in to unmask] wrote:
> > 
> > I am in the final stages of retrofitting SIO into our 
> baseline Gismo/GismoApps.
> > So now might be the time to set up an SIO punch list:
> > 
> >  1) Pending Masako's confirmation, I believe that 
> Gismo/GismoApps produce
> >     identical -data- in ASCII and SIO format.  On the other 
> hand, I have made
> >     no provision for SIO to produce the conventional ASCII 
> file -header-
> >     consisting of the complete geometry description used in 
> the job.  How
> >     should this be handled?
> > 
> >     a) I could simply write out the ASCII strings as SIO data.
> >     b) I could write out the name of the file which the 
> program read to
> >        get it's geometry data (a little risky ... we have 
> no formal method
> >        defined to handle desciption file evolution).
> >     c) We could ignore the problem.  (Not good!)
> 
> I would prefer a solution along the lines of b), but have no serious 
> suggestion.  Currently the rewritten geometry description is 
> skipped by all
> data file readers (except perhaps for the occasional human being).
>  
> The only pre-existing versioning we have is via CVS, but how 
> does this work 
> if someone just wants to make a small change to a standard 
> file, perhaps at 
> a remote site?    
> 
> >  2) I am currently writing all floating point numbers as 
> 'float'.  Should
> >     we go to 'double'?  I note that the current asc2root 
> converts everything
> >     to 'float' so the extra precision would be lost there.  
> What would JAS
> >     prefer?  Does it matter?  (It could be argued that 
> 'float' precision is
> >     plenty for hit positions, direction cosines, energy,... 
> .  I start
> >     getting uncomfortable when it comes to things like 
> error matrices
> >     where even small losses in precision can result in 
> instabilities).
> I vote for doubles in critical places at least; I would 
> prefer to go to 
> doubles entirely if the overhead isn't intolerable.  (The new 
> code which
> interprets the XML geometry description uses doubles everywhere.)
> The Root event classes do appear to use float everywhere, but probably
> shouldn't (cal part of FastMC already mostly uses double internally).
> Changing them would be tedious but straightforward.
> 
> 
> > 6) Anything I've forgotten?
> I hope not (and don't think so).
> 
> > 
> > Tony Waite.
>              Joanne
>