Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!wuarchive!udel!haven.umd.edu!mimsy!dftsrv!nssdcb.gsfc.nasa.gov!brotzman
From: brotzman@nssdcb.gsfc.nasa.gov (Lee E. Brotzman)
Newsgroups: comp.lang.c
Subject: Re: Implicit decimal points in floating-point reads
Summary: Oh well, so it can't be done.  That's life.
Keywords: scanf,floating point,decimal formats
Message-ID: <5409@dftsrv.gsfc.nasa.gov>
Date: 24 May 91 05:43:45 GMT
References: <5366@dftsrv.gsfc.nasa.gov> <16222@smoke.brl.mil>
Sender: news@dftsrv.gsfc.nasa.gov
Reply-To: brotzman@nssdcb.gsfc.nasa.gov
Organization: ST Systems Corp.
Lines: 53
News-Software: VAX/VMS VNEWS 1.3-4

In article <16222@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes...
>In article <5366@dftsrv.gsfc.nasa.gov> brotzman@nssdca.gsfc.nasa.gov writes:
>>   My question:  is it possible to read data that are formatted with implicit
>>decimal points in ANSI standard C without writing my own routine?
> 
>No, there is no Fortranish support for that in *scanf() formats.
> 
>>   I'd be surprised that such an obviously useful bit of functionality
>>that has existed for decades in FORTRAN isn't available in C, ...
> 
>What is obvious to ME is that such a format is an accident waiting to strike!
> 
>It is also TRIVIAL to multiple a scanned integer by a power of 10 to scale
>it thusly.

   Doug's response has been typical of the half-dozen or so I have 
received (thanks everybody), except that it's a bit more snippish than 
most.

   This "accident waiting to happen" stuff is bunk however.  We've 
been reading data formatted with implicit decimal points quite nicely 
for a few decades now, thank you very much.  Haven't noticed any 
problem with it until I tried using C, which simply wasn't designed 
with analysis of large volumes of data in mind like Fortran was.  No flame 
there, just statement of opinion.

  In my application, I can not know beforehand whether a specific field 
has implicit decimal points, the Fortran formats don't say, they just have 
the pleasant side effect of reading them correctly either way.  
Inspecting the fields, converting the values and dividing by some 
power of ten (which must also be selected by a string inspection) is 
trivial, but perhaps not all that efficient. I'm going to be using 
this code to filter records from files with 250,000 records 200 bytes 
long on CD-ROM.  If the CD-ROM drives can't stream the data out at 
full speed, they lose their place and have to reacquire, which can 
increase search times by factors of 3 or 4, so fast conversion of 
field values is critical.

   Sometimes -- no, make that most times -- dealing with data is not nearly 
as easy as dealing with code.  Programmers tend to forget this.  Data 
processing professionals can't afford to.

   Thanks to everyone who responded publicly and privately.  No 
further comments are required, as I don't ordinarily read this 
newsgroup.

   So long,

-- Lee E. Brotzman                    Internet:  brotzman@nssdca.gsfc.nasa.gov
-- ST Systems Corp.                   SPAN:      NSSDCA::BROTZMAN
-- Astrophysics Data System           BITNET:    ZMLEB@SCFVM
-- National Space Science Data Center "Prayer: the last refuge of a scoundrel"
-- "My thoughts are my own"                                 Lisa Simpson, 1990