Re: free implementation? factorial?

> Certainly some of the other classics, such as tree traversal, aren't
> an easy fit for traditional COBOL.  It's not hard to implement binary
> trees in COBOL, with or without pointers, but it's atypical.

What is usually done using trees in C is done using ISAM files in
Cobol, which may in fact be indexed by btrees, or by arrays and SEARCH
ALL (which may be a binary chop), or with relative files using the
record numbers as pointers.

The advantage of doing things in files is that these can be shared and
can be permanent which is important for business. If you want to
introduce Cobol do not teach recursion and btrees but teach the
difference between an invoice and a credit note.

In article <1137181696.726963.129770@z14g2000cwz.googlegroups.com>, "Richard" <riplin@Azoni
c.co.nz> writes:
> [I wrote:] 
>
> What is usually done using trees in C is done using ISAM files in
> Cobol, which may in fact be indexed by btrees, or by arrays and SEARCH
> ALL (which may be a binary chop), or with relative files using the
> record numbers as pointers.

Agreed - that's why I wrote that tree data structures are "atypical"
for COBOL.

Turing-completeness and the like aside, it's clear that programming
languages favor certain approaches over others, simply in the
syntatic sugar and semantic assistance they provide.  The Algol
family of languages - such as C, Pascal, and their derivatives -
accomodate tree structures with little programmer inconvenience.
LISP and its derivatives encourage them; they're the basic data
structure provided by the language.

On the other hand, there are languages like APL, where the multidimen-
sional array is the basic data structure; the implementation may use
trees under the covers, but from the programmer's point of view they're
not a natural fit.  And there's COBOL, where the basic data structures
are hierarchical records, arrays, and files.

> The advantage of doing things in files is that these can be shared and
> can be permanent which is important for business.

Obviously there are various tradeoffs between in-memory and on-disk
storage in most implementations, though unified virtual memory
management and hierarchical storage management are steadily removing
many of the distinguishing characteristics.

> If you want to
> introduce Cobol do not teach recursion and btrees but teach the
> difference between an invoice and a credit note.

Agreed, but as I noted in my response to Louis, introducing recursion
in COBOL is a different subject from introducing COBOL using recursion.

(And I certainly wouldn't try to teach B-trees, or B+trees, in COBOL;
they're not a natural fit and they're outdated.)

--
Michael Wojcik                  michael.wojcik@microfocus.com

If Mokona means for us to eat this, I, a gentle person, will become
!  -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:dqdtg901874@news1.newsguy.com...
[snip]
> (And I certainly wouldn't try to teach B-trees, or B+trees, in COBOL;
> they're not a natural fit and they're outdated.)

If those trees are *out*, what's *in*?

On Sun, 15 Jan 2006 12:45:43 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:
 
>
>If those trees are *out*, what's *in*?

I suppose, external databases.

In article <11sl2u4ans1jo34@corp.supernews.com>, "Rick Smith" <ricksmith@mfi.net> writes:[c
olor=darkred]
>
> "Michael Wojcik" <mwojcik@newsguy.com> wrote in message
> news:dqdtg901874@news1.newsguy.com...
> [snip] 
>
> If those trees are *out*, what's *in*?[/color]

Actually, on reflection, I'll qualify that: B+trees are outdated for
in-memory indices.  They're still popular for external indices, as
far as I can tell, though there are competitors such as extendible
hashing.

For in-memory indices, the current favorite is red-black trees, I'd
say - at least they have been favored more recently than B+trees.  In
the late 1980s, B+trees were considered pretty much state of the art
for balanced trees, as far as I can tell. AVL trees and red-black
trees (RB-trees) were also known (they predate the B-tree family),
but the former require too many rotations in the worst case to be
practical for many applications, and the latter were not as general
as B-trees and had slightly greater storage requirements, as they're
strictly binary (only one key and two links per node, whereas B-trees
have M keys and M+1 links).

With changes in available resources, the tradeoffs of RB-trees are
now generally more favorable than those for B-trees.  They're also
widely available thanks to two major sources: libavl and the C++
standard library (which all but mandates them).

Red-black trees are basically an alternate representation of the
structure of a 2-3-4 tree, which is a kind of B-tree, and I suppose
some people might consider RB-trees just B-trees in a special
representation; but since the implementations are very different,
they're better treated as a different data structure (particularly
for educational purposes, which is what this thread is ostensibly
about).

--
Michael Wojcik                  michael.wojcik@microfocus.com

Web 2.0 is ... like talking to people - without the pesky annoyance of
other people.  -- Martin Wood