i am doing my homework. I have to write a program using a balanced tree.
It is required to balance the tree.
So i wrote a function to do so.
On calling the function i get an stack overflow.

Any help ?
Thanks a lot.

My code:

program binaerbaum;
uses crt;
type name= string[12];
     pointer= ^baum;
     baum= record
       vorname: name;
       nachname: name;
       rechts: pointer;
       links: pointer;
     end;

var zeiger: pointer;
    antwort: char;
    vorname: name;
    nachname: name;
    zaehler, d: integer;
    pfad: string;

{--------------------------------------------------------------------------}

procedure einfuegen(var baumpointer:pointer; vorneu, nachneu: name);
begin
  if baumpointer= nil then
  begin
    new(baumpointer);
    baumpointer^.nachname:= nachneu;
    baumpointer^.vorname:= vorneu;
    baumpointer^.links:= nil;
    baumpointer^.rechts:= nil;
  end
  else
    if nachneu<baumpointer^.nachname then
      einfuegen(baumpointer^.links, nachneu, vorneu)
    else
      einfuegen(baumpointer^.rechts, nachneu, vorneu);
end;
{--------------------------------------------------------------------------}

procedure eingabe (var vn, nn: name);
begin
  clrscr;
  write('Vorname: ');
  readln(vn);
  write('Nachname: ', vorname,', ');
  readln(nn);
end;
{--------------------------------------------------------------------------}

procedure ausgabe(bpointer:pointer; var zaehler: integer; pfad: string);
begin
  if bpointer <> nil then
    begin
      if bpointer^.links<> nil then
        ausgabe(bpointer^.links, zaehler, pfad + 'L');

      zaehler:= zaehler + 1;
      write( zaehler:3,'  ', bpointer^.nachname,', ', bpointer^.vorname);
      gotoXY(50, whereY); writeln(pfad+'*');

      if bpointer^.rechts<> nil then
        ausgabe(bpointer^.rechts, zaehler, pfad + 'R');

     end;
end;
{--------------------------------------------------------------------------}

procedure liste;
var antw: char;
begin
  repeat
  eingabe (vorname, nachname);
  einfuegen(zeiger, nachname, vorname);
  writeln('weiteren namen');
  readln(antw);
  until antw= 'n';
  readln;
end;
{--------------------------------------------------------------------------}
procedure loeschen(var bp: pointer; vn, nn: name);
var rettel: pointer;
    retter: pointer;
begin
  if (nn < bp^.nachname) and (bp<> nil) then
    loeschen(bp^.links, nn, vn)
  else
    if (nn > bp^.nachname) and (bp<> nil) then
      loeschen(bp^.rechts, nn, vn)
    else
      if (nn= bp^.nachname) and (vn= bp^.vorname) then
        begin
          retter:= bp^.rechts;
          rettel:= bp^.links;
          dispose(bp);
          bp:= retter;
          while retter^.links <> nil do
           retter:= retter^.links;
           retter^.links:= rettel;
        end
        else
          writeln('name nicht vorhanden');
end;
{--------------------------------------------------------------------------}

function count(baum: pointer): integer;
begin
  if baum = nil then
    count:= 0
  else
    count:= count(baum^.rechts) + count(baum^.links);
end;
{--------------------------------------------------------------------------}

procedure optimieren(var baum: pointer );
var p: pointer;
begin
  while count(baum^.links)> count(baum^.rechts) do
  begin
    p := baum^.links;
    baum^.links:= p^.rechts;
    p^.rechts:= baum;
    baum:= p;
  end;
  while count(baum^.links) < count(baum^.rechts) do
  begin
    p:= baum^.rechts;
    baum^.rechts:= p^.links;
    p^.links:= baum;
    baum:= p;
  end;
  optimieren(baum^.links);
end;
{--------------------------------------------------------------------------}

Hallo Antje!

You do know what a stack-overflow is/means?

You may enlarge the stack by using the {$M } directive at the beginning
of the program. Another thing is: optimieren (what most likely causes
the overflow) is programmed recursively, thus needing much stack space
if you have enough data. On every call to optimieren the lokally
declared pointer and other things (returnadress = Rcksprungadresse so
that the program knows where it has to continue after the procedure has
finished etc.) are put on the stack. If possible try to change the
algorithm here to some which doesn't use recursion. Maybe you can use
some loops which go over the data. This will save much memory on the
stack, no matter how large your tree structure becomes.

optimieren does not check for a termination condition (like NIL for both
links and rechts). So regardless of what it does, it *always* calls
itself.

Vinzent.

just a short look at your code ...

{-----------------------------------------------------------------------
---}

Pointer is a built-in type and should (almost?) NEVER be redifined! A
pointer is an untyped type that can point to anything. You are
redefining pointer to a typed pointer to baum. Please choose a better
name for that, for example 'PBaum' or 'baumpointer'.

This has nothing to do with your problem but I hope you will change that
anyway.

Wolf

Greetins

Markus

Vinzent.

"Wolf Behrenhoff" <NoSpamPleaseButThisIsVa...@gmx.net> schreef in
bericht news:3E1D9EE6.D38DF0E3@gmx.net...

By putting in a commonly called unit

type real=single;
or
real=double;

all the 6 byte reals in my programs were replaced with 4 or 8 byte ones
that could be handled by the coprocessor.
This coprocessor real handling turned out to be faster by a factor 20 or
so.

But nevertheless pointer=^baum should not be used in this case.

As a rule of thumb never redefine a bulit-in type unless you exactly
know what you are doing (and why).

type
  { Real type [re]defininition }
{$ifopt N+}
  Real = Double;
{$else}
{$ifopt E+}
  Real = Double;
{$endif E+}
{$endif N+}

A Compile|Build is needed of all units if either the $N or $E compiler
option is changed.
--
Jay

"Jason Birgon" <gvision.nos...@ntlworld.com> schreef in bericht
news:4zrT9.2609$tx.143944@newsfep1-gui.server.ntli.net...

The reason is that this way the running code will automatically look for
the presence of a coprocessor.
If found, it will use corpocessor instructions,
else it will use emulation.
The emulated Double floating point handling turned out to be faster than
the original 6 byte real handling. Therefore you should always check
both!!!!!

If you N unchecked, you will get an error upon first use of any of the
real types other than 6 byte real itself, regardless of the status of
the E option.

Perhaps this should be mentioned in the FAQ.  Timo?

I don't waht to interrupt your reasonalbe discussion here, but I just
wanted to remark that you're getting slightly OT here. Why not just
start a new thread like Type redefinition & Coprocessor... or similar?

Greetings

I had a program that needed to do floating-point both in the main
routine and in a hardware interrupt service routine.

For this to be successful using only IEEE types, one must not only save
the state of the FPU, which can be done; but one must also deal with the
non re-entrant helper routines for FPU operations, which I did not
manage.

Instead, I used exclusively the IEEE types in the main program and the
pure-software 6-byte types in the ISR (or vice versa) - this was
successful.  It was a BP7 program; DPMI, I think, not Windows; it would
actually run in a Windows 3.x DOS box.

See <URL:http://www.merlyn.demon.co.uk/pas-real.htm#FloatISR>.

--
Jay