Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12731 > unrolled thread

newby question on C I/O

Back to article view | Back to comp.lang.c

Contents

  newby question on C I/O "analyst41@hotmail.com" <analyst41@hotmail.com> - 2011-11-04 15:07 -0700
    Re: newby question on C I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-04 20:50 -0400
      Re: newby question on C I/O "analyst41@hotmail.com" <analyst41@hotmail.com> - 2011-11-04 18:57 -0700
      Re: newby question on C I/O "analyst41@hotmail.com" <analyst41@hotmail.com> - 2011-11-07 17:10 -0800
        Re: newby question on C I/O Ian Collins <ian-news@hotmail.com> - 2011-11-08 14:47 +1300
        Re: newby question on C I/O "BartC" <bc@freeuk.com> - 2011-11-08 01:52 +0000
        Re: newby question on C I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-07 20:56 -0500
          Re: newby question on C I/O Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-08 20:27 +0000
            Re: newby question on C I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-08 20:48 -0500
            Re: newby question on C I/O "BartC" <bc@freeuk.com> - 2011-11-09 11:12 +0000
              Re: newby question on C I/O James Kuyper <jameskuyper@verizon.net> - 2011-11-09 07:02 -0500
                Re: newby question on C I/O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-09 16:12 +0000
          Re: newby question on C I/O - SUCCESS "analyst41@hotmail.com" <analyst41@hotmail.com> - 2011-11-08 16:12 -0800
    Re: newby question on C I/O James Kuyper <jameskuyper@verizon.net> - 2011-11-04 21:46 -0400
      Re: newby question on C I/O Ike Naar <ike@iceland.freeshell.org> - 2011-11-05 06:52 +0000
        Re: newby question on C I/O Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-05 04:13 -0700
        Re: newby question on C I/O James Kuyper <jameskuyper@verizon.net> - 2011-11-05 08:16 -0400
          Re: newby question on C I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 09:21 -0400
        Re: newby question on C I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-05 09:13 -0400
      Re: newby question on C I/O David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
        Re: newby question on C I/O James Kuyper <jameskuyper@verizon.net> - 2011-11-21 10:05 -0500
          Re: newby question on C I/O David Thompson <dave.thompson2@verizon.net> - 2012-01-19 02:40 -0500
    Re: newby question on C I/O "BartC" <bc@freeuk.com> - 2011-11-06 21:23 +0000
    Re: newby question on C I/O "analyst41@hotmail.com" <analyst41@hotmail.com> - 2011-11-10 18:00 -0800
      Re: newby question on C I/O Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-11 01:35 -0800
        Re: newby question on C I/O gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-11 11:26 +0000
          Re: newby question on C I/O Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-11 04:41 -0800
            Re: newby question on C I/O gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-11 14:14 +0000
              Re: newby question on C I/O Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-11 07:02 -0800
                Re: newby question on C I/O gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-11 15:44 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13709

On 11/21/2011 02:39 AM, David Thompson wrote:
> On Fri, 04 Nov 2011 21:46:03 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
> 
>> On 11/04/2011 06:07 PM, analyst41@hotmail.com wrote:
>>> I have a file that looks like
>>>
>>> Value Cost Special_Status
>>> 12    34          Yes
>>> 21    44          yes
>>> 32    43           no
>>> .....................
>>>
>>> I can read it into some arrays (or a data frame using R) using Fortran
> <snip>
>>>        read (1,*,end=100) values(j),costs(j),statuses(j)
>>
>> The '*' in that READ statement, where a FORMAT would ordinarily go,
>> indicates implicit formatting. A key difference between C and Fortran is
> 
> Yes. Formally called 'list-directed' formatting.
> 
>> that I/O is a built-in part of the Fortran language, while in C I/O is
>> handled by standard library functions. Given the way C functions work,
>> that means that something equivalent to the implicit formatting used by
>> the READ statement above isn't feasible in C. The simplest approach
> 
> Well, the syntax is a little different, but so is C stdio vs Fortran
> classic explicit-format. Functionally, what Fortran list-directed
> input does is a little different from what Standard C *scanf does, so
> you would have to write maybe a page or two of code to fullly handle
> it, which you could put in a utility function and reuse as needed. 

