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.