"Undocumented Extensions" (was: If you were inventing CoBOL...
From: William M. Klein (wmklein_at_nospam.netcom.com)
Date: 09/10/04
- Next message: LX-i: "Re: If you were inventing CoBOL..."
- Previous message: Frederico Fonseca: "Re: Cobol Editor For Windows"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: James J. Gavan: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 09 Sep 2004 22:32:41 GMT
Robert,
We have been thru this before. Some compiler vendors continue support for
"undocumented extensions" and some don't. Any programmer relying on such, seems
silly to me (but YMMV).
For an example of exactly HOW many undocumented extensions IBM dropped support
for, see:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG20/3.3.14
and
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3MG20/4.1.6
***
Unlike IBM, Micro Focus often (not quite always) adds new directives, cf
OLDNEXT-SENTENCE
and several other OLDxxxx directives
Anyone who assumes that Fujitsu will always support their current (undocumented)
SET ADDRESS OF (not conforming to ISO 2002) syntax, will EVENTUALLY find out if
this was or wasn't a safe assumption.
-- Bill Klein wmklein <at> ix.netcom.com "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message news:2tg1k09dhunkm7r4408ahkr13540j8388i@4ax.com... > On 8 Sep 2004 23:13:09 -0700, riplin@Azonic.co.nz (Richard) wrote: > >>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote > >>Changing from MFs SET ADDRESS (unsupported by Fujitsu) to >>BASED-STORAGE now _that_ is a rewrite. > > SET ADDRESS is unsupported but implemented by Fujitsu. > > I really doubt compiler companies will delete extensions that once > worked. When Micro Focus or IBM releases a 2002 compiler, do you think > we'll have to rewrite SET ADDRESS to BASED-STORAGE? > >>> In databases, 'table' is a misnomer. The structures are actually lists >>> linked by a tree-like index. >> >>In relational databases the data is held in 'tables' . They are >>logically exactly the same as tables there is no 'misnomer'. > > One cannot insert a row between two existing ones in a Cobol table. > >>> You're confusing tables with 'direct' structures accessed via hash. >>> How does one calculate the index number in a table? >> >>How about: divide by 2 for a binary chop search ? Try doing that on a >>list. > > Try doing that on an unsorted table. While you're sorting the table, > I'll build a tree. Never mind, it's already built. I'll do the lookups > in the unbalanced tree while you're sorting. Want to see it again? > I'll do them a second time while you're STILL sorting. > >>> >Double linked lists, trees, and other exotic structures are far more >>> >complex and error prone and may be considerably slower. > > Sorting is inherently complex too. We hide that from the user by > putting the logic in a library called by the SORT verb. The same could > have done for lists. > > In the old days, structures natively supported by the language, such > as tables, had a simplicity advantage over structures we had to manage > ourselves. OO changed the balance. We can now create types and > supporting methods that are nearly as easy to use. > > Someone said 'Two things would sicken the average citizen: the inside > of a slaughterhouse and seeing how government actually works.' We seem > to have found a third in data management algorithms. > >>> Talk about religion. You're asking the simplicity gods to protect us >>> from our own mistakes. >> >>Exactly. The principle is KISS. > > The principle is MISS -- Make It Simple, Stupid .. even if it isn't. > >>If a system can be made to work >>reliably using simple components that are demonstrably error free then >>only a fool would complexify it for no benefit. > > A pointer to the next entry in a list is no more complex than adding 1 > to a subscript. In fact, it's simpler. I don't have to multiply by the > size of an occurrence to find it. > >>> Lookups via a balanced tree run exactly as fast >>> as a binary chop -- both take log2 (n) looks. >> >>But they are _much_ slower to create. They are also slower for each >>'look'. > > Do you have evidence? I posted code that did it both ways and measured > total build and lookup time to be: > > MF table sort, search all 5.1 > tree, lookup (unbalanced) 2.6 > tree, balance, lookup 2.6 > >>> Simplicity advocates, hung by their own petard, usually avoid ODO >>> because it's 'too complicated'. >> >>Well there yer go, everyone except Robert is just too stupid to do it >>right. > > I didn't say everyone; I said simplicity advocates. > >>And is it these same 'simplicity advocates' that you are trying to >>encourage to code up double linked lists and tree traversals ? > > No, I posted that for people wanting to learn how to program. Others > will continue doing it the slow way until someone hands them an > easy-to-use package. > >>> 2. Binary chop REQUIRES the entries be sorted. If they aren't >>> naturally, one must add sort time to the comparison. Balancing a tree >>> is analogous to the sort time, but tree lookups don't REQUIRE that the >>> tree be balanced. They run correctly albiet a little slower with an >>> unbalanced tree >> >>When presented with ordered data they degrade to a linked list with >>only the right branch ever used and thus work much slower then a >>single linked list. > > In that case, the lookup could switch to binary chop. I posted a demo > that sorted by rotating the tree until everything was on the right, > then did lookups with binary chop. > > tree, to table, search all 2.9 > > If inputs had been in sequence, rotation would have stopped after one > pass. Time would have been 1.3. > >>To produce a reasonable balanced tree either they must be given data >>ordered randomly, for example by sorting using a random number as the >>key, or the tree must be rotated when unbalance is out by given >>amount. > > Random inputs do not produce a well-balanced tree. One has to > unbalance it until everything is on the right (or left), in other > words sort the entries. Only then can a balanced tree be built. > >>Rotation code can be very complex, with a need to detect when it is >>actually required. Poorly done it can become unstable in some cases >>when the rotation is done and then undone on the next access. > > 'I tried that once and ran into problems. It follows, therefore, that > nobody else should be allowed to use it.' I once worked for a manager > who set shop standards by that logic. She wouldn't allow Cobol SORT > because she had trouble with it ten years earlier. > >>You were wrong when you claimed simple lists were faster. There may be >>specific cases where loading a tree does produce an insignificant time >>saving over a SORT plus SEARCH ALL, > > See above. Twice the speed is not insignificant. The specific case was > 50,000 random 30-byte keys, which seems typical of everyday use. > >>and it would be _much_ slower if the data were naturally ordered. > > It would be the same, because tree search would detect that and switch > to binary chop. > >>But quite frankly I wouldn't care it was faster or not. I know from >>having done it how complex trees can be and I really don't see the >>point in recoding 'what C did in the 70s'. > > It is a prelude to managing more complex structures in databases. You > have to crawl before you can walk.
- Next message: LX-i: "Re: If you were inventing CoBOL..."
- Previous message: Frederico Fonseca: "Re: Cobol Editor For Windows"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: James J. Gavan: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
