Re: [U2] trimming a list (a test of your ability)
Just a thought.. If it's THAT big, might be quicker to actually write to a sequential file if you're on an OS that maps /tmp to memory like Solaris can (version dependent?). But I ain't got a Solaris box to test that theory. Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David L. Wasylenko Sent: 12 July 2012 23:09 To: U2 Users List Subject: Re: [U2] trimming a list (a test of your ability) JUST FOR FUN... I bumped the iteration count to 10,000,000 And the DIM BIG() to 10,000 Ran in 60 seconds with 157,094 to 355,618 iterations per second. Total byte count of the resulting @MV list was 78,888,896 bytes NOT too shabby ... david ... David L. Wasylenko President, Pick Professionals, Inc w) 314 558 1482 d...@pickpro.com -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David L. Wasylenko Sent: Thursday, July 12, 2012 4:57 PM To: U2 Users List Subject: Re: [U2] trimming a list (a test of your ability) Not exactly. Current position of EACH unique variable... And a DIM BIG(1000) has/is 1,000 unique variables. So 1,000 unique pointers. And the writing whole string --- yes it would, if the size outstrips the memory allocated. By using 1,000 smaller strings, the move is triggered much less often, allowing the append operation VS reallocation of a new, larger memory buffer. With REC-1 or REC1,-1 syntax: Using a *single* variable, 1,000,000 iterations: @am delimited = 21.719 seconds, ranging from 41,545 iterations a second to 45,161, very consistant @vm delimited = ( Had to stop it at 100,000 iterations, 235.561 seconds) from 12,787 iterations a second at start down to 449 per sec at 100,000 values, consistently slower and slower Just using REC-1 saved a HUGE amount of time. Using a DIM(1000) variable: @vm delimited = 24.859 seconds 39,553 to 317,460 per second; wide swing but much faster than a single variable @am delimited = 3.781 seconds245,158 to 425,531 per second; the big winner The @VM delimiter will continually get slower and slower using either method, however, the slowdown occurs only 1,000 times. So in either case, the savings is significant using @AM - the DIM() concept is icing and the best method I've seen. ... david ... David L. Wasylenko President, Pick Professionals, Inc w) 314 558 1482 d...@pickpro.com -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Thursday, July 12, 2012 4:16 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] trimming a list (a test of your ability) I beg to differ. The runtime maintains a pointer to *your current attribute*, as I understand it. Not to *each* attribute location. One buffer location, not a thousand. If it maintained a pointer to *each* attribute location, you could jump around in the variable at random and has access as quick as a dimensioned array gives you. But I believe that is not the case. By-attribute insertion is quick *only* because you are always inserting at the current position (or the next). Change this to a locate with insertion and it should dramatically slow down. This is because the entire string is being picked up and put down on each insert. The whole string. I think in the case of insertion at the end (the current position) it doesn't actually pick up and rewrite the whole string on each append. Just the end of the string. -Original Message- From: David L. Wasylenko d...@pickpro.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Jul 12, 2012 2:09 pm Subject: Re: [U2] trimming a list (a test of your ability) Nope; as to do with how systems handle system delimiters. ynamic arrays maintain pointers to attribute locations, but not the @VM ointers. he system already has buffering, memory management etc. for string anipulation. However, what makes it fast is the routine makes use of 1,000 different memory ocations, ach being vastly smaller than the final resulting record. Each element of the array is smaller string, resulting in less paging, heap anipulation etc. The following example uses ONE variable instead of the previous 1000; xecution time is 21.735 seconds compared to the prior version: 3.75 seconds 01:D.ARRAY= ; START.TIME=TIME() 2:FOR PTR=1 TO 100 3: GOSUB H.ADD; * add to array 4: ! IF NOT(MOD(PTR,1000)) THEN CRT PTR 5:NEXT PTR 6:GOSUB H.RESULT 7:END.TIME=TIME() 8:CRT END.TIME, START.TIME, END.TIME-START.TIME 9:STOP 0: ** 1: H.ADD:* add to array 2: ** 3:D.ARRAY-1=PTR 4: * 5:RETURN 6: ** 7: H.RESULT:* construct resulting array 8: ** 9:D.ARRAY=CHANGE(D.ARRAY,@AM,@VM) 0: * 1:RETURN 2: * 3: * end of job 4: * 5: END david . David L. Wasylenko resident, Pick Professionals, Inc ) 314 558
Re: [U2] trimming a list (a test of your ability)
You must do WHILE MORE:NEXT.ID or WHILE NEXT.ID:MORE otherwise the last NEXT.ID will not be processed From: dennis bartlett dqbartl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Friday, 13 July 2012, 7:09 Subject: Re: [U2] trimming a list (a test of your ability) Hi Steven The REMOVE statement process a multivalued list. The SETTING clause will set the variable to either 3, or 2, or 1, or 0 depending on the value of the delimiter last encountered... 1 for @FM 2 for @VM 3 for @SM 0 for End Of String If the array consists only of @FM, then MORE will be set to 1 for each iteration (since the delimiter it is encountering each time is an @FM) and then, when the last element is read, MORE will be set to ZERO, and the WHILE MORE will fail, thus the loop is exited. If FM.ARRAY is empty, MORE will return as 0 and the loop will exit, but you're right - the WHILE MORE line should be one line higher.. UNIQ.LIST = '' LOOP REMOVE NEXT.ID http://next.id/ FROM FM.ARRAY SETTING MORE WHILE MORE LOCATE(NEXT.ID http://next.id/,UNIQ.LIST,1;POS) ELSE UNIQ.LIST-1 = NEXT.ID http://next.id/ REPEAT the WHILE statement is in effect a while it is not zero and the second it becomes a zero, the loop exits. ___ 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
Re: [U2] trimming a list (a test of your ability)
On 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or another. Except that a string, as far as I am aware, uses the pascal method I think it's called - namely a string is stored as its length followed by the string (or a Hollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a 'string' faster than -1? Very much so And if so, why doesn't the database use the same logic for -1 as it does for := since technically they're accomplishing the same thing? Because it's doing it in a completely different way. The -1 logic just happens to work whereas the append logic was designed to work that way. If you use a field number, the code searches for that field - I think it takes the field as a counter, and searches the string decrementing the counter every time it hits a field mark. When the counter hits zero it's found what it's looking for. Of course, if you start at -1, it never hits zero and ends up at the end of the string. But this is by accident not design. To do what you suggest would require special case code which doesn't - logically - belong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] trimming a list (a test of your ability)
Yes/No A string is stored in a fixed length *spot*, and is ended by an FF. This is *why* if you actually try to create a string in BASIC (or read one) with an embedded FF in it, the runtime will truncate the string It doesn' actually truncate the variable spot, what it does is fool the run-time into thinking you've hit the end of the string so it ignores anything else after it thinking it's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of any variable, if you're string is only 8, it will then allocate you 50 bytes, and *move* the string into that new spot and the old spot will just be a direct pointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes elsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, that's the end. The run-time will also garbage-collect the old spots by the way, for use as other things. I'd be surprised if it actually wastes effort to store the length constantly at the fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- From: Wols Lists antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 3:53 am Subject: Re: [U2] trimming a list (a test of your ability) On 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or another. Except that a string, as far as I am aware, uses the pascal method I hink it's called - namely a string is stored as its length followed by he string (or a Hollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a 'string' faster than -1? Very much so And if so, why doesn't the database use the same logic for -1 as it does for := since technically they're accomplishing the same thing? ecause it's doing it in a completely different way. The -1 logic just happens to work whereas the append logic was designed to work hat way. If you use a field number, the code searches for that field - I think it akes the field as a counter, and searches the string decrementing the ounter every time it hits a field mark. When the counter hits zero it's ound what it's looking for. Of course, if you start at -1, it never hits zero and ends up at the end f the string. But this is by accident not design. To do what you uggest would require special case code which doesn't - logically - elong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions heers, ol __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] trimming a list (a test of your ability)
Interesting but I think each time you do a LOCATE it must scan the entire string from front to back. I think on very large lists, you might see a speed improvement if you sort, append and then do a backward walk to remove dups. Of course that's much more complicated. -Original Message- From: dennis bartlett dqbartl...@gmail.com To: Marco Manyevere mmanyev...@yahoo.com; U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 7:59 am Subject: Re: [U2] trimming a list (a test of your ability) Actually the way I wrote it the first time was correct but I needed to test or null x's i.e. z='' oop remove x from y setting more if x ne '' then locate (...) else z := x:@fm end hile more epeat On 13 July 2012 19:30, Marco Manyevere mmanyev...@yahoo.com wrote: You must do WHILE MORE:NEXT.ID or WHILE NEXT.ID:MORE otherwise the last NEXT.ID will not be processed From: dennis bartlett dqbartl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Friday, 13 July 2012, 7:09 Subject: Re: [U2] trimming a list (a test of your ability) Hi Steven The REMOVE statement process a multivalued list. The SETTING clause will set the variable to either 3, or 2, or 1, or 0 depending on the value of the delimiter last encountered... 1 for @FM 2 for @VM 3 for @SM 0 for End Of String If the array consists only of @FM, then MORE will be set to 1 for each iteration (since the delimiter it is encountering each time is an @FM) and then, when the last element is read, MORE will be set to ZERO, and the WHILE MORE will fail, thus the loop is exited. If FM.ARRAY is empty, MORE will return as 0 and the loop will exit, but you're right - the WHILE MORE line should be one line higher.. UNIQ.LIST = '' LOOP REMOVE NEXT.ID http://next.id/ FROM FM.ARRAY SETTING MORE WHILE MORE LOCATE(NEXT.ID http://next.id/,UNIQ.LIST,1;POS) ELSE UNIQ.LIST-1 = NEXT.ID http://next.id/ REPEAT the WHILE statement is in effect a while it is not zero and the second it becomes a zero, the loop exits. ___ 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 __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] trimming a list (a test of your ability)
For universe, I believe that used to be true - I seem to recall running into this maybe 15+(?) years ago. I also seem to recall that the resolution to this issue was, as was mentioned, prepending all strings with a length. Try it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) end [abc xyz] 7 5 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Friday, July 13, 2012 12:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] trimming a list (a test of your ability) Yes/No A string is stored in a fixed length *spot*, and is ended by an FF. This is *why* if you actually try to create a string in BASIC (or read one) with an embedded FF in it, the runtime will truncate the string It doesn' actually truncate the variable spot, what it does is fool the run-time into thinking you've hit the end of the string so it ignores anything else after it thinking it's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of any variable, if you're string is only 8, it will then allocate you 50 bytes, and *move* the string into that new spot and the old spot will just be a direct pointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes elsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, that's the end. The run-time will also garbage-collect the old spots by the way, for use as other things. I'd be surprised if it actually wastes effort to store the length constantly at the fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- From: Wols Lists antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 3:53 am Subject: Re: [U2] trimming a list (a test of your ability) On 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or another. Except that a string, as far as I am aware, uses the pascal method I hink it's called - namely a string is stored as its length followed by he string (or a Hollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a 'string' faster than -1? Very much so And if so, why doesn't the database use the same logic for -1 as it does for := since technically they're accomplishing the same thing? ecause it's doing it in a completely different way. The -1 logic just happens to work whereas the append logic was designed to work hat way. If you use a field number, the code searches for that field - I think it akes the field as a counter, and searches the string decrementing the ounter every time it hits a field mark. When the counter hits zero it's ound what it's looking for. Of course, if you start at -1, it never hits zero and ends up at the end f the string. But this is by accident not design. To do what you uggest would require special case code which doesn't - logically - elong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions heers, ol __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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
Re: [U2] trimming a list (a test of your ability)
Just to be complete : for j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end next end j=0 x =[abcxyz] len=7 pos=5 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of u2ug Sent: Friday, July 13, 2012 1:10 PM To: U2 Users List Subject: Re: [U2] trimming a list (a test of your ability) For universe, I believe that used to be true - I seem to recall running into this maybe 15+(?) years ago. I also seem to recall that the resolution to this issue was, as was mentioned, prepending all strings with a length. Try it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) end [abc xyz] 7 5 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Friday, July 13, 2012 12:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] trimming a list (a test of your ability) Yes/No A string is stored in a fixed length *spot*, and is ended by an FF. This is *why* if you actually try to create a string in BASIC (or read one) with an embedded FF in it, the runtime will truncate the string It doesn' actually truncate the variable spot, what it does is fool the run-time into thinking you've hit the end of the string so it ignores anything else after it thinking it's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of any variable, if you're string is only 8, it will then allocate you 50 bytes, and *move* the string into that new spot and the old spot will just be a direct pointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes elsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, that's the end. The run-time will also garbage-collect the old spots by the way, for use as other things. I'd be surprised if it actually wastes effort to store the length constantly at the fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- From: Wols Lists antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 3:53 am Subject: Re: [U2] trimming a list (a test of your ability) On 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or another. Except that a string, as far as I am aware, uses the pascal method I hink it's called - namely a string is stored as its length followed by he string (or a Hollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a 'string' faster than -1? Very much so And if so, why doesn't the database use the same logic for -1 as it does for := since technically they're accomplishing the same thing? ecause it's doing it in a completely different way. The -1 logic just happens to work whereas the append logic was designed to work hat way. If you use a field number, the code searches for that field - I think it akes the field as a counter, and searches the string decrementing the ounter every time it hits a field mark. When the counter hits zero it's ound what it's looking for. Of course, if you start at -1, it never hits zero and ends up at the end f the string. But this is by accident not design. To do what you uggest would require special case code which doesn't - logically - elong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions heers, ol __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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
Re: [U2] trimming a list (a test of your ability)
Well I'll be a horned toad. However try this ED BP TESTFF 001 PRINT DOG:CHAR(255):CAT .^ Up arrow mode .R/DOG/DOG^255 001 PRINT DOG :CHAR(255):CAT .FI BASIC BP TESTFF No closing quote The compiler doesn't see the FF as the same sort of thing as other characters even if the editor does -Original Message- From: u2ug simpson-u...@gerzio.ca To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 10:43 am Subject: Re: [U2] trimming a list (a test of your ability) Just to be complete : for j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end ext nd =0 x =[abcxyz] len=7 pos=5 -Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of u2ug ent: Friday, July 13, 2012 1:10 PM o: U2 Users List ubject: Re: [U2] trimming a list (a test of your ability) For universe, I believe that used to be true - I seem to recall running into his maybe 15+(?) years ago. also seem to recall that the resolution to this issue was, as was mentioned, repending all strings with a length. Try it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) nd [abc xyz] Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of Wjhonson ent: Friday, July 13, 2012 12:27 PM o: u2-users@listserver.u2ug.org ubject: Re: [U2] trimming a list (a test of your ability) es/No A string is stored in a fixed length *spot*, and is ended by an FF. his is *why* if you actually try to create a string in BASIC (or read one) with n embedded FF in it, the runtime will truncate the string It doesn' actually runcate the variable spot, what it does is fool the run-time into thinking ou've hit the end of the string so it ignores anything else after it thinking t's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of ny variable, if you're string is only 8, it will then allocate you 50 bytes, nd *move* the string into that new spot and the old spot will just be a direct ointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes lsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, hat's the end. he run-time will also garbage-collect the old spots by the way, for use as ther things. I'd be surprised if it actually wastes effort to store the length constantly at he fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- rom: Wols Lists antli...@youngman.org.uk o: u2-users u2-users@listserver.u2ug.org ent: Fri, Jul 13, 2012 3:53 am ubject: Re: [U2] trimming a list (a test of your ability) n 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or nother. xcept that a string, as far as I am aware, uses the pascal method I hink it's alled - namely a string is stored as its length followed by he string (or a ollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a string' faster than -1? ery much so And if so, why doesn't the database use the same logic for -1 as it does for = since technically they're accomplishing the same thing? cause it's doing it in a completely different way. The -1 logic just happens o work whereas the append logic was designed to work hat way. f you use a field number, the code searches for that field - I think it akes he field as a counter, and searches the string decrementing the ounter every ime it hits a field mark. When the counter hits zero it's ound what it's ooking for. f course, if you start at -1, it never hits zero and ends up at the end f the tring. But this is by accident not design. To do what you uggest would require pecial case code which doesn't - logically - elong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions eers, l _ -Users mailing list -us...@listserver.u2ug.org tp://listserver.u2ug.org/mailman/listinfo/u2-users ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org
Re: [U2] trimming a list (a test of your ability)
Yep - I've run into that at some time as well. I seem to remember this being a problem with the editor or with reading/writing values to an mv file rather than internal string handling. If you re-edit the source, do you find that it has been split into : 001 PRINT DOG 002 :CHAR(255):CAT ? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Friday, July 13, 2012 1:49 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] trimming a list (a test of your ability) Well I'll be a horned toad. However try this ED BP TESTFF 001 PRINT DOG:CHAR(255):CAT .^ Up arrow mode .R/DOG/DOG^255 001 PRINT DOG :CHAR(255):CAT .FI BASIC BP TESTFF No closing quote The compiler doesn't see the FF as the same sort of thing as other characters even if the editor does -Original Message- From: u2ug simpson-u...@gerzio.ca To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 10:43 am Subject: Re: [U2] trimming a list (a test of your ability) Just to be complete : for j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end ext nd =0 x =[abcxyz] len=7 pos=5 -Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of u2ug ent: Friday, July 13, 2012 1:10 PM o: U2 Users List ubject: Re: [U2] trimming a list (a test of your ability) For universe, I believe that used to be true - I seem to recall running into his maybe 15+(?) years ago. also seem to recall that the resolution to this issue was, as was mentioned, repending all strings with a length. Try it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) nd [abc xyz] Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of Wjhonson ent: Friday, July 13, 2012 12:27 PM o: u2-users@listserver.u2ug.org ubject: Re: [U2] trimming a list (a test of your ability) es/No A string is stored in a fixed length *spot*, and is ended by an FF. his is *why* if you actually try to create a string in BASIC (or read one) with n embedded FF in it, the runtime will truncate the string It doesn' actually runcate the variable spot, what it does is fool the run-time into thinking ou've hit the end of the string so it ignores anything else after it thinking t's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of ny variable, if you're string is only 8, it will then allocate you 50 bytes, nd *move* the string into that new spot and the old spot will just be a direct ointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes lsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, hat's the end. he run-time will also garbage-collect the old spots by the way, for use as ther things. I'd be surprised if it actually wastes effort to store the length constantly at he fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- rom: Wols Lists antli...@youngman.org.uk o: u2-users u2-users@listserver.u2ug.org ent: Fri, Jul 13, 2012 3:53 am ubject: Re: [U2] trimming a list (a test of your ability) n 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or nother. xcept that a string, as far as I am aware, uses the pascal method I hink it's alled - namely a string is stored as its length followed by he string (or a ollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a string' faster than -1? ery much so And if so, why doesn't the database use the same logic for -1 as it does for = since technically they're accomplishing the same thing? cause it's doing it in a completely different way. The -1 logic just happens o work whereas the append logic was designed to work hat way. f you use a field number, the code searches for that field - I think it akes he field as a counter, and searches the string decrementing the ounter every ime it hits a field mark. When the counter hits zero it's ound what it's ooking for. f course, if you start at -1, it never hits zero and ends up at the end f the tring. But this is by accident not design. To do what you uggest would require pecial case code which doesn't - logically - elong there. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions eers, l
Re: [U2] trimming a list (a test of your ability)
Oops - meant to say : I seem to remember this being a problem writing values to an mv file rather than internal string handling. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of u2ug Sent: Friday, July 13, 2012 2:54 PM To: U2 Users List Subject: Re: [U2] trimming a list (a test of your ability) Yep - I've run into that at some time as well. I seem to remember this being a problem with the editor or with reading/writing values to an mv file rather than internal string handling. If you re-edit the source, do you find that it has been split into : 001 PRINT DOG 002 :CHAR(255):CAT ? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Friday, July 13, 2012 1:49 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] trimming a list (a test of your ability) Well I'll be a horned toad. However try this ED BP TESTFF 001 PRINT DOG:CHAR(255):CAT .^ Up arrow mode .R/DOG/DOG^255 001 PRINT DOG :CHAR(255):CAT .FI BASIC BP TESTFF No closing quote The compiler doesn't see the FF as the same sort of thing as other characters even if the editor does -Original Message- From: u2ug simpson-u...@gerzio.ca To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 10:43 am Subject: Re: [U2] trimming a list (a test of your ability) Just to be complete : for j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end ext nd =0 x =[abcxyz] len=7 pos=5 -Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of u2ug ent: Friday, July 13, 2012 1:10 PM o: U2 Users List ubject: Re: [U2] trimming a list (a test of your ability) For universe, I believe that used to be true - I seem to recall running into his maybe 15+(?) years ago. also seem to recall that the resolution to this issue was, as was mentioned, repending all strings with a length. Try it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) nd [abc xyz] Original Message- rom: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] n Behalf Of Wjhonson ent: Friday, July 13, 2012 12:27 PM o: u2-users@listserver.u2ug.org ubject: Re: [U2] trimming a list (a test of your ability) es/No A string is stored in a fixed length *spot*, and is ended by an FF. his is *why* if you actually try to create a string in BASIC (or read one) with n embedded FF in it, the runtime will truncate the string It doesn' actually runcate the variable spot, what it does is fool the run-time into thinking ou've hit the end of the string so it ignores anything else after it thinking t's leftover garbage from trimming or something. So initially let's say you get a spot of 8 bytes which is the default size of ny variable, if you're string is only 8, it will then allocate you 50 bytes, nd *move* the string into that new spot and the old spot will just be a direct ointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes lsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, hat's the end. he run-time will also garbage-collect the old spots by the way, for use as ther things. I'd be surprised if it actually wastes effort to store the length constantly at he fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -Original Message- rom: Wols Lists antli...@youngman.org.uk o: u2-users u2-users@listserver.u2ug.org ent: Fri, Jul 13, 2012 3:53 am ubject: Re: [U2] trimming a list (a test of your ability) n 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or nother. xcept that a string, as far as I am aware, uses the pascal method I hink it's alled - namely a string is stored as its length followed by he string (or a ollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a string' faster than -1? ery much so And if so, why doesn't the database use the same logic for -1 as it does for = since technically they're accomplishing the same thing? cause it's doing it in a completely different way. The -1 logic just happens o work whereas the append logic was designed to work hat way. f you use a field number, the code searches for that field - I think it akes he field as a counter, and searches the string decrementing the ounter every ime it hits a field mark. When the counter hits zero it's ound what it's ooking for. f course, if you start at -1, it never hits zero and ends up at the
Re: [U2] trimming a list (a test of your ability)
The Universe editor seems to handle it, but if I write a BASIC program to display the line to my screen, it's truncated So it seems a bit of this and a bit of that. One systems programmer said hey let's fix it here, and didn't tell their colleague in the next cube. -Original Message- From: u2ug simpson-u...@gerzio.ca To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 12:20 pm Subject: Re: [U2] trimming a list (a test of your ability) Yep - I've run into that at some time as well. seem to remember this being a problem with the editor or with eading/writing values to an mv file rather than internal string andling. f you re-edit the source, do you find that it has been split into : 001 PRINT DOG 02 :CHAR(255):CAT ? Original Message- rom: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson ent: Friday, July 13, 2012 1:49 PM o: u2-users@listserver.u2ug.org ubject: Re: [U2] trimming a list (a test of your ability) ell I'll be a horned toad. owever try this ED BP TESTFF 01 PRINT DOG:CHAR(255):CAT ^ p arrow mode R/DOG/DOG^255 01 PRINT DOG :CHAR(255):CAT FI BASIC BP TESTFF No closing quote The compiler doesn't see the FF as the same sort of thing as other haracters even if the editor does Original Message- rom: u2ug simpson-u...@gerzio.ca o: U2 Users List u2-users@listserver.u2ug.org ent: Fri, Jul 13, 2012 10:43 am ubject: Re: [U2] trimming a list (a test of your ability) ust to be complete : or j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end xt d =0 =[abcxyz] en=7 os=5 -Original Message- om: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] Behalf Of u2ug nt: Friday, July 13, 2012 1:10 PM : U2 Users List bject: Re: [U2] trimming a list (a test of your ability) For universe, believe that used to be true - I seem to recall running into his maybe 5+(?) years ago. also seem to recall that the resolution to this issue was, as was entioned, repending all strings with a length. ry it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) d abc xyz] Original Message- om: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] Behalf Of Wjhonson nt: Friday, July 13, 2012 12:27 PM : u2-users@listserver.u2ug.org bject: Re: [U2] trimming a list (a test of your ability) es/No string is stored in a fixed length *spot*, and is ended by an FF. is is *why* if you actually try to create a string in BASIC (or read ne) with n embedded FF in it, the runtime will truncate the string It oesn' actually runcate the variable spot, what it does is fool the un-time into thinking ou've hit the end of the string so it ignores nything else after it thinking t's leftover garbage from trimming or omething. o initially let's say you get a spot of 8 bytes which is the default ize of ny variable, if you're string is only 8, it will then allocate ou 50 bytes, nd *move* the string into that new spot and the old spot ill just be a direct ointer to the new spot. f you exceed 50 bytes, it then *allocates* you a new *spot* of 250 ytes lsewhere, and the original 8 byte spot now points at the new spot nd so on. owever, as it scans the string looking for the *end*, if it encounters n FF, hat's the end. e run-time will also garbage-collect the old spots by the way, for use s ther things. 'd be surprised if it actually wastes effort to store the length onstantly at he fore, but I'm willing to be edumacated on that abstruse oint. (Or pointer) Will -Original Message- om: Wols Lists antli...@youngman.org.uk : u2-users u2-users@listserver.u2ug.org nt: Fri, Jul 13, 2012 3:53 am bject: Re: [U2] trimming a list (a test of your ability) n 12/07/12 16:15, Dave Laansma wrote: 'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' bout pointers, it still has to get to the end of the 'string' one way r nother. cept that a string, as far as I am aware, uses the pascal method I ink it's alled - namely a string is stored as its length followed by he tring (or a ollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to string' faster than -1? ry much so And if so, why doesn't the database use the same logic for -1 as it oes for = since technically they're accomplishing the same thing? cause it's doing it in a completely different way. The -1 logic just appens o work whereas the append logic was designed to work hat way. you use a field number, the code searches for that field - I think it kes he field as a counter, and searches the string decrementing the unter every ime it hits a field mark. When the counter hits zero it's und what it's ooking for. course, if you start at -1, it never hits zero and ends up at the end the tring. But this is by
Re: [U2] trimming a list (a test of your ability)
I think you know that various bits of the entire system have been tweaked to *allow* an FF, and other various bits have not. So if you do a size-based Read on a Windows file in Universe, and it has an embedded FF, it will probably truncate But perhaps you can read it using a line-based Read That sort of thing. Some of this may be by design, some by default, some kinda lookin like a bug. -Original Message- From: u2ug simpson-u...@gerzio.ca To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Jul 13, 2012 12:23 pm Subject: Re: [U2] trimming a list (a test of your ability) Oops - meant to say : I seem to remember this being a problem writing values to an mv file ather than internal string handling. Original Message- rom: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of u2ug ent: Friday, July 13, 2012 2:54 PM o: U2 Users List ubject: Re: [U2] trimming a list (a test of your ability) Yep - I've run into that at some time as well. seem to remember this being a problem with the editor or with eading/writing values to an mv file rather than internal string andling. f you re-edit the source, do you find that it has been split into : 001 PRINT DOG 02 :CHAR(255):CAT ? Original Message- rom: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson ent: Friday, July 13, 2012 1:49 PM o: u2-users@listserver.u2ug.org ubject: Re: [U2] trimming a list (a test of your ability) ell I'll be a horned toad. owever try this ED BP TESTFF 01 PRINT DOG:CHAR(255):CAT ^ p arrow mode R/DOG/DOG^255 01 PRINT DOG :CHAR(255):CAT FI BASIC BP TESTFF No closing quote The compiler doesn't see the FF as the same sort of thing as other haracters even if the editor does Original Message- rom: u2ug simpson-u...@gerzio.ca o: U2 Users List u2-users@listserver.u2ug.org ent: Fri, Jul 13, 2012 10:43 am ubject: Re: [U2] trimming a list (a test of your ability) ust to be complete : or j=0 to 255 if char(j)='x' then continue x=abc:char(j):xyz l=len(x) p=index(x,x,1) if j=0 or l#7 or p#5 then crt j=:j crt x =[:x:] crt len=:l crt pos=:p end xt d =0 =[abcxyz] en=7 os=5 -Original Message- om: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] Behalf Of u2ug nt: Friday, July 13, 2012 1:10 PM : U2 Users List bject: Re: [U2] trimming a list (a test of your ability) For universe, believe that used to be true - I seem to recall running into his maybe 5+(?) years ago. also seem to recall that the resolution to this issue was, as was entioned, repending all strings with a length. ry it: x=abc:char(255):xyz crt [:x:] crt len(x) crt index(x,x,1) d abc xyz] Original Message- om: u2-users-boun...@listserver.u2ug.org mailto:u2-users-boun...@listserver.u2ug.org] Behalf Of Wjhonson nt: Friday, July 13, 2012 12:27 PM : u2-users@listserver.u2ug.org bject: Re: [U2] trimming a list (a test of your ability) es/No string is stored in a fixed length *spot*, and is ended by an FF. is is *why* if you actually try to create a string in BASIC (or read ne) with n embedded FF in it, the runtime will truncate the string It oesn' actually runcate the variable spot, what it does is fool the un-time into thinking ou've hit the end of the string so it ignores nything else after it thinking t's leftover garbage from trimming or omething. o initially let's say you get a spot of 8 bytes which is the default ize of ny variable, if you're string is only 8, it will then allocate ou 50 bytes, nd *move* the string into that new spot and the old spot ill just be a direct ointer to the new spot. f you exceed 50 bytes, it then *allocates* you a new *spot* of 250 ytes lsewhere, and the original 8 byte spot now points at the new spot nd so on. owever, as it scans the string looking for the *end*, if it encounters n FF, hat's the end. e run-time will also garbage-collect the old spots by the way, for use s ther things. 'd be surprised if it actually wastes effort to store the length onstantly at he fore, but I'm willing to be edumacated on that abstruse oint. (Or pointer) Will -Original Message- om: Wols Lists antli...@youngman.org.uk : u2-users u2-users@listserver.u2ug.org nt: Fri, Jul 13, 2012 3:53 am bject: Re: [U2] trimming a list (a test of your ability) n 12/07/12 16:15, Dave Laansma wrote: 'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' bout pointers, it still has to get to the end of the 'string' one way r nother. cept that a string, as far as I am aware, uses the pascal method I ink it's alled - namely a string is stored as its length followed by he tring (or a ollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to string' faster than -1? ry much so And if so, why doesn't the database use the same logic for -1 as it oes for = since technically they're
