How to Install and Uninstall perl-List-BinarySearch-XS Package on openSuSE Tumbleweed

Last updated: October 31,2024

1. Install "perl-List-BinarySearch-XS" package

In this section, we are going to explain the necessary steps to install perl-List-BinarySearch-XS on openSuSE Tumbleweed

$ sudo zypper refresh $ sudo zypper install perl-List-BinarySearch-XS

2. Uninstall "perl-List-BinarySearch-XS" package

In this section, we are going to explain the necessary steps to uninstall perl-List-BinarySearch-XS on openSuSE Tumbleweed:

$ sudo zypper remove perl-List-BinarySearch-XS

3. Information about the perl-List-BinarySearch-XS package on openSuSE Tumbleweed

Information for package perl-List-BinarySearch-XS:
--------------------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : perl-List-BinarySearch-XS
Version : 0.09-1.20
Arch : x86_64
Vendor : openSUSE
Installed Size : 41.7 KiB
Installed : No
Status : not installed
Source package : perl-List-BinarySearch-XS-0.09-1.20.src
Upstream URL : https://metacpan.org/release/List-BinarySearch-XS
Summary : Binary Search a sorted array with XS routines.
Description :
A binary search searches _sorted_ lists using a divide and conquer
technique. On each iteration the search domain is cut in half, until the
result is found. The computational complexity of a binary search is O(log
n).
This module implements several Binary Search algorithms using XS code for
optimal performance. You are free to use this module directly, or as a
plugin for the more general List::BinarySearch.
The binary search algorithm implemented in this module is known as a
_Deferred Detection_ Binary Search. Deferred Detection provides *stable
searches*. Stable binary search algorithms have the following
characteristics, contrasted with their unstable binary search cousins:
* * In the case of non-unique keys, a stable binary search will always
return the lowest-indexed matching element. An unstable binary search
would
return the first one found, which may not be the chronological first.
* * Best and worst case time complexity is always O(log n). Unstable
searches may stop once the target is found, but in the worst case are
still
O(log n). In practical terms, this difference is usually not meaningful.
* * Stable binary searches only require one relational comparison of a
given pair of data elements per iteration, where unstable binary searches
require two comparisons per iteration.
* * The net result is that although an unstable binary search might have
better "best case" performance, the fact that a stable binary search gets
away
with fewer comparisons per iteration gives it better performance in the
worst
case, and approximately equal performance in the average case. By trading
away
slightly better "best case" performance, the stable search gains the
guarantee
that the element found will always be the lowest-indexed element in a
range of
non-unique keys.