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

Groups > linux.debian.user > #266251 > unrolled thread

counting commas

Back to article view | Back to linux.debian.user

Contents

  counting commas fxkl47BF@protonmail.com - 2024-01-19 08:20 +0100
    Re: counting commas John Crawley <john@bunsenlabs.org> - 2024-01-19 08:30 +0100
    Re: counting commas <tomas@tuxteam.de> - 2024-01-19 09:10 +0100
    Re: counting commas "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 09:30 +0100
      Re: counting commas Michael Grant <mgrant@grant.org> - 2024-01-19 12:20 +0100
      Re: counting commas Greg Wooledge <greg@wooledge.org> - 2024-01-19 13:40 +0100
        Re: counting commas "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-19 16:30 +0100
          Re: counting commas fxkl47BF@protonmail.com - 2024-01-19 16:40 +0100
            Re: counting commas Greg Wooledge <greg@wooledge.org> - 2024-01-19 17:50 +0100
              Re: counting commas fxkl47BF@protonmail.com - 2024-01-19 18:30 +0100
              Re: counting commas debian-user@howorth.org.uk - 2024-01-19 18:30 +0100
                Re: counting commas John Hasler <john@sugarbit.com> - 2024-01-19 21:10 +0100
                  Re: counting commas Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-20 04:00 +0100
                    Re: counting commas Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-20 05:00 +0100
                Re: counting commas David Wright <deblis@lionunicorn.co.uk> - 2024-01-20 00:10 +0100
                  Re: counting commas Cindy Sue Causey <butterflybytes@gmail.com> - 2024-01-20 01:10 +0100
                  Re: counting commas Peter Hillier-Brook <phb@hbsys.plus.com> - 2024-01-20 01:10 +0100
                  Re: counting commas Curt <curty@free.fr> - 2024-01-20 18:20 +0100
                    Re: counting commas Greg Wooledge <greg@wooledge.org> - 2024-01-20 18:30 +0100
                      Re: counting commas fxkl47BF@protonmail.com - 2024-01-20 18:40 +0100
                      Re: counting commas Curt <curty@free.fr> - 2024-01-20 18:40 +0100
                    Re: counting commas David Wright <deblis@lionunicorn.co.uk> - 2024-01-20 21:10 +0100
          Re: counting commas Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-20 03:50 +0100
            Re: counting commas gene heskett <gheskett@shentel.net> - 2024-01-20 06:50 +0100
            Re: counting commas gene heskett <gheskett@shentel.net> - 2024-01-20 07:00 +0100
            Re: counting commas "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-20 21:40 +0100
              Re: counting commas gene heskett <gheskett@shentel.net> - 2024-01-20 22:10 +0100
              Re: counting commas John Hasler <john@sugarbit.com> - 2024-01-21 01:10 +0100
                Re: counting commas gene heskett <gheskett@shentel.net> - 2024-01-21 01:20 +0100
                  Re: counting commas John Hasler <john@sugarbit.com> - 2024-01-21 01:30 +0100
                    Re: counting commas gene heskett <gheskett@shentel.net> - 2024-01-21 02:10 +0100

Page 1 of 2  [1] 2  Next page →

#266251 — counting commas

why doesn't grep count 2 commas


echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
1

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
Kích thước máy xay cỏ

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
  giá máy thế nào

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
  phụ tùng máy mua ở đâu

[toc] | [next] | [standalone]

#266253

On 19/01/2024 16:10, fxkl47BF@protonmail.com wrote:
> why doesn't grep count 2 commas
> 
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
> 1
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
> Kích thước máy xay cỏ
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
>    giá máy thế nào
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
>    phụ tùng máy mua ở đâu
> 
Grep's -c option counts the *lines* which match. You only inputted one line, and grep said one line was found which matched *,*
-- 
John

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

#266255

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 19, 2024 at 07:10:51AM +0000, fxkl47BF@protonmail.com wrote:
> why doesn't grep count 2 commas
> 
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
> 1
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
> Kích thước máy xay cỏ
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
>   giá máy thế nào
> 
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
>   phụ tùng máy mua ở đâu

It is in the man page:

   -c, --count
         Suppress  normal output; instead print a count of matching lines
         for each input file.  With the -v,  --invert-match  option  (see
         below), count non-matching lines.

