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))
}
}









share|improve this question














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.



















    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))
    }
    }









    share|improve this question














    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.

















      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))
      }
      }









      share|improve this question













      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      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.
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          A few things I noticed while looking over the code:




          1. You don't need the import scala.math.Ordering._ statement. It's not buying you anything.

          2. It would be easier to read/follow the code if you used better variable names.


          3. 12345 actually isn't a very big Int. Int.MaxValue would be better.

          4. If this val size = args(0).toInt is zero then this println(a(pa), b(pb), c(pc)) will throw.

          5. According to a hint from the IntelliJ IDE, array.length is more efficient than array.size because .size "requires an additional implicit conversion to SeqLike 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.






          share|improve this answer























          • 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 Answer





          StackExchange.ifUsing("editor", function () {
          return StackExchange.using("mathjaxEditing", function () {
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          });
          });
          }, "mathjax-editing");

          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "196"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          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

























          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:




          1. You don't need the import scala.math.Ordering._ statement. It's not buying you anything.

          2. It would be easier to read/follow the code if you used better variable names.


          3. 12345 actually isn't a very big Int. Int.MaxValue would be better.

          4. If this val size = args(0).toInt is zero then this println(a(pa), b(pb), c(pc)) will throw.

          5. According to a hint from the IntelliJ IDE, array.length is more efficient than array.size because .size "requires an additional implicit conversion to SeqLike 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.






          share|improve this answer























          • 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















          up vote
          0
          down vote













          A few things I noticed while looking over the code:




          1. You don't need the import scala.math.Ordering._ statement. It's not buying you anything.

          2. It would be easier to read/follow the code if you used better variable names.


          3. 12345 actually isn't a very big Int. Int.MaxValue would be better.

          4. If this val size = args(0).toInt is zero then this println(a(pa), b(pb), c(pc)) will throw.

          5. According to a hint from the IntelliJ IDE, array.length is more efficient than array.size because .size "requires an additional implicit conversion to SeqLike 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.






          share|improve this answer























          • 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













          up vote
          0
          down vote










          up vote
          0
          down vote









          A few things I noticed while looking over the code:




          1. You don't need the import scala.math.Ordering._ statement. It's not buying you anything.

          2. It would be easier to read/follow the code if you used better variable names.


          3. 12345 actually isn't a very big Int. Int.MaxValue would be better.

          4. If this val size = args(0).toInt is zero then this println(a(pa), b(pb), c(pc)) will throw.

          5. According to a hint from the IntelliJ IDE, array.length is more efficient than array.size because .size "requires an additional implicit conversion to SeqLike 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.






          share|improve this answer














          A few things I noticed while looking over the code:




          1. You don't need the import scala.math.Ordering._ statement. It's not buying you anything.

          2. It would be easier to read/follow the code if you used better variable names.


          3. 12345 actually isn't a very big Int. Int.MaxValue would be better.

          4. If this val size = args(0).toInt is zero then this println(a(pa), b(pb), c(pc)) will throw.

          5. According to a hint from the IntelliJ IDE, array.length is more efficient than array.size because .size "requires an additional implicit conversion to SeqLike 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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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


















          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Ellipse (mathématiques)

          Quarter-circle Tiles

          Mont Emei