Scribd
Upload
54 views3 pages

Binary Search Explanation

The document discusses the intricacies of using BINARY SEARCH when reading data from an internal table in ABAP. The author describes debugging an issue where a record was present in a table but not found using READ TABLE with BINARY SEARCH. Through testing, they determined the table needed to be sorted on the key fields in ascending order for BINARY SEARCH to work properly. While faster for large tables, BINARY SEARCH can produce unexpected results if the table is not sorted correctly on the key fields used.

Uploaded by

EEE
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
54 views3 pages

Binary Search Explanation

The document discusses the intricacies of using BINARY SEARCH when reading data from an internal table in ABAP. The author describes debugging an issue where a record was present in a table but not found using READ TABLE with BINARY SEARCH. Through testing, they determined the table needed to be sorted on the key fields in ascending order for BINARY SEARCH to work properly. While faster for large tables, BINARY SEARCH can produce unexpected results if the table is not sorted correctly on the key fields used.

Uploaded by

EEE
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

The pure and simple truth about BINARY SEARCH

Tuesday, October 10, 2006


The pure and simple truth is rarely pure and never simple.
Oscar Wilde

Last week I got an email from a worried user that some information was missing on a sales
report. After few hours of exhaustive debugging with a few time-outs in between, I realized
that an obscure READ TABLE... command comes back with SY-SUBRC = 4. It was looking for a
combination of material number and customer number in an internal table. Both numbers
were right, leading zeroes and all. I had the whole table in front of me in the debugging
window and the record, which READ was supposed to find, was indeed present in it. “What
do you mean sy-subrc is 4?! Here is that record, right there, you dumbass!”, - almost yelled I
at the poor innocent Dell monitor.

Here I should probably mention that READ TABLE command had BINARY SEARCH addition.
As I’ve learned from my very long programming (not ABAP) experience, sometimes if you
just make things simpler it might actually solve the problem. So I’ve just commented out the
BINARY SEARCH part and ran the program again. Now it worked like a charm. OK, now I had
to get to the bottom of this.

I set up a very simple test program:


DATA: BEGIN OF i_test OCCURS 0,
key1,
key2,
non_key,
END OF i_test.

PERFORM populate_table.

SORT i_test BY key1.


LOOP AT i_test.
WRITE: / i_test-key1, i_test-key2, i_test-non_key.
ENDLOOP.

READ TABLE i_test WITH KEY key1 = 'B' BINARY SEARCH.


IF sy-subrc = 0.
WRITE: / 'Found:'.
WRITE: / i_test-key1, i_test-key2, i_test-non_key.
ELSE.
WRITE: / 'Not found'.
ENDIF.
(I’ve omitted populate_table routine because it just populates i_test with some test data).
Here is the output from the program:
OK, so it found the very first record with B. So far so good. I changed the READ line to add
the second key:
READ TABLE i_test WITH KEY key1 = 'B' key2 = 'Z' BINARY SEARCH.
It did find B Z record. Alright, let’s make the things a bit more interesting:
READ TABLE i_test WITH KEY key2 = 'Z' key1 = 'B' BINARY SEARCH.
Here comes the ‘Not found’ message! However, after I changed SORT from key1 to key2 it
was able to find the B Z record again. Now let’s kick it up a notch. I changed SORT and READ
commands as follows:
SORT i_test BY key1 ASCENDING key2 DESCENDING.
...
READ TABLE i_test WITH KEY key1 = 'B' key2 = 'A' BINARY SEARCH
Here is the content of the i_test table after the sorting so that you guys could follow:
AZC
AZD
AAA
AAB
BZE
BBC
BAA
BAB
CCA
ZBB
ZAA
The results were as follows: the test above (B A) came back with ‘Not found’ (this time
switching key1 and key2 in READ did not help). The things got even curioser when the A A
record was found but Z A was not.

So what’s the deal with this damn binary search? I really like the simple explanation that
one guy gave in an SDN post: ”Let’s say you have numbers 1..to ..100 in a table and you are
searching for 34. It would read the 50th record and if it is say 50 next it would read the 25th
record and if it is say 25 it would carry to read the 38th record and so on.”

Back to my example. There were 11 entries in my test table. The binary search started by
splitting the table in half and it got the middle record (B B C). “OK,” thought the computer.
“Since I’m looking for Z and A, let me look at the second part of the list (because Z > B). Oh,
now I see C C A, we are getting closer! Let’s look at what’s left after that.” Naturally, at this
point the only records to search were only C C A, Z B B and Z A A. So it split the list in half
again and got Z B B. “OMG, I went too far! Let me get back real quick. Hmm... I see C C A. C
is less than Z, which means that there is no record with Z and A. Oh well... SY-SUBRC = 4.
Buhbye!”.

As I finally found out, the problem with the sales report was that the internal table was first
sorted by one field, which would have worked fine with the READ, but then re-sorted by
another field somewhere in the middle. It looks like a good idea to sort the table right
before the binary search, which I will do in the future.

Obviously, with BINARY SEARCH what you see is not always what you get. To get the right
result, the table must be sorted by the right field and in ascending order. If this is not done
properly, sometimes binary search might still work correctly, depending on what data is
inside the table. But sometimes you might wish it didn’t work at all because it could make
finding an error a major pain in the back.

While I was on it, I also ran the runtime analysis a few times. With the small amount of data
in my test program ordinary READ actually worked even faster than READ ... BINARY
SEARCH. However, with thousands of records and about 10 fields (as in my sales report),
BINARY SEARCH performs much better. I’m pretty sure that hashed table would be even
more efficient (unfortunately, it can not be used in that specific report).

http://friendlyabaper.blogspot.com/2006/10/pure-and-simple-truth-about-binary.html

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy