Find the combination of matches which are closest to each other
up vote
0
down vote
favorite
Problem - Given three sorted arrays find combinations which are closest to each other.
example -
i/p - 3,8,18 7,11,16 10,15,19
o/p - (8,7,10)
i/p - 2,2,6 11,15,15 8,8,18
o/p - (6,11,8)
Kindly review this scala code and suggest improvements
import scala.math.Ordering._
object NearestMatch {
def main(args: Array[String]) = {
val size = args(0).toInt
val range = args(1).toInt
val (a,b,c) = (Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted)
println(a.mkString(","))
println(b.mkString(","))
println(c.mkString(","))
var (i,j,k) = (0,0,0)
var (pa,pb,pc) = (0,0,0)
var curDiff = 12345 // a very large number
while (i < a.size && j < b.size && k < c.size) {
val min = Math.min(a(i), Math.min(b(j), c(k)))
val max = Math.max(a(i), Math.max(b(j), c(k)))
val newDiff = max-min
if (curDiff > newDiff) {
pa = i
pb = j
pc = k
curDiff = newDiff
}
if (a(i) == min) i+=1
else if (b(j) == min) j+=1
else k+=1
}
println(a(pa), b(pb), c(pc))
}
}
array interview-questions scala combinatorics
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
up vote
0
down vote
favorite
Problem - Given three sorted arrays find combinations which are closest to each other.
example -
i/p - 3,8,18 7,11,16 10,15,19
o/p - (8,7,10)
i/p - 2,2,6 11,15,15 8,8,18
o/p - (6,11,8)
Kindly review this scala code and suggest improvements
import scala.math.Ordering._
object NearestMatch {
def main(args: Array[String]) = {
val size = args(0).toInt
val range = args(1).toInt
val (a,b,c) = (Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted)
println(a.mkString(","))
println(b.mkString(","))
println(c.mkString(","))
var (i,j,k) = (0,0,0)
var (pa,pb,pc) = (0,0,0)
var curDiff = 12345 // a very large number
while (i < a.size && j < b.size && k < c.size) {
val min = Math.min(a(i), Math.min(b(j), c(k)))
val max = Math.max(a(i), Math.max(b(j), c(k)))
val newDiff = max-min
if (curDiff > newDiff) {
pa = i
pb = j
pc = k
curDiff = newDiff
}
if (a(i) == min) i+=1
else if (b(j) == min) j+=1
else k+=1
}
println(a(pa), b(pb), c(pc))
}
}
array interview-questions scala combinatorics
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Problem - Given three sorted arrays find combinations which are closest to each other.
example -
i/p - 3,8,18 7,11,16 10,15,19
o/p - (8,7,10)
i/p - 2,2,6 11,15,15 8,8,18
o/p - (6,11,8)
Kindly review this scala code and suggest improvements
import scala.math.Ordering._
object NearestMatch {
def main(args: Array[String]) = {
val size = args(0).toInt
val range = args(1).toInt
val (a,b,c) = (Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted)
println(a.mkString(","))
println(b.mkString(","))
println(c.mkString(","))
var (i,j,k) = (0,0,0)
var (pa,pb,pc) = (0,0,0)
var curDiff = 12345 // a very large number
while (i < a.size && j < b.size && k < c.size) {
val min = Math.min(a(i), Math.min(b(j), c(k)))
val max = Math.max(a(i), Math.max(b(j), c(k)))
val newDiff = max-min
if (curDiff > newDiff) {
pa = i
pb = j
pc = k
curDiff = newDiff
}
if (a(i) == min) i+=1
else if (b(j) == min) j+=1
else k+=1
}
println(a(pa), b(pb), c(pc))
}
}
array interview-questions scala combinatorics
Problem - Given three sorted arrays find combinations which are closest to each other.
example -
i/p - 3,8,18 7,11,16 10,15,19
o/p - (8,7,10)
i/p - 2,2,6 11,15,15 8,8,18
o/p - (6,11,8)
Kindly review this scala code and suggest improvements
import scala.math.Ordering._
object NearestMatch {
def main(args: Array[String]) = {
val size = args(0).toInt
val range = args(1).toInt
val (a,b,c) = (Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted,
Array.fill(size)(scala.util.Random.nextInt(range)).sorted)
println(a.mkString(","))
println(b.mkString(","))
println(c.mkString(","))
var (i,j,k) = (0,0,0)
var (pa,pb,pc) = (0,0,0)
var curDiff = 12345 // a very large number
while (i < a.size && j < b.size && k < c.size) {
val min = Math.min(a(i), Math.min(b(j), c(k)))
val max = Math.max(a(i), Math.max(b(j), c(k)))
val newDiff = max-min
if (curDiff > newDiff) {
pa = i
pb = j
pc = k
curDiff = newDiff
}
if (a(i) == min) i+=1
else if (b(j) == min) j+=1
else k+=1
}
println(a(pa), b(pb), c(pc))
}
}
array interview-questions scala combinatorics
array interview-questions scala combinatorics
asked Nov 2 at 5:04
vikrant
335
335
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ yesterday
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
A few things I noticed while looking over the code:
- You don't need the
import scala.math.Ordering._
statement. It's not buying you anything. - It would be easier to read/follow the code if you used better variable names.
12345
actually isn't a very bigInt
.Int.MaxValue
would be better.- If this
val size = args(0).toInt
is zero then thisprintln(a(pa), b(pb), c(pc))
will throw. - According to a hint from the IntelliJ IDE,
array.length
is more efficient thanarray.size
because.size
"requires an additional implicit conversion toSeqLike
to be made."
But the real problem is that you're using Scala, a functional language, to write imperative code with many mutable variables, making the code more verbose.
Your algorithm is efficient and limits the number of while
loop iterations, so how to express it in a functional manner: recursion.
def minDif[N:Numeric](x :Seq[N] ,y :Seq[N] ,z :Seq[N]
,curSet :Seq[N] ,curDiff :N) :Unit = {
import Numeric.Implicits._
import Ordering.Implicits._
if (x.isEmpty || y.isEmpty || z.isEmpty)
println(curSet.mkString(",")) //done
else {
val newSet = Seq(x.head, y.head, z.head)
val newMin = newSet.min
val newDiff = newSet.max - newMin
val (nxtSet, nxtDiff) = if (curDiff > newDiff) (newSet, newDiff)
else (curSet, curDiff)
newSet match {
case Seq(`newMin`,_,_) => minDif(x.tail, y, z, nxtSet, nxtDiff)
case Seq(_,`newMin`,_) => minDif(x, y.tail, z, nxtSet, nxtDiff)
case Seq(_,_,`newMin`) => minDif(x, y, z.tail, nxtSet, nxtDiff)
}
}
}
// a b and c have already been populated and sorted
minDif(a, b, c, Seq(), Int.MaxValue)
The minDif()
method is tail recursive so it is compiled to an equivalent while
loop under the hood.
Notice that I used Seq
as the collection type. This allows minDif()
to accept many different types as input: Array
, Stream
, Vector
, etc. Since there is no indexing into any collection there is little advantage in restricting it to just arrays.
Also the element type is Numeric
so this will work with Int
, Float
, Long
, etc.
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
A few things I noticed while looking over the code:
- You don't need the
import scala.math.Ordering._
statement. It's not buying you anything. - It would be easier to read/follow the code if you used better variable names.
12345
actually isn't a very bigInt
.Int.MaxValue
would be better.- If this
val size = args(0).toInt
is zero then thisprintln(a(pa), b(pb), c(pc))
will throw. - According to a hint from the IntelliJ IDE,
array.length
is more efficient thanarray.size
because.size
"requires an additional implicit conversion toSeqLike
to be made."
But the real problem is that you're using Scala, a functional language, to write imperative code with many mutable variables, making the code more verbose.
Your algorithm is efficient and limits the number of while
loop iterations, so how to express it in a functional manner: recursion.
def minDif[N:Numeric](x :Seq[N] ,y :Seq[N] ,z :Seq[N]
,curSet :Seq[N] ,curDiff :N) :Unit = {
import Numeric.Implicits._
import Ordering.Implicits._
if (x.isEmpty || y.isEmpty || z.isEmpty)
println(curSet.mkString(",")) //done
else {
val newSet = Seq(x.head, y.head, z.head)
val newMin = newSet.min
val newDiff = newSet.max - newMin
val (nxtSet, nxtDiff) = if (curDiff > newDiff) (newSet, newDiff)
else (curSet, curDiff)
newSet match {
case Seq(`newMin`,_,_) => minDif(x.tail, y, z, nxtSet, nxtDiff)
case Seq(_,`newMin`,_) => minDif(x, y.tail, z, nxtSet, nxtDiff)
case Seq(_,_,`newMin`) => minDif(x, y, z.tail, nxtSet, nxtDiff)
}
}
}
// a b and c have already been populated and sorted
minDif(a, b, c, Seq(), Int.MaxValue)
The minDif()
method is tail recursive so it is compiled to an equivalent while
loop under the hood.
Notice that I used Seq
as the collection type. This allows minDif()
to accept many different types as input: Array
, Stream
, Vector
, etc. Since there is no indexing into any collection there is little advantage in restricting it to just arrays.
Also the element type is Numeric
so this will work with Int
, Float
, Long
, etc.
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
add a comment |
up vote
0
down vote
A few things I noticed while looking over the code:
- You don't need the
import scala.math.Ordering._
statement. It's not buying you anything. - It would be easier to read/follow the code if you used better variable names.
12345
actually isn't a very bigInt
.Int.MaxValue
would be better.- If this
val size = args(0).toInt
is zero then thisprintln(a(pa), b(pb), c(pc))
will throw. - According to a hint from the IntelliJ IDE,
array.length
is more efficient thanarray.size
because.size
"requires an additional implicit conversion toSeqLike
to be made."
But the real problem is that you're using Scala, a functional language, to write imperative code with many mutable variables, making the code more verbose.
Your algorithm is efficient and limits the number of while
loop iterations, so how to express it in a functional manner: recursion.
def minDif[N:Numeric](x :Seq[N] ,y :Seq[N] ,z :Seq[N]
,curSet :Seq[N] ,curDiff :N) :Unit = {
import Numeric.Implicits._
import Ordering.Implicits._
if (x.isEmpty || y.isEmpty || z.isEmpty)
println(curSet.mkString(",")) //done
else {
val newSet = Seq(x.head, y.head, z.head)
val newMin = newSet.min
val newDiff = newSet.max - newMin
val (nxtSet, nxtDiff) = if (curDiff > newDiff) (newSet, newDiff)
else (curSet, curDiff)
newSet match {
case Seq(`newMin`,_,_) => minDif(x.tail, y, z, nxtSet, nxtDiff)
case Seq(_,`newMin`,_) => minDif(x, y.tail, z, nxtSet, nxtDiff)
case Seq(_,_,`newMin`) => minDif(x, y, z.tail, nxtSet, nxtDiff)
}
}
}
// a b and c have already been populated and sorted
minDif(a, b, c, Seq(), Int.MaxValue)
The minDif()
method is tail recursive so it is compiled to an equivalent while
loop under the hood.
Notice that I used Seq
as the collection type. This allows minDif()
to accept many different types as input: Array
, Stream
, Vector
, etc. Since there is no indexing into any collection there is little advantage in restricting it to just arrays.
Also the element type is Numeric
so this will work with Int
, Float
, Long
, etc.
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
add a comment |
up vote
0
down vote
up vote
0
down vote
A few things I noticed while looking over the code:
- You don't need the
import scala.math.Ordering._
statement. It's not buying you anything. - It would be easier to read/follow the code if you used better variable names.
12345
actually isn't a very bigInt
.Int.MaxValue
would be better.- If this
val size = args(0).toInt
is zero then thisprintln(a(pa), b(pb), c(pc))
will throw. - According to a hint from the IntelliJ IDE,
array.length
is more efficient thanarray.size
because.size
"requires an additional implicit conversion toSeqLike
to be made."
But the real problem is that you're using Scala, a functional language, to write imperative code with many mutable variables, making the code more verbose.
Your algorithm is efficient and limits the number of while
loop iterations, so how to express it in a functional manner: recursion.
def minDif[N:Numeric](x :Seq[N] ,y :Seq[N] ,z :Seq[N]
,curSet :Seq[N] ,curDiff :N) :Unit = {
import Numeric.Implicits._
import Ordering.Implicits._
if (x.isEmpty || y.isEmpty || z.isEmpty)
println(curSet.mkString(",")) //done
else {
val newSet = Seq(x.head, y.head, z.head)
val newMin = newSet.min
val newDiff = newSet.max - newMin
val (nxtSet, nxtDiff) = if (curDiff > newDiff) (newSet, newDiff)
else (curSet, curDiff)
newSet match {
case Seq(`newMin`,_,_) => minDif(x.tail, y, z, nxtSet, nxtDiff)
case Seq(_,`newMin`,_) => minDif(x, y.tail, z, nxtSet, nxtDiff)
case Seq(_,_,`newMin`) => minDif(x, y, z.tail, nxtSet, nxtDiff)
}
}
}
// a b and c have already been populated and sorted
minDif(a, b, c, Seq(), Int.MaxValue)
The minDif()
method is tail recursive so it is compiled to an equivalent while
loop under the hood.
Notice that I used Seq
as the collection type. This allows minDif()
to accept many different types as input: Array
, Stream
, Vector
, etc. Since there is no indexing into any collection there is little advantage in restricting it to just arrays.
Also the element type is Numeric
so this will work with Int
, Float
, Long
, etc.
A few things I noticed while looking over the code:
- You don't need the
import scala.math.Ordering._
statement. It's not buying you anything. - It would be easier to read/follow the code if you used better variable names.
12345
actually isn't a very bigInt
.Int.MaxValue
would be better.- If this
val size = args(0).toInt
is zero then thisprintln(a(pa), b(pb), c(pc))
will throw. - According to a hint from the IntelliJ IDE,
array.length
is more efficient thanarray.size
because.size
"requires an additional implicit conversion toSeqLike
to be made."
But the real problem is that you're using Scala, a functional language, to write imperative code with many mutable variables, making the code more verbose.
Your algorithm is efficient and limits the number of while
loop iterations, so how to express it in a functional manner: recursion.
def minDif[N:Numeric](x :Seq[N] ,y :Seq[N] ,z :Seq[N]
,curSet :Seq[N] ,curDiff :N) :Unit = {
import Numeric.Implicits._
import Ordering.Implicits._
if (x.isEmpty || y.isEmpty || z.isEmpty)
println(curSet.mkString(",")) //done
else {
val newSet = Seq(x.head, y.head, z.head)
val newMin = newSet.min
val newDiff = newSet.max - newMin
val (nxtSet, nxtDiff) = if (curDiff > newDiff) (newSet, newDiff)
else (curSet, curDiff)
newSet match {
case Seq(`newMin`,_,_) => minDif(x.tail, y, z, nxtSet, nxtDiff)
case Seq(_,`newMin`,_) => minDif(x, y.tail, z, nxtSet, nxtDiff)
case Seq(_,_,`newMin`) => minDif(x, y, z.tail, nxtSet, nxtDiff)
}
}
}
// a b and c have already been populated and sorted
minDif(a, b, c, Seq(), Int.MaxValue)
The minDif()
method is tail recursive so it is compiled to an equivalent while
loop under the hood.
Notice that I used Seq
as the collection type. This allows minDif()
to accept many different types as input: Array
, Stream
, Vector
, etc. Since there is no indexing into any collection there is little advantage in restricting it to just arrays.
Also the element type is Numeric
so this will work with Int
, Float
, Long
, etc.
edited Nov 5 at 9:22
answered Nov 3 at 20:23
jwvh
52627
52627
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
add a comment |
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
Your solution is certainly more compact, infact it was first solution I came up with. But it turned out to be very slow for longer arrays (since it is taking all combinations in account) . For list with 1000 elements it coredumps because of exhausted heap.
– vikrant
Nov 4 at 4:21
See the update.
– jwvh
Nov 5 at 9:23
See the update.
– jwvh
Nov 5 at 9:23
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
thanks for comment. this version works, but when I compare performance it is a but expensive. For 10000 number arrays recursive version took 1025771008 ns (nano seconds) while iterative took 9347872 ns. For 50000 numbers difference is more significant (more than two times) recursive 25612533913 ns , iterative 27517216 ns . I do think that my code look like iterative, but if it solves the problem in more efficient way then the functional version, shouldnt we stick to it?
– vikrant
Nov 5 at 19:21
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
@vikrant; Yes, you should stick with your current code if A) efficient throughput is of paramount importance, and B) you are required code in Scala. No other language permitted. You're writing C code in Scala, which says something about Scala's flexibility, but it's not what the language was designed for.
– jwvh
Nov 6 at 0:40
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
yes I have both (A & B) of constraints. I do see that performance is comparable for small arrays, but i need to design it for longer arrays.
– vikrant
Nov 10 at 6:02
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f206775%2ffind-the-combination-of-matches-which-are-closest-to-each-other%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown