COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
in [Cobol]
|
Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Anonymous on 17 Sep 2007 05:40 In article <189re35chs8bfaq2riqhm1n0dod28c3qtr(a)4ax.com>, Robert <no(a)e.mail> wrote: >On Sun, 16 Sep 2007 00:26:57 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq(a)4ax.com>, >>Robert <no(a)e.mail> wrote: >>>On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >>> >>>>On Sep 15, 6:50 pm, Robert <n...(a)e.mail> wrote: >>>>> On Fri, 14 Sep 2007 22:51:45 -0700, Richard <rip...(a)Azonic.co.nz> wrote: >> >>[snip] >> >>>>> >Just why is 'index is faster than subscript' a myth, again ? >>>>> >>>>> 1. Because a timing test showed indexes are slower. >>>> >>>>And you have done a timing test on every machine in the universe. >>> >>>If humans were unable to generalize, there wouldn't be any machines. >>>We'd be living in >>>shacks and tents. >> >>What Mr Plinston puts forward, Mr Wagner, may demonstrate why there is a >>season to things and a time to every purpose. The above might be phrased >>otherwise and yet still retain some original flavor, eg: >> >>A: Just why is 'index is faster than subscript' a myth, again ? >> >>B: Because a timing test showed indexes are slower. >> >>A: '*A* timing test' (emphasis added) shows that under *a* set of >>conditions one might not be better than the other; it is possible that >>under other sets of conditions the other might be better than the one. > >I tried to make the tests represent typical usage AND I posted source >code. If you think >the test is unfair, say so or write your own test. Were I to think such, Mr Wagner, I might consider doing such. Until I state that I think such there's little reason to assume that I do. [snip] >>>They shouldn't give advice until they test on every machine. >> >>It has been advised that one should tend to their own garden first, Mr >>Wagner, before one tends to Micro Focus'... or something like that. > >We all plant our crops in the soil plowed by Micro Focus .. or something >like that. Or... nothing like that. Plural majestatus est... or something like that. DD
From: Anonymous on 17 Sep 2007 05:46 In article <7jlre31oq6blvdmk49jl2974tctunhkr43(a)4ax.com>, Robert <no(a)e.mail> wrote: [snip] >I spent years trying to prove that 2 is not the optimal division factor. >Based on >calculus, I really believed it was e - 1, which is approximately 1.7. I >almost 'proved' >it with tests. Years later I saw that 2 really IS the optimal division >factor. On well, I >tried. 'I try to make my words good 'n tender 'cause I might have to eat them tomorrow' might be seen as a variation of 'Looking back and saying 'Oh, that was but the folly of a decade past' might cause one to recall that what one does, now, may be looked at, at some point... as the folly of a decade past'. (the second one is a memory-mangling of Nietzsche, I cannot recall the original nor the source) DD
From: Pete Dashwood on 17 Sep 2007 06:38 <docdwarf(a)panix.com> wrote in message news:fcliei$57t$1(a)reader1.panix.com... > In article <7jlre31oq6blvdmk49jl2974tctunhkr43(a)4ax.com>, > Robert <no(a)e.mail> wrote: > > [snip] > >>I spent years trying to prove that 2 is not the optimal division factor. >>Based on >>calculus, I really believed it was e - 1, which is approximately 1.7. I >>almost 'proved' >>it with tests. Years later I saw that 2 really IS the optimal division >>factor. On well, I >>tried. > > 'I try to make my words good 'n tender 'cause I might have to eat them > tomorrow' might be seen as a variation of 'Looking back and saying 'Oh, > that was but the folly of a decade past' might cause one to recall that > what one does, now, may be looked at, at some point... as the folly of a > decade past'. > > (the second one is a memory-mangling of Nietzsche, I cannot recall the > original nor the source) > I've always thought that "Keep your words soft and sweet, for you may have to eat them" was a Chinese proverb. But I can't cite and I haven't GOOGLEd, so I could be wrong. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 17 Sep 2007 08:02 On Sun, 16 Sep 2007 22:16:01 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >On Sep 17, 10:33 am, Robert <n...(a)e.mail> wrote: >> If Itanium is unsuccessful, CPUs are close to hitting the wall in terms of speed. We can't >> make them much more complex (required to avoid instruction collisions) because we can't >> make traces much smaller. We're approaching the size of atoms. > >No, wrong. Itanium is 180nanom to 90nanom. Current stuff is down to >40nanom. Isn't the limit about 20 nanom? I may have been thinking 20 angstroms, which is 2.0 nm.
From: Anonymous on 17 Sep 2007 08:09
In article <ogrre3p3d1ps6i0kipohsgjpuog6chje0q(a)4ax.com>, Robert <no(a)e.mail> wrote: >On Mon, 17 Sep 2007 02:14:38 GMT, "William M. Klein" ><wmklein(a)nospam.netcom.com> wrote: > >> >>"Robert" <no(a)e.mail> wrote in message >>news:j6ore39s4saaeccj4mkfsghkb0s0blk19j(a)4ax.com... >>> On Mon, 17 Sep 2007 01:43:39 GMT, "William M. Klein" >>> <wmklein(a)nospam.netcom.com> wrote: >>> >>>>An ODO is ONLY faster if the number of "filled in" table entries varies. >>> >>> It usually does. It's usually loaded from a database table or file. >>> >> >>Agan, your expereince is not the same as mine. In most (certainly NOT all) >>cases, SEARCH ALL is done on tables of things like "tax codes" "state >>abreviations", etc. Although it would certainly be "nice" if such code was >>dynamically read in, most that I have seen are "hard-coded" and the length of >>the table is changed when new entries are added (or entries removed). > >That's how we did it in the Old Days. Today, a program change, no matter >how trivil, takes >six months of approvals and testing. That might be, Mr Wagner, because in the Oldene Dayse the *real* work was still being done by eyeshade-wearing, arm-gartered, quill-wielding accountants in ledgers. Now that more data are being kept on a computer it is necessary to make sure that changes introduced don't cause errors when quarterly and annual processing are done. (some people like seeing changes *banged* into Prod at a moment's notice... and some people believe in 'job security via idiosyncratic knowledge', as well) [snip] >A smart program might cache the results of the last hundred lookups in a >Cobol table. What an innovative thought... it is absoultely *nothing* like IF INFILE-CURRENT-CLIENT NOT = WS-PREVIOUS-CLIENT PERFORM A615872-GET-CLIENT-DATA THRU A615872-GCD-EX. .... as used to be done in the Oldene Dayse. DD |