The key characteristic of Fortran list-directed input that I was talking
about is the fact that you don't have to identify the types of the
expressions you are printing; that information is implicitly determined
by looking at the expressions themselves. C++ function overloading makes
it feasible to do something similar in the <iostream> part of the C++
standard library (though you do have to provide your own overloads for
operator<<() and operator>>() for any user-defined type), but I don't
see any way to implement such a feature in "a page or two of code" in C.
Could you explain how that would work?

[toc] | [prev] | [next] | [standalone]

#15938

On Mon, 21 Nov 2011 10:05:10 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

> On 11/21/2011 02:39 AM, David Thompson wrote:
> > On Fri, 04 Nov 2011 21:46:03 -0400, James Kuyper
> > <jameskuyper@verizon.net> wrote:
> > 
> >> On 11/04/2011 06:07 PM, analyst41@hotmail.com wrote:
<snip>
> >>>        read (1,*,end=100) values(j),costs(j),statuses(j)
> >>
> >> The '*' in that READ statement, where a FORMAT would ordinarily go,
> >> indicates implicit formatting. A key difference between C and Fortran is
> > 
> > Yes. Formally called 'list-directed' formatting.
> > 
> >> that I/O is a built-in part of the Fortran language, while in C I/O is
> >> handled by standard library functions. Given the way C functions work,
> >> that means that something equivalent to the implicit formatting used by
> >> the READ statement above isn't feasible in C. The simplest approach
> > 
> > Well, the syntax is a little different, but so is C stdio vs Fortran
> > classic explicit-format. Functionally, what Fortran list-directed
> > input does is a little different from what Standard C *scanf does, so
> > you would have to write maybe a page or two of code to fullly handle
> > it, which you could put in a utility function and reuse as needed. 
> 
> The key characteristic of Fortran list-directed input that I was talking
> about is the fact that you don't have to identify the types of the
> expressions you are printing; that information is implicitly determined
> by looking at the expressions themselves. C++ function overloading makes
> it feasible to do something similar in the <iostream> part of the C++
> standard library (though you do have to provide your own overloads for
> operator<<() and operator>>() for any user-defined type), but I don't
> see any way to implement such a feature in "a page or two of code" in C.
> Could you explain how that would work?

