Re: character matching

["Nick Roberts" <nick.roberts@acm.org>]

On Fri, 13 Aug 2004 14:53:07 +0930, John J <g_001@hotmail.com> wrote:

> To develop a program that counts words and sentences I'm trying to
> write some code that will recognise a word due to it being a series
> of alphanumeric characters terminated by one or more of a space,
> comma, fullstop, colon, exclamation mark or question mark. I'm going
> to use a case to match the condition then perform an advance on a
> wordcounter.

Possibly a slightly easier definition of a word would be any
contiguous sequence of characters each of which is a letter, digit,
or hyphen (or apostrophe)?

Is this a teaching exercise (e.g. at university)?

In any event, your problem is not really Ada-related, but one of
'algorithm synthesis'. Frankly I've always had trouble with algorithm
synthesis myself, so you have a lot sympathy from me.

However, I'm afraid there is only one possible way to create a new
algorithm that works: invent an algorithm in your head (or on paper,
in any notation that suits you); 'dry run' it, in your head or on
paper, using what you think are representative test data; code it up
into Ada; run it on some test data!

Sometimes it helps to write out some test data on paper, and then
just think about how you would intuitively set about counting the
words by hand. This can give you some clues as to how a program
should do it.

A couple of hints: try to keep your algorithm/program as simple as
possible. If it starts getting complex, that may be a sign that you
need to make a big change to your approach; don't forget the 'corner
cases', such as the beginning and end of a line and the file.

A technique I use a lot is to initially write the program so that it
outputs lots of messages at each point detailing what the values of
relevant variables are and so on. You can suffer from 'spewage' (one
trick is to capture output into a file and then view the file), but
I find this idea can be invaluable in showing how a program is
working (or failing).

In the end, there's only one way to learn how to do this stuff, and
that's the hard way, by trial and error.

Assuming it's a formal execise, you'll impress your professor by
including some (brief) documentation about: what approaches you
tried and rejected; how (you think) the approach you decided to use
works; any unusual details about how to (compile and) use your
program; (very briefly) any limitations you know it has,
improvements you think could be made, other comments.

-- 
HTH, Nick Roberts