Universe gives a slight lead to -1 too.
Also, it compiles Y = Y:CHAR(254):I and Y := CHAR(254):I to exactly the same
thing. I checked with VLIST and even edited the compiled code to be sure.
ALSO (and this surprised me) it doesn't support ROUNDS *= 2
The documenation (Universe BASIC 2-25)
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:
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
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
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
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
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
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
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
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
?
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
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
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
The general reason why I post code snippets like this, isn't really necessarily
always to solve the issue I'm having, but often to see examples of how others
solve similar issues.
It's my belief that by sharing how we do things, we can all learn something new
and interesting. We may use that,
This is the best solution, using REMOVE and building a new list instead of
constantly 'shrinking' the original table.
That being said, as NEW.LIST gets rather large, adding new elements to it can
get 'time' consuming. Just like the REMOVE keeps track of the pointer as you
spin through a table,
That was my first thought,
Change to KEY.COUNT TO 1 STEP -1
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, July 12, 2012 4:22 AM
To: 'U2 Users List'
Subject: Re: [U2] trimming a list (a
Instead of -1, use string=string:char(254):additionalelement
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma
Sent: Thursday, July 12, 2012 9:20 AM
To: Marco Manyevere; U2 Users List
Subject:
String concatenation will probably work faster since it doesn't care about
pointers
IF NEW.LIST# THEN NEW.LIST := @AM (or @VM if you want in the original format)
NEW.LIST := UTILITY.ID
Martin
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
Use 'STEP -1' so as to work from the back to front. That would avoid the need
to reset DISPLAY.LOOP and KEY.COUNT
1295 FOR DISPLAY.LOOP = KEY.COUNT TO 1 STEP -1
1296 UTILITY.ID = KEY.LIST1,DISPLAY.LOOP
1297 GOSUB GET.UTILITY.RECORD
1298 IF
Is this technique significantly faster? It still has to search to the end of
the table each time it appends this string, doesn't it?
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,
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.
So, the question then is, does concatenation := establish and append to
a 'string' faster than -1?
And if so, why doesn't the database use
I just did a test of this on Universe 10 on Windows 7 and it doesn't make any
difference
FFT.BP 'SPEED.TEST'
0001 GOSUB SUB.ONE
0002 GOSUB SUB.TWO
0003 *
0004 GOSUB SUB.TWO
0005 GOSUB SUB.ONE
0006 STOP
0007 *
0008 SUB.ONE:
0009 START = TIME()
0010 A =
Ah, but try it with := instead of Y = Y:
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Daniel McGrath
Sent: Thursday, July 12, 2012 8:56 AM
To: U2 Users List
Subject:
HOLY SMOKES!
X = X : string
Is CRAZY slow! I had to break out.
My results on Unidata/AIX, -1 was SLIGHTLY faster than := for 1,000,000
appendages to a null table.
Sincerely,
David Laansma
IT Manager
Hubbard Supply Co.
Direct: 810-342-7143
Office: 810-234-8681
Fax: 810-234-6142
Absolutely correct, but it didn't make a difference when I reverse the order of
the tests. I got to 0 vs 565 when I shut it down (and 500+ vs 0 in reverse
order). I think that is a clear enough answer.
Caveat, this was done on UDT, other MVDMS may behave different.
As always; don't assume,
Sort of OT:
My NebulaXLite product builds XML files that can get into tens of
megabytes. Concatenation with either method described below can cause
this process to take 1/2 hour or longer. I developed a technique that
reduces build time of these large blocks down to seconds, and no, this
isn't a
You are probably thinking about the technique of pre-allocating the chunk of
memory first, then manually overwriting sections instead of appending to the
end. This saves on system calls to allocate new memory. I think there used to
be something on pick wiki about it.
Regards,
Dan
Nope;
Has to do with how systems handle system delimiters.
Dynamic arrays maintain pointers to attribute locations, but not the @VM
pointers.
The system already has buffering, memory management etc. for string
manipulation.
However, what makes it fast is the routine makes use of 1,000 different
I can think of a way I've used in the past.
You keep track of the size, or use a break every so-many values like 100 or
whatever or a size of 10K or whatever
And then you simply start in a new empty carrier variable
So you have an embedded loop
FOR I = 1 TO 500
A-1 = I
IF NOT(MOD(I,1000))
Could you show us a comparison of times using your methods?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Thursday, July 12, 2012 12:52 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2]
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
From: Lunt, Bruce
Could you show us a comparison of times using your methods?
It'll take a while to do that, sorry. I'm just testing this
functionality in the latest version which will be available for U2 in
a month or so. But I will be publishing before/after performance data
as part of the
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,
Thought I'd have a go at something a bit different so I came up with a
recursive routine (CHECK.LIST). I used a simple list of 5000 integers
and filtered evens out as my test. The recursion basically splits the
list in half until it's smallish, then processes CNT to 1 step -1. It
didn't produce
The runtime does not maintain a pointer to each cell in a dimensioned array.
The cell positions are *calculated* using an initial offset address and then a
formula. No pointers.
Or *one* if you prefer to call the offset address a pointer to the start of the
array.
The moving pointer into a
To continue along these lines, and if you want your code to be compact,
if KEY.LIST were equal to RAISE(KEY.LIST) you could do this:
NEW.LIST =
SELECT KEY.LIST
LOOP WHILE READNEXT UTILITY.ID DO
GOSUB GET.UTILITY.RECORD
IF INDEX(UTILITY.NAME,LAST.NAME,1) THEN NEW.LIST-1 = UTILITY.ID
REPEAT
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
I am getting sucked in!
NLST =;* For new
list
MAXI = DCOUNT(KEY.LIST1,@vM) ;* Count items
FOR INO =1 TO MAXI ;* Each key in list
KEY.ID = KEY.LIST1,INO;* A key ID
38 matches
Mail list logo