Aha. You were distinguishing all Fortran I/O (with special statements
which are aware of types) from C (with function calls that aren't).

I thought you were focussing on the difference between implicit (star)
format and explict format like 'I4, F9.2', and for that matter
namelist which also does formatting/parsing but slightly different.
That is what I meant a page or so of C can do.

Yes, using actual types to drive or check formatting/parsing is a
feature of Fortran (and some other languages) not available in C.

One approach I have used in a few cases involving formatting/parsing
of a fairly large number of structure types is a code generator that
produces C declarations and corresponding C I/O routines. I've also
seen some decent table-driven methods. Both of those are add-ons.

[toc] | [prev] | [next] | [standalone]

#12831

<analyst41@hotmail.com> wrote in message
news:0f0ee88e-09f4-43ca-8c95-84f9a4846455@c1g2000vbw.googlegroups.com...
> I have a file that looks like
>
> Value Cost Special_Status
> 12    34          Yes
> 21    44          yes
> 32    43           no
> .....................
>
> I can read it into some arrays (or a data frame using R) using Fortran
> trivially
>
>         subroutine getdat(values,costs,statuses.items)

>        character statuses*3
>        real values,costs
>        dimension values(1000),Costs(1000),Statuses(1000)

This looks weird Fortran (I'm sure you never needed to declare arrays in two
steps.)

But anyway, you have a file containing 3 numbers per line, and hopefully not
more than 1000 lines, to read into these arrays.

This sounds like line-oriented input. I can do this in C, but with several
layers of functions over the standard C functions. I think at the bottom of
the pile of functions, is a fgets() call, and a sscanf() call (a version of
scanf), and a bit of string processing to chop up each line into tokens.
sscanf() is made to operate on one token at a time (each a separate string).

 Quite a lot of work, but it means that in the end I can just do:

  'read the next line into a buffer'

  'read a floating point number' (into values[i])
  'read another number' (into costs[i])
  'read a name' (into status[i])

without ever again having to delve into the mysteries of scanf().

If end-of-buffer is encountered, then it will read 0.0 or "", rather than
wrap to the next line and get everything out of step.

So, yes it is harder than Fortran, but it's doable with some effort.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13075

On Nov 4, 5:07 pm, "analys...@hotmail.com" <analys...@hotmail.com>
wrote:
> I have a file that looks like
>
> Value Cost Special_Status
> 12    34          Yes
> 21    44          yes
> 32    43           no
> .....................
>
> I can read it into some arrays (or a data frame using R) using Fortran
> trivially
>
>          subroutine getdat(values,costs,statuses.items)
>
>         character statuses*3
>         real values,costs
>         dimension values(1000),Costs(1000),Statuses(1000)
>
>          integer items, j
>
>         open (unit=1,file="filename")
>
>         read (1,*)
>
>         j = 0
>         do
>         j = j + 1
>        read (1,*,end=100) values(j),costs(j),statuses(j)
>        enddo
>
> 100 continue
>
>       items = j - 1
>
>       stop
>       end
>
> Seems much harder in C - can anyone post an intuitive, easy solution
> to do this in C?
>
> Thanks.

Now that my problem has been solved, I wish to point out that this is
a one-liner in R:

if data.txt looks like

value, cost, premium_status
22  , 43,  "yes"
54 ,  32 ,   "no"
65 ,  43  , "yes"

In R you would do (a is an object called a data frame - like a table
in SQL terminology).

> a = read.csv("data.txt",stringsAsFactors=FALSE)
> a
  value cost premium_status
1    22   43            yes
2    54   32             no
3    65   43            yes
> mode(a$value)
[1] "numeric"
> mode(a$cost)
[1] "numeric"
> mode(a$premium_status)
[1] "character"


R would treat the header values as column names and even assign a type
to each column.

[toc] | [prev] | [next] | [standalone]

#13082

On Nov 11, 4:00 am, "analys...@hotmail.com" <analys...@hotmail.com>
wrote:
> On Nov 4, 5:07 pm, "analys...@hotmail.com" <analys...@hotmail.com>
>
> Now that my problem has been solved, I wish to point out that this is
> a one-liner in R:
>
>  a = read.csv("data.txt",stringsAsFactors=FALSE)
>
I've got a readcsv C subroutine on my website. it's many line sof C,
but, once written, it allows you to read a csv file in one call.

The main problem with the code is that generating nans and testing fro
them, portably, is difficult.
--
For the csv routine
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#13084

In article <3010f4e8-ae0d-4e79-87ad-637cf26824cb@e2g2000vbb.googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Nov 11, 4:00 am, "analys...@hotmail.com" <analys...@hotmail.com>
>wrote:
>> On Nov 4, 5:07 pm, "analys...@hotmail.com" <analys...@hotmail.com>
>>
>> Now that my problem has been solved, I wish to point out that this is
>> a one-liner in R:
>>
>>  a = read.csv("data.txt",stringsAsFactors=FALSE)
>>
>I've got a readcsv C subroutine on my website. it's many line sof C,
>but, once written, it allows you to read a csv file in one call.
>
>The main problem with the code is that generating nans and testing fro
>them, portably, is difficult.

I assume you are referring to:

    http://www.malcolmmclean.site11.com/www/CSVtoC/csvtoc.html

Be aware that that generates C code as output, which is not what one usually
expects to get from a CSV parser.

Unless I am mistaken...

-- 
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof. 

    - John Kenneth Galbraith -

[toc] | [prev] | [next] | [standalone]

#13085

On Nov 11, 1:26 pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <3010f4e8-ae0d-4e79-87ad-637cf2682...@e2g2000vbb.googlegroups.com>,
>
> I assume you are referring to:
>
>    http://www.malcolmmclean.site11.com/www/CSVtoC/csvtoc.html
>
> Be aware that that generates C code as output, which is not what one usually
> expects to get from a CSV parser.
>
> Unless I am mistaken...
>
If you take the file csv.c and csv.h you get a general-purpose csv
file loader, which obviously needs a surrounding C program or program
with a  C interface to use. The utility is a stand alone program built
on top of that.
--
Download the csv file loader
http://www.malcolmcmlean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#13088

In article <588d197d-615e-450a-99eb-8990ab483279@n6g2000vbg.googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Nov 11, 1:26 pm, gaze...@shell.xmission.com (Kenny McCormack)
>wrote:
>> In article <3010f4e8-ae0d-4e79-87ad-637cf2682...@e2g2000vbb.googlegroups.com>,
>>
>> I assume you are referring to:
>>
>>    http://www.malcolmmclean.site11.com/www/CSVtoC/csvtoc.html
>>
>> Be aware that that generates C code as output, which is not what one usually
>> expects to get from a CSV parser.
>>
>> Unless I am mistaken...
>>
>If you take the file csv.c and csv.h you get a general-purpose csv
>file loader, which obviously needs a surrounding C program or program
>with a  C interface to use. The utility is a stand alone program built
>on top of that.

Ok, so we *are* talking about the same thing, right?  We agree on that?

My point is this:  If I am reading it correctly, the output of running the
program is two pieces of C code - 1 that defines the struct and the other
that contains the data itself (as an initializer).  So, the point is that
the data is fixed at compile time.

Which coudl certainly be useful, in some contexts, but is certainly not what
I think an average person would expect from a "CSV loader".

-- 
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com).  But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

