Yes it keeps track of the position of the current field (only), not each field. It's not indexed. Its just a one value pointer.
-----Original Message----- From: Wols Lists <antli...@youngman.org.uk> To: u2-users <u2-users@listserver.u2ug.org> Sent: Tue, Feb 12, 2013 12:16 pm Subject: Re: [U2] : Evaluating DCOUNT On 12/02/13 19:04, Wjhonson wrote: > Correct me if I'm misunderstanding you Tom, but you said that field marks are indexes so the first scan resolves where each field begins. That is not correct, at least not literally. > > Count or Raising or Lowering or Scanning in general will not create an index to the position of any fields. > The Remove maintains *A* (singular) pointer to where it's at, right now, as > it moves along. > It's not a fully indexed string. There's just a current position pointer. One. > The thing here, is Tom said he used for/next, and not remove. Just as remove keeps track of the current position in the string, so does *field* access in a dynamic array! So the original program had to scan the multi-value variable every single time round the loop. SLOW. The revised program, using RAISE, was scanning a multi-*field* variable, and BASIC's internal optimiser kept track of the current field. Effectively increasing the speed to pretty much the same as using REMOVE. Cheers, Wol > > > > > > > > -----Original Message----- > From: Tom Whitmore <tewhitm...@ratex.com> > To: U2 Users List <u2-users@listserver.u2ug.org> > Sent: Tue, Feb 12, 2013 10:43 am > Subject: Re: [U2] : Evaluating DCOUNT > > > Hi, > When you have more than about 1,000 values in a field, changing the value > mark > to a field mark, is significant. I had a program that needed to work through > two fields with over 20,000 values. Initially, I left the strings as value > delimited, used a for/next loop and assigned the results to a new field > delimited string using <-1>. The program took about 15 minutes to perform > the > tasks needed. I then raised each string, used remove and concatenated @FM:item. > It was done almost immediately, there was no perception of a delay getting to > TCL. To put it in code snippet, the first took 15 minutes and the second > took > maybe a second. > > X=20K values > Y=20K values > Z='' > MAX=DCOUNT(X,@VM) > FOR C=1 TO MAX > I1=X<1,C> > I2=Y<1,C> > Z<C>=I1*I2 > NEXT C > > > X=RAISE(20Kvalues) > Y=RASE(20Kvalues) > Z='' > LOOP > REMOVE I1 FROM X SETTING XPOS > REMOVE I2 FROM Y SETING YPOS > UNTIL I1='' AND I2='' AND XPOS=0 AND YPOS=0 > IF (Z) > THEN Z:=@AM:I1*I2 > ELSE Z=I1*I2 > REPEAT > > There are several things: > 1) REMOVE is faster than extract, especially when you are working with values > 2) Strings are treated different from dynamic arrays even though in theory > you > are doing the same thing (appending to the end of the string). > 3) COUNT will scan the string, then the extract will scan the string when it is > value delimited. Field marks are indexes so the first scan resolves the > location where each field begins. > > Tom > RATEX Business Solutions > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] > On Behalf Of Dave Laansma > Sent: Tuesday, February 12, 2013 1:21 PM > To: 'U2 Users List' > Subject: Re: [U2] : Evaluating DCOUNT > > Hey Allen, > > The REMOVE so fast <How fast is it?! "Match Game" throwback> that I suspect the > time it takes to interpret the difference between a VM and AM is negligible. > I > could be wrong. > > And as far as using dimensioned arrays, agreed. They do seem to improve speed > ... but still not in comparison to the REMOVE <virtual bow to the REMOVE god>. > > Sincerely, > David Laansma > Hubbard Supply Co. > Direct: 810-342-7143 > Office: 810-234-8681 > Fax: 810-234-6142 > www.hubbardsupply.com > "Delivering Products, Services and Innovative Solutions" > > -----Original Message----- > From: u2-users-boun...@listserver.u2ug.org > [mailto:u2-users-boun...@listserver.u2ug.org] > On Behalf Of Allen Egerton > Sent: Monday, February 11, 2013 9:02 AM > To: U2 Users List > Subject: Re: [U2] : Evaluating DCOUNT > > David, > > You're correct that the remove is faster, and it is because it maintains an > internal pointer to the next item, as opposed to positioning to it for each > reference. > > And I'm pretty sure that you can make it run even faster with: > LINE.KEYS = RAISE(HEADER.REC<200>) > > As a matter of preference, I would set D1 to 999 or some other numeric value > rather than a null, only because Universe/Unidata is typeless, and I would be > afraid that the null, (""), might be treated as a zero; but that's just personal > fear and preference not based on a horror story. > > > On 2/11/2013 8:30 AM, Dave Laansma wrote: >> I would HOPE that it evaluates it each time since the size of <array> could > change within the loop. >> >> Personally if the size of <array> is relatively small, DCOUNT is alright. > However I've found REMOVE to be EXTREMELY faster and therefore use it > whenever > possible, even on small <arrays>. >> >> For example, we have two files, a 'header' and 'detail' file. The keys to >> the > 'detail' file are stored in attribute <200> of the header file. So I'll pull the > keys out of the header record, such: >> >> LINE.KEYS = HEADER.REC<200> >> D1 = "" >> LOOP UNTIL D1 = 0 >> REMOVE LINE.KEY FROM LINE.KEYS SETTING D1 >> <loop statements> >> REPEAT >> >> As opposed to: >> >> FOR V1 = 1 TO DCOUNT(HEADER.REC<200>,@VM) >> LINE.KEY = HEADER.REC<200,V1> >> <loop statements> >> NEXT V1 >> >> Based on historical dialogs on this subject on this forum, I have seen an > improvement in overall performance. >> >> Sincerely, >> David Laansma >> Hubbard Supply Co. >> Direct: 810-342-7143 >> Office: 810-234-8681 >> Fax: 810-234-6142 >> www.hubbardsupply.com >> "Delivering Products, Services and Innovative Solutions" >> >> -----Original Message----- >> From: u2-users-boun...@listserver.u2ug.org >> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey >> Butera >> Sent: Monday, February 11, 2013 7:55 AM >> To: u2-users@listserver.u2ug.org >> Subject: Re: [U2] : Evaluating DCOUNT >> >> On 02/11/2013 12:14 AM, Peter Cheney wrote: >>> Hi Everyone, >>> >>> Does a DCOUNT get evaluated again for each iteration of a loop? >>> Or is UniVerse these days intelligent enough to keep track of what's going > on? >>> >>> e.g. >>> >>> for i = 1 to dcount(array,@fm) >>> *commands here >>> next i >>> >>> versus >>> >>> totalattributes = dcount(array,@fm) >>> for i = 1 to totalattributes >>> *commands here >>> next i >>> >>> Apart from readability and perhaps easier debugging is there an actual > internal difference? >>> I know it was an issue on older pick releases but I cannot remember if it > ever affected UV? >> >> Not sure about universe, but unidata defintely checks the DCOUNT for each > iteration. This produces 4 (not 2): >> >> >> CT=0 >> X=45:@VM:58 >> FOR I=1 TO DCOUNT(X,@VM) >> CT+=1 >> IF I<=2 THEN >> X<1,-1> = 99 >> END >> NEXT I >> CRT CT >> >> > > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > > > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
