Talk:Interpolation search

message: The use of Big-O notation is confused in the Performance section. Given arbitrary input, this search algorithm is O(n). Given uniformly distributed data, then the algorithm is O(log(log(n))). The text the Performance section does not make this clear - it flatly states the performance is O(log(log(n))) without qualifying the assumptions on the input. 96.240.164.36 (talk) 22:25, 27 June 2010 (UTC)
replies: text: Agreed. The doubly logarithmic running time is on uniformly distributed data (or the average-case running time for random data from a uniform distribution). The current statement is simply not correct. Mlhetland (talk) 22:24, 12 July 2010 (UTC)
thread_title:  Big-O 

message: I've seen this algorithm in Knuth's book (Volume 3). I don't have it around, but maybe somebody can add a reference to it.  —Preceding unsigned comment added by 82.139.116.86 (talk) 17:19, 18 October 2009 (UTC)
replies: text: Volume 3 pp419-420, the last part of section 6.2.1 "Searching an Ordered Table", however it is a discussion only: "When we know that K lies between Kl and Ku we can choose the next probe to be about (K - Kl)/(Ku - Kl) of the way between l and u, assuming that the keys are numeric and that they increase in a roughly constant manner throughout the interval." There is no presentation of the steps of an actual algorithm (in MIX or not), nor discussion of the details that would for example prevent entering in to an attempt at interpolation when Ku = Kl, the assumption of the start of the step's description.NickyMcLean (talk) 20:29, 18 October 2009 (UTC)
thread_title:  Citation 

message: implementation seems to be defective.
it crashes with an exception!
----
No, it doesn't... What exceptions are you getting and what parameters do you use??
int[] a={1,2,3,4,5,6,7,13,43,65, 87,111,134,153,413,654,764,875,987};
System.out.println(interpolationSearch(a,8));  // Prints correctly -1
System.out.println(interpolationSearch(a,153)); // Prints correct 13
System.out.println(interpolationSearch(a,999)); // Prints correct -1
--Dodno 08:00, 19 November 2006 (UTC)
replies: text: The anon might've run into a signed integer overflow in (toFind - sortedArray[low]) * (high - low). --Mrwojo (talk) 04:27, 30 March 2008 (UTC)
thread_title:  Error 

message: There is a long-standing bug. The method is based upon the Binary Search method, unfortunately using the inferior "inclusive bounds" variant, thus the fiddling with mid - 1 or mid + 1. In January 2010 I presented a version based upon the "exclusive bounds" form, but, lacking any text to refer to, this was ejected as "Original Research". The code as presented also offers no reference, but has been allowed to stand.
The bug is simple, and simply found, and has been present all along. Simply consider a sorted array with two values only, both equal, and the searched-for value being that value also. Say that value is 6. The test of the while statement becomes 6 <= 6 & 6 >= 6, which is true, so the interpolation is attempted, so there is a division by (6 - 6), which is zero, and thus a divide-by-zero fault. This is the error I alluded to under the heading "Brisk", below. NickyMcLean (talk) 10:36, 17 September 2014 (UTC)
thread_title: It ''is'' erroneous

message: The algorithm in its current form is broken, as the "mid" variable sometimes assumes a negative index, causing Java to throw an IndexOutOfBoundsException:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -7374
	at TestMain.interpolationSearch2(TestMain.java:45)
	at TestMain.main(TestMain.java:72)
Line 45 being:
	       if (sortedArray[mid] < toFind)
               
Which is immediately preceded by:
               mid = low + ((toFind - sortedArray[low]) * (high - low)) / (sortedArray[high] - sortedArray[low]);
		 
I'd say this article is in need of an expert on the subject, or atleast, someone with a working implementation of the Interpolation search algorithm. 
Edit: Link to full code here http://dl.dropbox.com/u/6471787/TestMain.java
 —Preceding unsigned comment added by 217.76.87.120 (talk) 18:27, 20 January 2011 (UTC)
thread_title:  Implementation still broken 

message: Is higher order interpolation possible ? Frigo 12:58, 4 January 2007 (UTC)
thread_title:  Higher order 

message: The Java code is littered with multiple comparisons: there are five comparisons against X! Is this really necessary? Especially the addendum to check for the case X = A[L]? A recast would seem in order. Compare with the non-C pseudocode in the binary search discussion page. And for the benefit of non-Java readers, just what are the bounds of the array? That is, if there are N elements, are they indexed as 1:N, or 0:N - 1, or what? Using A.length merely adds to the confusion.
Meanwhile, I've re-ordered the calculation to make more clear the comparison with a binary chop.
 public int interpolationSearch(int[] A, int X){
  // Returns the index of X in the sorted array A, or -1 if not found
  int L = 0;               //Low bound.
  int R = A.length - 1;    //High bound.
  int P;                   //Probe position.
  while (A[L] < X && A[R] >= X) {
   P = L + (R - L)*(X - A[L])/(A[R] - A[L]);  //Interpolate on the difference X - A[L]
 //P = L + (R - L)/2       //Binary chop position.
   if (A[P] < X)
    L = P + 1;
   else if (A[P] > X)      //Repetition of the comparison code is forced by syntax limitations.
    R = P - 1;
   else
    return P;
  } 
  if (A[L] == X)
   return L;
  else
   return -1; // Not found
 }
NickyMcLean 20:10, 18 February 2007 (UTC)
thread_title: Endless repetition

message: I think the statement on the page that "In reality, an interpolation search is often no faster..." needs either a recent citation, or should be removed.  The costs of branch-cuts and cache-misses in modern architectures should dominate computation of probe location in most cases. —The preceding unsigned comment was added by 18.157.7.102 (talk) 03:48, 24 February 2007 (UTC)
thread_title:  Complexity of arithmetic? 

message: :"Humans have a rough idea of the distribution of surnames in an alphabetical listing, and can guess that "Baker" is closer to "Abadeeah" than it is to "Zyteca" and interpolate accordingly. In the absence of information about the popularity of surnames, computer representations of text strings do not facilitate such arithmetic."
This is effectively stating that it requires knowledge of the distribution of surnames through the alphabet just to make use of the fact that B is nearer to A in the alphabet than it is to Z.  What nonsense.  How best can we rewrite this to make sense? -- Smjg (talk) 08:08, 3 July 2009 (UTC)
thread_title:  Dubious 

message: So impressive to see that Oli Filth has demonstrated high-level status in removed a pile of stuff lacking attribution to approved sources. So much easier than making an effort along the lines of finding suitable sources. And as for the surviving "java" implementation, it remains unsourced, as well it might since it contains a bug, not that approved sources are always bug-free.  NickyMcLean (talk) 03:58, 5 June 2010 (UTC)
replies: text: I've answered your post at my talk page.  As for the Java snippet, if you know there to be a bug, why have you not addressed the problem?  And yes, we should find a source.  Oli Filth(talk|contribs) 09:11, 5 June 2010 (UTC)

text: I meant "address" as in "correct it"!  Oli Filth(talk|contribs) 22:22, 7 June 2010 (UTC)
thread_title: Brisk

message: Example implementation on page 2: http://www.cs.cmu.edu/~adityaa/211/Lecture7AGPrint.pdf
AlecTaylor (talk) 14:34, 19 May 2012 (UTC)
thread_title: Three way comparisons are possible in Java