Nevertheless, the above quote is dead-on, because, the thing is - business
in one breath tells us they don't need to be regulated (which is to say:
that they can morally self-regulate), then in the next breath tells us that
corporations are amoral entities which have no obligations to anyone except
their officers and shareholders, then in the next breath they tell us they
don't need to be regulated (that they can morally self-regulate) ...

[toc] | [prev] | [next] | [standalone]

#13091

On Nov 11, 4:14 pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
>
> Ok, so we *are* talking about the same thing, right?  We agree on that?
>
> My point is this:  If I am reading it correctly, the output of running the
> program is two pieces of C code - 1 that defines the struct and the other
> that contains the data itself (as an initializer).  So, the point is that
> the data is fixed at compile time.
>
> Which coudl certainly be useful, in some contexts, but is certainly not what
> I think an average person would expect from a "CSV loader".
>
Yes, if you treat the source as a whole program, then it's a CSV to C
data structure utility. It's intended for when you've got a lot of
data in CSV files that you want to incorporate at compile time into
your C programs, without rekeying.

However the code to load a CSV file has been abstracted out and placed
in the file csv.c. So you can take this file and only this file, and
you have a general purpose CSV loader, very similar to R's read.csv()
function.
--
The CSV code and much more
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#13094

In article <964a6f26-3125-4fc2-ad1b-e53dc4b4e9fe@3g2000vbp.googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
...
>However the code to load a CSV file has been abstracted out and placed
>in the file csv.c. So you can take this file and only this file, and
>you have a general purpose CSV loader, very similar to R's read.csv()
>function.

Got it.  Yes, csv.c looks like what I expected.  It looks like it may be
worth looking into...

-- 
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web