It counts matching lines. You gave it one line.

If you want to go character-wise, tr might fit the bill (e.g. do a tr -c
to remove everything except comma, then measure the resulting string's
length).

Of course, if you have something else than shell+utils there might be
more efficient ways.

Cheers
-- 
t

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

#266259

Hi,

fxkl47BF@protonmail.com wrote:
> why doesn't grep count 2 commas
> echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' |
> grep -c ,
> 1

Happens with much simpler text too:
  $ echo ',,,' | grep -c ','
  1

The man page explains it:

 -c, --count
    Suppress  normal output; instead print a count of matching lines
    for each input file.  With the -v,  --invert-match  option  (see
    below), count non-matching lines.  (-c is specified by POSIX.)

Note that it counts lines, not characters.

Counting characters by grep seems somewhat tricky:
  https://www.unix.com/shell-programming-and-scripting/128033-grep-command-count-characters.html

An answer to this question
  https://stackoverflow.com/questions/16679369/count-occurrences-of-a-char-in-a-string-using-bash
proposes
    echo "referee" | tr -cd 'e' | wc -c

  $ echo ',,,' | tr -cd ',' | wc -c
  3
  $ echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | tr -cd ',' | wc -c
  2

(I hope i did not quote something that's against the code of conduct. :))


Have a nice day :)

Thomas

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

#266268

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 19, 2024 at 09:25:14AM +0100, Thomas Schmitt wrote:
> fxkl47BF@protonmail.com wrote:
> > why doesn't grep count 2 commas
> > echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' |
> > grep -c ,
> > 1

Here's my way:

$ echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' |  fold -w1 | grep -c ,
2

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

#266273

On Fri, Jan 19, 2024 at 09:25:14AM +0100, Thomas Schmitt wrote:
> An answer to this question
>   https://stackoverflow.com/questions/16679369/count-occurrences-of-a-char-in-a-string-using-bash
> proposes
>     echo "referee" | tr -cd 'e' | wc -c
> 
>   $ echo ',,,' | tr -cd ',' | wc -c
>   3

That's one way, and it's sh-compatible.

If you actually want to do it in *bash* as the URL suggests, you can
take advantages of bash's extra features, to avoid forking two new
programs plus a subshell.

