AFAIK, %lookup() does a linear search.
I assume you mean a binary search for the %lookupXX() functions *only*.
From the RPGLE Reference: "Since a binary search is used by the %LOOKUPxx built-in functions..."
Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, May 2, 2019 2:24 PM
To: RPG programming on IBM i
Subject: RE: Looking for free format equivalent
Thanks for the warning... I read that on IBM's site.
The interface that populates this string ensures that
1. It is completely filled out with dates
2. They are actual dates
3. They are ascending
This is a file that controls the operation of our Accounting System.
So unless I have data corruption - I should be good. The index of the array corresponds to beginning date of the fiscal period.
I'll file this piece of information for future use.
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of John Yeung
Sent: Thursday, May 02, 2019 4:43 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Looking for free format equivalent
On Thu, May 2, 2019 at 3:51 PM Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
My problem was twofold
1. I was using SQL to retrieve the string - you can't do that
directly into RA0094 2. The array needs ASCEND or DESCEND to use
%lookuple
Since you said you're converting from the old LOOKUP opcode, you should be aware of another difference between it and the BIFs: The opcode searches sequentially; the BIFs use binary search. Which means you have to make sure of two things when using the BIFs: First, the data needs to ACTUALLY be sorted (not just *declared* sorted). Second, which is actually just a stricter expression of the first, if your array isn't "full" then you have to be sure to specify the "startindex" and "numelems" parameters when you do the lookup, or you have to fill any trailing array elements with *HIVAL beforehand. Or just sort the whole array with SORTA.
This has bitten me more than once. One common efficient-seeming pattern for building an array is by reading in sorted values. Figuring that the data going in is already sorted, there's no need to use SORTA afterwards; that would just be redundant. But it wouldn't, if you don't have enough values to fill the array. You can get away with this bit of sloppiness with the opcode, because it searches sequentially.
But binary search will be screwed up by this. (If you take the time to work out why this is, with pencil and paper if necessary, you will etch it into your brain and be much less likely to be caught out by
this.)
John Y.
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
