From: Mark Holm 
To: atm{at}shore.net
Reply-To: Mark Holm 


Hi,

When I woke up this morning, I thought of a couple of more conditions for
the proposed 1-D surface profile output standard.

1. Stick to the lower 128 characters in ASCII, even in comments.  I know this is
awfully English-centric, but there really shouldn't be much need for more
characters in this application, and it helps keep the thing as hardware and
OS independant as possible.

2. Special values may be contained in lines that do not begin with the
comment character and do not begin with a numeric character.  The starting
characters would have to be part of the standard.  The one example that
made me think of it is:

COR 39.00

This would be the Central Obstruction Radius, for the case of a round
central obstruction.  (39.00 is just an example value.)

3. As I said before, white space characters, space and tab, would be
allowed, but discouraged at the beginning and end of lines, but the CR or
CRLF would always mark the end of a line.

4. Tabs are allowed but discouraged, spaces are preferred.

5. For simplicity, no other non printing characters allowed, beyond space,
tab, carrige return and line feed.

6. Again being US centric, the standard decimal separator would be a period (.).
   No thousands separator would be used or allowed.

(Can you tell, my brain is in parser mode?)

7. The standard would be to specify a surface value every millimeter.  The
writer of the test analysis software would be responsible for the
interpolation between test values down to the millimeter level. 
Optionally, finer specification is allowed, within the limits (2 decimal
places) of the standard, but millimeter resolution would be the minimum.  I
think this will be sufficient
for FFT based diffraction pattern construction.  (Jim Burrows knows more
about the math constraints on FFT spatial resolution.)


I have been thinking a little about a standard for 2-d surfaces also.  The
bandwidth inefficiency of ASCII begins to be more of a problem.  Binary,
double precision would be more compact.  I think there is more of a problem
with double
precision floating point representations and binary file formts.  I don't
know all of the complications.  Isn't there still a problem with bigendian
and littleendian storage formats on popular computers?  Do all the popular
compilers
out there support ANSI double precision for storage?  How to format for
inclusion of non numeric data such as comments, and non array data such as
Central Obsruction Radius?


Mark Holm
mdholm{at}telerama.com

--- BBBS/NT v4.00 MP