unicorn:~$ string="apple,banana,cherry,date"
unicorn:~$ commas=${string//[!,]/}
unicorn:~$ echo "${#commas}"
3

In this case, I'm using the ${varname//old/new} expansion to remove
everything that isn't a comma.

But at this point, we have to wonder what the *actual* goal is.  They
wanted to count the number of commas... why, exactly?  Are they going
to split the input string into a list of substrings?  If so, just do
that in the first place.

unicorn:~$ IFS=, read -ra list <<< "$string,"
unicorn:~$ declare -p list
declare -a list=([0]="apple" [1]="banana" [2]="cherry" [3]="date")

To understand why I added an extra comma at the end of the input
string, see <https://mywiki.wooledge.org/BashPitfalls#pf47>.

This approach needs adjustment if the input string may contain
newlines.  So, please state the actual goal up front, in full, and
include a worst-case-scenario example.

Finally, if the input is actually a CSV (Comma-Separated Values)
file, which may contain fields with commas *inside* them, then none
of these approaches work.  You need an actual CSV parser to handle
these files properly.

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

#266278

Hi,

Greg Wooledge wrote:
> unicorn:~$ string="apple,banana,cherry,date"
> unicorn:~$ commas=${string//[!,]/}
> unicorn:~$ echo "${#commas}"
> 3

Always astonishing what a good bashism can do.


> But at this point, we have to wonder what the *actual* goal is.

Up to now we only know about the astonishment of fxkl47BF@protonmail.com
that grep -c does not count characters.

For a more complicated use case i would write a little C program where
i'd be in control of every single bit of throughput.
(Ok, C causes scars on the programmer's self esteem. But what does not
kill me makes me just stronger. I'm a vim user.)


Have a nice day :)

Thomas

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

#266279

On Fri, 19 Jan 2024, Thomas Schmitt wrote:

> Hi,
>
> Greg Wooledge wrote:
>> unicorn:~$ string="apple,banana,cherry,date"
>> unicorn:~$ commas=${string//[!,]/}
>> unicorn:~$ echo "${#commas}"
>> 3
>
> Always astonishing what a good bashism can do.
>
>
>> But at this point, we have to wonder what the *actual* goal is.

to exclude phrases with commas for seperate examination

>
> Up to now we only know about the astonishment of fxkl47BF@protonmail.com
> that grep -c does not count characters.

i DID know that
that brain cell was offline at the moment
it needed a reminder to refresh the connection

>
> For a more complicated use case i would write a little C program where
> i'd be in control of every single bit of throughput.
> (Ok, C causes scars on the programmer's self esteem. But what does not
> kill me makes me just stronger. I'm a vim user.)

vi is the only way to go
i programmed c on hp/ux for 20+ years
had a room full of k200's
that was a lifetime ago

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

#266281

On Fri, Jan 19, 2024 at 03:30:17PM +0000, fxkl47BF@protonmail.com wrote:
> >> But at this point, we have to wonder what the *actual* goal is.
> 
> to exclude phrases with commas for seperate examination

Parsing natural language text is going to be tricky.  I can only talk
about English, and not about whatever language your text is actually
written in.

Let's look at a few example English sentences:

    Good morning, John.

    I went to the store with Mary, Paul, Susan and Ralph.

    I won, and you lost.

    The bear, who was hungry, looked for food.

    Oh, that's interesting.

These are five different examples of comma usage in English.  Do you
happen to know in advance that your text will *only* contain samples
that use the fourth style above?  Let's assume this.  Let's then form
a template:

    STUFF, ASIDE, MORE STUFF, ASIDE, STILL MORE STUFF.

I.e. given a sentence which conforms to expectation, we should see
an even number of commas (is *THIS* why you were counting them??) and
we should extract the ASIDEs from in between the first and second, then
the third and fourth, and so on.

So... uh, I guess my next question is: are you *pre-filtering* the
sentences and keeping only the ones which have an even number of
commas?  Or have you already *done* that, and now you're asking how
to extract the ASIDEs?

I really don't think I'd try this with shell scripts.  The tools just
aren't designed for this.  You really want tools that are custom built
for natural language processing, or a language that lets you run
through a large string character by character in a fast, efficient
way (C comes to mind) if you're trying to build your tools from the
ground up.

The "obvious" algorithm for extracting the ASIDEs would be use a
simple finite state machine, and march through the sentence
character by character.  When you encounter a comma, change state.
Otherwise, if you're in the "ASIDE" state, copy the character to your
output buffer.  When you leave the "ASIDE" state, terminate the current
output buffer and move to the next one.  That's how I'd do it in C.
Add whitespace trimming and so on.

Also note that breaking a piece of natural language text *into*
sentences in the first place is extraordinarily difficult.  If you
haven't already got a way to do that, you're probably screwed.
Seriously, asking the debian-user list how to count the number of
commas in a text file is *not* a good sign if you're dealing with a
masters-degree-level problem in natural language analysis.

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

#266284

On Fri, 19 Jan 2024, Greg Wooledge wrote:

> On Fri, Jan 19, 2024 at 03:30:17PM +0000, fxkl47BF@protonmail.com wrote:
>>>> But at this point, we have to wonder what the *actual* goal is.
>>
>> to exclude phrases with commas for seperate examination
>
> Parsing natural language text is going to be tricky.  I can only talk
> about English, and not about whatever language your text is actually
> written in.
>
> Let's look at a few example English sentences:
>
>    Good morning, John.
>
>    I went to the store with Mary, Paul, Susan and Ralph.
>
>    I won, and you lost.
>
>    The bear, who was hungry, looked for food.
>
>    Oh, that's interesting.
>
> These are five different examples of comma usage in English.  Do you
> happen to know in advance that your text will *only* contain samples
> that use the fourth style above?  Let's assume this.  Let's then form
> a template:
>
>    STUFF, ASIDE, MORE STUFF, ASIDE, STILL MORE STUFF.
>
> I.e. given a sentence which conforms to expectation, we should see
> an even number of commas (is *THIS* why you were counting them??) and
> we should extract the ASIDEs from in between the first and second, then
> the third and fourth, and so on.
>
> So... uh, I guess my next question is: are you *pre-filtering* the
> sentences and keeping only the ones which have an even number of
> commas?  Or have you already *done* that, and now you're asking how
> to extract the ASIDEs?
>
> I really don't think I'd try this with shell scripts.  The tools just
> aren't designed for this.  You really want tools that are custom built
> for natural language processing, or a language that lets you run
> through a large string character by character in a fast, efficient
> way (C comes to mind) if you're trying to build your tools from the
> ground up.
>
> The "obvious" algorithm for extracting the ASIDEs would be use a
> simple finite state machine, and march through the sentence
> character by character.  When you encounter a comma, change state.
> Otherwise, if you're in the "ASIDE" state, copy the character to your
> output buffer.  When you leave the "ASIDE" state, terminate the current
> output buffer and move to the next one.  That's how I'd do it in C.
> Add whitespace trimming and so on.
>
> Also note that breaking a piece of natural language text *into*
> sentences in the first place is extraordinarily difficult.  If you
> haven't already got a way to do that, you're probably screwed.
> Seriously, asking the debian-user list how to count the number of
> commas in a text file is *not* a good sign if you're dealing with a
> masters-degree-level problem in natural language analysis.
>


certain characters give the interpreter a hard time
i'll just process what is easy for the interpreter
then work on the rest

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

#266285

Greg Wooledge <greg@wooledge.org> wrote:

> I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

> I really don't think I'd try this with shell scripts.  The tools just
> aren't designed for this.  You really want tools that are custom built
> for natural language processing, or a language that lets you run
> through a large string character by character in a fast, efficient
> way (C comes to mind) if you're trying to build your tools from the
> ground up.

At the risk of being seen as old-fashioned, but as a user of both
languages, I think Perl is a much better choice than C for string
processing. But whatever the OP knows is likely the best choice in the
short term.

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

#266290

 debian-user@howorth.org.uk writes:
> There shouldn't be a comma in that sentence, in English. There is in
> the closely related expression "I won, you lost."

The program has to be able to deal with bad writing.

> At the risk of being seen as old-fashioned, but as a user of both
> languages, I think Perl is a much better choice than C for string
> processing.

Use SPITBOL.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

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

#266303

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 19, 2024, 6:52 PM John Hasler <john@sugarbit.com> wrote:

>  debian-user@howorth.org.uk writes:
> > The
> > At the risk of being seen as old-fashioned, but as a user of both
> > languages, I think Perl is a much better choice than C for string
> > processing.
>
> Use SPITBOL.
>

Another SPITBOL user lives??!? :-)
It should all be open-source by now....
Is it?

John Hasler
> john@sugarbit.com
> Elmwood, WI USA
>
>

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

#266304

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 19, 2024, 9:24 PM John Hasler <john@sugarbit.com> wrote:

> > Another SPITBOL user lives??!? :-)
>
> It's been decades since I used it.
>
> > It should all be open-source by now....
> > Is it?
>
> http://www.snobol4.com/
>
> A search finds this:
>

Well thank you so much John. They are giving away for free Spitbol 360/70,
and for the past year I just so happen to have an IBM mainframe laying
around again :-)
One of my CS profs in college was Glenn Manacher who had been a maintainer
of Snobol at Bell labs in New Jersey.


https://github.com/spitbol/x64
>
> I haven't looked at it.  I'm surprised it isn't in Debian.
> --
> John Hasler
> john@sugarbit.com
> Elmwood, WI USA
>

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

#266296

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
> Greg Wooledge <greg@wooledge.org> wrote:
> 
> > I won, and you lost
> 
> There shouldn't be a comma in that sentence, in English. There is in
> the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

The first is a more neutral statement of fact. The
second carries an implication of triumphalism or
mockery: many speakers would expect a swoop upwards
in intonation on "won", a pause, and a steep drop
between "you" and "lost"; kinda like:

  -⭜   ·¯⭝

if that works in your font.

What you lose (sorry) in "I won, you lost." is the
anacrusis, the ·, which many would pronounce "ən",
as in ənyeeoo. Without it, I'd be inclined to write
"I won. You lost." (similar intonation).

Disclaimer: my choice of intonation was to illustrate
one difference. There are many more ways of saying
all of those sentences.

Cheers,
David.

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

#266298

On 1/19/24, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
>> Greg Wooledge <greg@wooledge.org> wrote:
>>
>> > I won, and you lost
>>
>> There shouldn't be a comma in that sentence, in English. There is in
>> the closely related expression "I won, you lost."
>
> That's rather proscriptive. "I won and you lost."


I won and you lost, but we can still be friends.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with memories of a North Georgia English teacher saying to me,
"You didn't go to school around here, did you." He'd been standing up
against my desk as I was taking a third or fourth test at the time. He
was apparently trying to figure out if I was cheating on his tests.
Nope. *

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

#266299

On 19/01/2024 23:02, David Wright wrote:
> On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
>> Greg Wooledge <greg@wooledge.org> wrote:
>>
>>> I won, and you lost
>>
>> There shouldn't be a comma in that sentence, in English. There is in
>> the closely related expression "I won, you lost."

Anything other than this *accurate* statement would have led to a caning 
in my grammar school in the late '40s. :-)

Peter HB

> That's rather proscriptive. "I won and you lost." and
> "I won, and you lost." are two different sentences.
> 
> The first is a more neutral statement of fact. The
> second carries an implication of triumphalism or
> mockery: many speakers would expect a swoop upwards
> in intonation on "won", a pause, and a steep drop
> between "you" and "lost"; kinda like:
> 
>    -⭜   ·¯⭝
> 
> if that works in your font.
> 
> What you lose (sorry) in "I won, you lost." is the
> anacrusis, the ·, which many would pronounce "ən",
> as in ənyeeoo. Without it, I'd be inclined to write
> "I won. You lost." (similar intonation).
> 
> Disclaimer: my choice of intonation was to illustrate
> one difference. There are many more ways of saying
> all of those sentences.
> 
> Cheers,
> David.
> 

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

#266321

On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
>> Greg Wooledge <greg@wooledge.org> wrote:
>> 
>> > I won, and you lost
>> 
>> There shouldn't be a comma in that sentence, in English. There is in
>> the closely related expression "I won, you lost."
>
> That's rather proscriptive. "I won and you lost." and
> "I won, and you lost." are two different sentences.
>

AFAIK, "you lost" is an independent clause and should be separated from
the independent clause that precedes it with a comma before the
coordinating conjunction.

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

#266322

On Sat, Jan 20, 2024 at 05:09:58PM -0000, Curt wrote:
> On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
> >> Greg Wooledge <greg@wooledge.org> wrote:
> >> 
> >> > I won, and you lost
> >> 
> >> There shouldn't be a comma in that sentence, in English. There is in
> >> the closely related expression "I won, you lost."
> >
> > That's rather proscriptive. "I won and you lost." and
> > "I won, and you lost." are two different sentences.
> >
> 
> AFAIK, "you lost" is an independent clause and should be separated from
> the independent clause that precedes it with a comma before the
> coordinating conjunction.

Regardless of which grammar rules are right, wrong, or optional, the point
of this is that parsing natural language text is *stupidly difficult*.
A person who has to ask why "grep -c" doesn't count the number of commas
in a single line of text probably isn't able to take on this quest.

Any serious inquiries about natural language parsing should be directed
to an appropriate artificial intelligence mailing list instead of this one.

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

#266323

On Sat, 20 Jan 2024, Greg Wooledge wrote:

> On Sat, Jan 20, 2024 at 05:09:58PM -0000, Curt wrote:
>> On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:
>>> On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:
>>>> Greg Wooledge <greg@wooledge.org> wrote:
>>>>
>>>>> I won, and you lost
>>>>
>>>> There shouldn't be a comma in that sentence, in English. There is in
>>>> the closely related expression "I won, you lost."
>>>
>>> That's rather proscriptive. "I won and you lost." and
>>> "I won, and you lost." are two different sentences.
>>>
>>
>> AFAIK, "you lost" is an independent clause and should be separated from
>> the independent clause that precedes it with a comma before the
>> coordinating conjunction.
>
> Regardless of which grammar rules are right, wrong, or optional, the point
> of this is that parsing natural language text is *stupidly difficult*.
> A person who has to ask why "grep -c" doesn't count the number of commas
> in a single line of text probably isn't able to take on this quest.
>
> Any serious inquiries about natural language parsing should be directed
> to an appropriate artificial intelligence mailing list instead of this one.
>

mr wooledge makes a valid point
if an ignorant person such as myself tries to parse his advice i get
unless you're a super brilliant egghead you shouldn't bother to try

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web