Re: Bizarre %LOOKUP behavior

["M. Lazarus" <mlazarus@xxxxxxxx>]

John,

 You should be able to solve your problem by removing the "ascend" 
keyword from the conv definition.

 A couple of comments on your code:
1) The INZ keyword is unnecessary.

2) The length (70) is also unnecessary.

 -mark

At 8/9/2011 07:05 PM, you wrote:
> "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.