Re: Bizarre %LOOKUP behavior

"Shakes my confidence in RPG"?

Ooooooookay...

Anyway, the %LOOKUP BIF uses a binary scan where LOOKUP does not. Jon and Susan wrote about that when V5R1 came out.

As to the number of elements, I have no idea. I would look at my compiler listing and see what size the compiler thinks the arrays are. This works fine on V5R4:

d size c 1500
d ds
d conv 70 dim(size) ascend inz
d oldvalue 35 overlay(conv)
d newvalue 35 overlay(conv:*next)

d x s 5u 0
d x1 s 5u 0
d x2 s 5u 0
d x3 s 5u 0
d x4 s 5u 0

/free
for x = 1 to size;
oldvalue(x) = %editc(x:'X');
newvalue(x) = %char(x);
endfor;

x1 = %lookup('00003': oldvalue);
x2 = %lookup('00750': oldvalue);
x3 = %lookup('00751': oldvalue);
x4 = %lookup('00800': oldvalue);

*inlr = *on;
/end-free

At *INLR, x1 is 3, x2 is 750, x3 is 751 and x4 is 800, just as you would expect.

Joe

Stuff that shakes my confidence in RPG:

I have a data structure which contains an array, with overlaid subfields:

D ds
D conv 70 dim(Size) ascend inz
D oldvalue 35 overlay(conv)
D newvalue 35 overlay(conv:*next)

Size is 1500, but the thing is populated with 794 elements. When I
use %LOOKUP(testvalue:oldvalue), it only returns a nonzero index if
testvalue is one of the first 750 elements in oldvalue.

Then I tried %LOOKUP(testvalue:oldvalue:30), and it returned a nonzero
index only if testvalue is between oldvalue(30) and oldvalue(765),
inclusive. %LOOKUP(testvalue:oldvalue:40) returns nonzero if
testvalue is between oldvalue(40) and oldvalue(770), inclusive. This
pattern continues. It always seems to search only from startindex to
(750 + startindex/2), unless I provide the 4th parameter.

The manual says %LOOKUP searches the entire array when the 4th
parameter is omitted, but that's clearly not happening here. Does
this have something to do with the overlays? I know I have used
simple arrays with more elements and not had this problem.

I'm on V5R2M0, if it matters.

Another finding which surprised (and disappointed) me: The LOOKUP
opcode doesn't seem to make use of sorting. Judging by simple
timings, it always seems to look at every single element of a sorted
array, no matter what indicators I give it. (In contrast, the %LOOKUP
function is much, much faster on a sorted array, as one would expect.)
Yeah, as if we needed any more reasons to avoid using the opcode.

John Y.