Mine is more of a *programming *problem, rather than one native to Pascal, but here goes:

I have a text file with many Double values. Looking more or less like below, but with hundreds of entries...

1.5
3.25
7.54
10.33
2.22

The values listed are only for illustration. What I need to do is read the values in the first file and sum them up such that the output file starts with the first value, the second entry in the output file is the sum of the first AND second values, the third entry in the output file is the sum of the first, second and third values of the input file:

1.5
4.75 (1.5 + 3.25)
12.29 (1.5 + 3.25 + 7.54)
22.62 (1.5 + 3.25 + 7.54 + 10.33)
24.84 (1.5 + 3.25 + 7.54 + 10.33 + 2.22)

The process of summing up continues to the end of the file.

I figure this is a program loop problem, rather than a Pascal problem, but it's beyond me. I would greatly appreciate assistance.

Thank you,
Ko Hashiguchi

Hi

Good candidate for recursive algorithm i think.

regards

Nataraj

2011/10/14 Ko Hashiguchi :

var
  infile: text;
  outfile: text;
  sum: double;
  value: double;
begin
  assign(infile, ...);
  assign(outfile, ...);
  reset(infile);
  rewrite(outfile);
  sum := 0;
  while not eof(infile) do begin
    readln(infile, value);
    sum := sum + value'
    writeln(outfile, sum);
  end;
end.

Depending on how many numbers you read and the difference between magnitude of sum and value, you may have to do some extra work for the numeric stability. but that is for later concern.

Vincent

Vincent Snijders wrote

Depending on how many numbers you read and the difference between ....

The original poster's questions sounds very much like a homework assignment, which you have no done for him. Naughty!

Regards,
- Graeme -

Hello Graeme,

I'm way too old for homework, just to let you know. I'm five months younger than Steve Jobs and three months older than Bill Gates. Call me an old fart who just needed the help.

Regards,
Ko Hashiguchi

On Fri, Oct 14, 2011 at 12:04 AM, Graeme Geldenhuys <

2011/10/14 Graeme Geldenhuys :

The thought crossed my mind and therefore I googled Ko Hashiguchi pascal and found this:
http://free-pascal-general.1045716.n5.nabble.com/Odd-delimited-text-file-length-limitations-td4550913.html

I took the risk...

Vincent

Ko Hashiguchi wrote

Call me an old fart who just needed the help.

Please accept my apology then.

Regards,
- Graeme -

Graeme,

No apology necessary. I am 56 years old, I have to (because of lack of money) write my own utilities, and I am too old to take up programming as a profession. But I am NOT too old to program! I just need help every now and then.

I am the same Ko Hashiguchi who asked for help with delimited ASCII files on this forum some months ago.

You gentlemen have been very helpful, and I appreciate it!

Ko Hashiguchi

On Fri, Oct 14, 2011 at 12:19 AM, Graeme Geldenhuys <

Hi

Many of us from south Asian countries in here ought to be in their middles ages! I am 45. Since many of us might have started out in our late twenties in Delphi, natural progression to be here in fpc in our autumn days of life.

regards

Nataraj

Nataraj S Narayan wrote

Good candidate for recursive algorithm i think.

At first glance maybe, but it is actually a horrible candidate. That is due to the fact that the number of values is unknown and recursion has a built-in limit based on the stack size. So if your logic is recursive it will work one day on one file of numbers and not the next on a longer file.

Much better to simply maintain a summed value, read a value, add it to the sum, write the current sum, and continue until done.

file.

Exactly! I often see advices to use recursive function/procedure calls because it looks so elegant but actually it can crash quite easily (depending on stack size and local variables). Most people don't think about this and believe that if it works on a test it will always work. But that's delusory.

IMO recursive function calls should only be used if there is a known limitation of recursion levels and if that maximum will safely work under all circumstances.

Much better to simply maintain a summed value, read a value, add it to the sum, write the current sum, and continue until done.

Yes, in this case it is much better and also much easier.

>> Good candidate for recursive algorithm i think. > At first glance maybe, but it is actually a horrible candidate.

IMHO, this is far from being a problem that needs to be solved with recursion. Indeed, you don't need recursion at all: you have a file, and just need to sum its values till EOF; only you need also to show the partial result at each step.
Moreover, since the file has a well known beginning and end, a cycle is more than enough.
Recursion is for other things, such as expression parsing etc. where you don't (and neither possibly can't) actually know how deep may the nesting.

Just my 2c

Cheers, A.

Recursion is for other things, such as expression parsing etc. where

you don't (and neither possibly can't) actually know how deep may the nesting.

Well, I would advice only to use it if you *know* the maximum nesting depth. Otherwise it can crash easily.

A good example of stack overflow crashes is a (Pascal) software happened in a huge railway signal box in germany (near Hamburg) in 1995 (http://catless.ncl.ac.uk/Risks/17.02.html#subj3). The software worked ok on testing but on go live it crashed with stack overflow because suddenly the data amount (and therefore the nesting depth) was significantly larger than in the tests. It is much harder to judge the stack memory use than the heap use and often the stack is more limited than the heap so you run into such issues easier.

Well, I would advice only to use it if you *know* the maximum nesting depth. Otherwise it can crash easily.

I was not focusing on the problems that could arise using recursion, my point simply was that in this case, use of recursion was a no-need.

Of course when using recursion you _MUST_ keep an eye on the stack, but then, a good parameter design for the recursive function could help a lot. Pointers are a must; while structures/records should be avoided in primis, as they are stack-hungry ;-)

I don't know anything in detail about this crash (shit happens, I might say) all I can say out of my knowledge is that maybe in that specific situation some possible scenarios have been underestimated. I would ask myself why should you need recursion in that case too... but the approaches are different, and subjective, too. I would have gone through a tree-node solution instead; but that's me, I know.
As I say, recursion is primarily for cases where/when you don't/can't have any finite states to start with. A railway net, by definition, although the possibilities of the shifts may result in a big number of trees, _is_ finite. IMHO. Hence, the use of recursion, again, is just a nice thing for your software to have, not necessarily the most adequate implementation of the human algorithm otherwise behind it.

I found, one day, that the easiest thing to do when you have no idea about how to have a computer replacing a human, is just to have as close as possible a representation of the human work-flow; then have a computer just being able to perform and cross-check it just faster. BTW, we all know that humans don't have a stack big enough to deal with recursion at reasonable speeds... ;-)

Cheers, A.