Project Euler 23 implementation












0












$begingroup$


This code to solve Problem 23 in Project Euler gives the correct answer. But, running the last expression takes around 40 seconds. I welcome advice on how to improve performance here.



(defn sum-div [num]
(->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
(filter #(= (mod num %) 0))
(map (fn [x]
(let [d (/ num x)]
(if (= x d)
x
[x d]))))
flatten
distinct
(reduce +)
(+ 1)))

(def abundants
(->> (range 12 28123)
(map #(vector % (sum-div %)))
(filter #(> (second %) (first %)))
(map first)
set))

(defn is-sum-of-two-abundants?
[num]
(let [sub-ab (->> abundants
(filter #(< % num))
set)]
(some (fn [ab]
(sub-ab (- num ab)))
sub-ab)))

(->> (range 28124)
(filter (complement is-sum-of-two-abundants?))
(reduce +))









share|improve this question











$endgroup$

















    0












    $begingroup$


    This code to solve Problem 23 in Project Euler gives the correct answer. But, running the last expression takes around 40 seconds. I welcome advice on how to improve performance here.



    (defn sum-div [num]
    (->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
    (filter #(= (mod num %) 0))
    (map (fn [x]
    (let [d (/ num x)]
    (if (= x d)
    x
    [x d]))))
    flatten
    distinct
    (reduce +)
    (+ 1)))

    (def abundants
    (->> (range 12 28123)
    (map #(vector % (sum-div %)))
    (filter #(> (second %) (first %)))
    (map first)
    set))

    (defn is-sum-of-two-abundants?
    [num]
    (let [sub-ab (->> abundants
    (filter #(< % num))
    set)]
    (some (fn [ab]
    (sub-ab (- num ab)))
    sub-ab)))

    (->> (range 28124)
    (filter (complement is-sum-of-two-abundants?))
    (reduce +))









    share|improve this question











    $endgroup$















      0












      0








      0


      0



      $begingroup$


      This code to solve Problem 23 in Project Euler gives the correct answer. But, running the last expression takes around 40 seconds. I welcome advice on how to improve performance here.



      (defn sum-div [num]
      (->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
      (filter #(= (mod num %) 0))
      (map (fn [x]
      (let [d (/ num x)]
      (if (= x d)
      x
      [x d]))))
      flatten
      distinct
      (reduce +)
      (+ 1)))

      (def abundants
      (->> (range 12 28123)
      (map #(vector % (sum-div %)))
      (filter #(> (second %) (first %)))
      (map first)
      set))

      (defn is-sum-of-two-abundants?
      [num]
      (let [sub-ab (->> abundants
      (filter #(< % num))
      set)]
      (some (fn [ab]
      (sub-ab (- num ab)))
      sub-ab)))

      (->> (range 28124)
      (filter (complement is-sum-of-two-abundants?))
      (reduce +))









      share|improve this question











      $endgroup$




      This code to solve Problem 23 in Project Euler gives the correct answer. But, running the last expression takes around 40 seconds. I welcome advice on how to improve performance here.



      (defn sum-div [num]
      (->> (range 2 (+ 1 (int (Math/ceil (Math/sqrt num)))))
      (filter #(= (mod num %) 0))
      (map (fn [x]
      (let [d (/ num x)]
      (if (= x d)
      x
      [x d]))))
      flatten
      distinct
      (reduce +)
      (+ 1)))

      (def abundants
      (->> (range 12 28123)
      (map #(vector % (sum-div %)))
      (filter #(> (second %) (first %)))
      (map first)
      set))

      (defn is-sum-of-two-abundants?
      [num]
      (let [sub-ab (->> abundants
      (filter #(< % num))
      set)]
      (some (fn [ab]
      (sub-ab (- num ab)))
      sub-ab)))

      (->> (range 28124)
      (filter (complement is-sum-of-two-abundants?))
      (reduce +))






      performance clojure






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 12 mins ago









      Jamal

      30.3k11116227




      30.3k11116227










      asked Nov 5 '18 at 9:33









      nakiyanakiya

      1266




      1266






















          1 Answer
          1






          active

          oldest

          votes


















          1












          $begingroup$

          I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



          As a last ditch effort though, I changed



          (->> abundants
          (filter #(< % num))
          set)


          to



          (->> abundants
          (filterv #(< % num)) ; Note the v
          set)


          And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



          Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





          I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



          (def lower-limit 12) ; Defining these so they aren't magic,
          (def upper-limit 28123) ; especially since upper-limit is used in two places

          (defn sum-div [num]
          (->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
          (filter #(= (mod num %) 0))
          (map (fn [x]
          (let [d (/ num x)]
          (if (= x d)
          x
          [x d]))))
          (flatten) ; I personally prefer wrapping for consistency
          (distinct)
          (apply +) ; apply is generally regarded as more idiomatic for summing
          (inc))) ; Use inc instead of (+ 1)

          (def abundants
          (->> (range lower-limit upper-limit)
          (map #(vector % (sum-div %)))
          (filter #(> (second %) (first %)))
          (map first)
          (set)))

          (defn is-sum-of-two-abundants?
          [num]
          (let [sub-ab (->> abundants
          (filterv #(< % num))
          (set))]
          (some (fn [ab]
          (sub-ab (- num ab)))
          sub-ab)))

          (time
          (->> (range (inc upper-limit)) ; Use upper limit
          (remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
          (apply +)))

          "Elapsed time: 26714.867469 msecs"
          => 4179871





          share|improve this answer











          $endgroup$













          • $begingroup$
            Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
            $endgroup$
            – nakiya
            Nov 7 '18 at 2:39






          • 1




            $begingroup$
            @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 2:44










          • $begingroup$
            I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
            $endgroup$
            – nakiya
            Nov 7 '18 at 3:13










          • $begingroup$
            @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 3:19













          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',
          autoActivateHeartbeat: false,
          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%2f206966%2fproject-euler-23-implementation%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









          1












          $begingroup$

          I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



          As a last ditch effort though, I changed



          (->> abundants
          (filter #(< % num))
          set)


          to



          (->> abundants
          (filterv #(< % num)) ; Note the v
          set)


          And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



          Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





          I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



          (def lower-limit 12) ; Defining these so they aren't magic,
          (def upper-limit 28123) ; especially since upper-limit is used in two places

          (defn sum-div [num]
          (->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
          (filter #(= (mod num %) 0))
          (map (fn [x]
          (let [d (/ num x)]
          (if (= x d)
          x
          [x d]))))
          (flatten) ; I personally prefer wrapping for consistency
          (distinct)
          (apply +) ; apply is generally regarded as more idiomatic for summing
          (inc))) ; Use inc instead of (+ 1)

          (def abundants
          (->> (range lower-limit upper-limit)
          (map #(vector % (sum-div %)))
          (filter #(> (second %) (first %)))
          (map first)
          (set)))

          (defn is-sum-of-two-abundants?
          [num]
          (let [sub-ab (->> abundants
          (filterv #(< % num))
          (set))]
          (some (fn [ab]
          (sub-ab (- num ab)))
          sub-ab)))

          (time
          (->> (range (inc upper-limit)) ; Use upper limit
          (remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
          (apply +)))

          "Elapsed time: 26714.867469 msecs"
          => 4179871





          share|improve this answer











          $endgroup$













          • $begingroup$
            Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
            $endgroup$
            – nakiya
            Nov 7 '18 at 2:39






          • 1




            $begingroup$
            @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 2:44










          • $begingroup$
            I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
            $endgroup$
            – nakiya
            Nov 7 '18 at 3:13










          • $begingroup$
            @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 3:19


















          1












          $begingroup$

          I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



          As a last ditch effort though, I changed



          (->> abundants
          (filter #(< % num))
          set)


          to



          (->> abundants
          (filterv #(< % num)) ; Note the v
          set)


          And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



          Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





          I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



          (def lower-limit 12) ; Defining these so they aren't magic,
          (def upper-limit 28123) ; especially since upper-limit is used in two places

          (defn sum-div [num]
          (->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
          (filter #(= (mod num %) 0))
          (map (fn [x]
          (let [d (/ num x)]
          (if (= x d)
          x
          [x d]))))
          (flatten) ; I personally prefer wrapping for consistency
          (distinct)
          (apply +) ; apply is generally regarded as more idiomatic for summing
          (inc))) ; Use inc instead of (+ 1)

          (def abundants
          (->> (range lower-limit upper-limit)
          (map #(vector % (sum-div %)))
          (filter #(> (second %) (first %)))
          (map first)
          (set)))

          (defn is-sum-of-two-abundants?
          [num]
          (let [sub-ab (->> abundants
          (filterv #(< % num))
          (set))]
          (some (fn [ab]
          (sub-ab (- num ab)))
          sub-ab)))

          (time
          (->> (range (inc upper-limit)) ; Use upper limit
          (remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
          (apply +)))

          "Elapsed time: 26714.867469 msecs"
          => 4179871





          share|improve this answer











          $endgroup$













          • $begingroup$
            Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
            $endgroup$
            – nakiya
            Nov 7 '18 at 2:39






          • 1




            $begingroup$
            @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 2:44










          • $begingroup$
            I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
            $endgroup$
            – nakiya
            Nov 7 '18 at 3:13










          • $begingroup$
            @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 3:19
















          1












          1








          1





          $begingroup$

          I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



          As a last ditch effort though, I changed



          (->> abundants
          (filter #(< % num))
          set)


          to



          (->> abundants
          (filterv #(< % num)) ; Note the v
          set)


          And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



          Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





          I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



          (def lower-limit 12) ; Defining these so they aren't magic,
          (def upper-limit 28123) ; especially since upper-limit is used in two places

          (defn sum-div [num]
          (->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
          (filter #(= (mod num %) 0))
          (map (fn [x]
          (let [d (/ num x)]
          (if (= x d)
          x
          [x d]))))
          (flatten) ; I personally prefer wrapping for consistency
          (distinct)
          (apply +) ; apply is generally regarded as more idiomatic for summing
          (inc))) ; Use inc instead of (+ 1)

          (def abundants
          (->> (range lower-limit upper-limit)
          (map #(vector % (sum-div %)))
          (filter #(> (second %) (first %)))
          (map first)
          (set)))

          (defn is-sum-of-two-abundants?
          [num]
          (let [sub-ab (->> abundants
          (filterv #(< % num))
          (set))]
          (some (fn [ab]
          (sub-ab (- num ab)))
          sub-ab)))

          (time
          (->> (range (inc upper-limit)) ; Use upper limit
          (remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
          (apply +)))

          "Elapsed time: 26714.867469 msecs"
          => 4179871





          share|improve this answer











          $endgroup$



          I played around with this for a good half hour without any luck. I was consistently getting ~57 seconds on my crappy M3 laptop.



          As a last ditch effort though, I changed



          (->> abundants
          (filter #(< % num))
          set)


          to



          (->> abundants
          (filterv #(< % num)) ; Note the v
          set)


          And got it down to 25 seconds! Since you seem to be using a faster computer than me, you'll likely get an even lower time.



          Why does this cause such a dramatic change? ¯_(ツ)_/¯. filterv is strict while filter is lazy, but I have no idea why that makes such a difference here. I would have expected it to be slower since the strict filtering would require a full iteration on its own, then the adding to the set would require another full iteration. Apparently something else is going on. I'll update this answer if I think of what may be happening.





          I cleaned up the code a bit too, although none of the other changes made any performance impact. These are mostly just personal stylistic and practice recommendations. See the comments:



          (def lower-limit 12) ; Defining these so they aren't magic,
          (def upper-limit 28123) ; especially since upper-limit is used in two places

          (defn sum-div [num]
          (->> (range 2 (inc (int (Math/ceil (Math/sqrt num)))))
          (filter #(= (mod num %) 0))
          (map (fn [x]
          (let [d (/ num x)]
          (if (= x d)
          x
          [x d]))))
          (flatten) ; I personally prefer wrapping for consistency
          (distinct)
          (apply +) ; apply is generally regarded as more idiomatic for summing
          (inc))) ; Use inc instead of (+ 1)

          (def abundants
          (->> (range lower-limit upper-limit)
          (map #(vector % (sum-div %)))
          (filter #(> (second %) (first %)))
          (map first)
          (set)))

          (defn is-sum-of-two-abundants?
          [num]
          (let [sub-ab (->> abundants
          (filterv #(< % num))
          (set))]
          (some (fn [ab]
          (sub-ab (- num ab)))
          sub-ab)))

          (time
          (->> (range (inc upper-limit)) ; Use upper limit
          (remove is-sum-of-two-abundants?) ; remove is literally equal to (filter (complement ...))
          (apply +)))

          "Elapsed time: 26714.867469 msecs"
          => 4179871






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 5 '18 at 15:41

























          answered Nov 5 '18 at 15:23









          CarcigenicateCarcigenicate

          2,86011229




          2,86011229












          • $begingroup$
            Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
            $endgroup$
            – nakiya
            Nov 7 '18 at 2:39






          • 1




            $begingroup$
            @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 2:44










          • $begingroup$
            I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
            $endgroup$
            – nakiya
            Nov 7 '18 at 3:13










          • $begingroup$
            @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 3:19




















          • $begingroup$
            Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
            $endgroup$
            – nakiya
            Nov 7 '18 at 2:39






          • 1




            $begingroup$
            @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 2:44










          • $begingroup$
            I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
            $endgroup$
            – nakiya
            Nov 7 '18 at 3:13










          • $begingroup$
            @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
            $endgroup$
            – Carcigenicate
            Nov 7 '18 at 3:19


















          $begingroup$
          Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
          $endgroup$
          – nakiya
          Nov 7 '18 at 2:39




          $begingroup$
          Thank you for the time and suggestions. With filterv, my running time comes down to 17 seconds. Great find! If I wanted to figure out what's the reason for the difference between the two versions, how should I go about it?
          $endgroup$
          – nakiya
          Nov 7 '18 at 2:39




          1




          1




          $begingroup$
          @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
          $endgroup$
          – Carcigenicate
          Nov 7 '18 at 2:44




          $begingroup$
          @nakiya Profile it and see where the time is being spent, what's using memory, and what the GC is doing. filter might be using more memory, which is causing the GC to run too often. VisualVM comes with the JDK, and is available for free from the Java site. It's not perfect, but it's been pretty helpful for me.
          $endgroup$
          – Carcigenicate
          Nov 7 '18 at 2:44












          $begingroup$
          I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
          $endgroup$
          – nakiya
          Nov 7 '18 at 3:13




          $begingroup$
          I found that by removing the whole sub-ab calc and by simply using abundants instead or sub-ab in is-sum-of-two-abundants?, I can reduce running time to 2 seconds. i.e (defn is-sum-of-two-abundants? [num] (some (fn [ab] (abundants (- num ab))) abundants))
          $endgroup$
          – nakiya
          Nov 7 '18 at 3:13












          $begingroup$
          @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
          $endgroup$
          – Carcigenicate
          Nov 7 '18 at 3:19






          $begingroup$
          @nakiya That's because that gets rid of all the end filtering. Was (filterv #(< % num)) never necessary in the first place? I honestly didn't look into the algorithm itself in too much detail.
          $endgroup$
          – Carcigenicate
          Nov 7 '18 at 3:19




















          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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f206966%2fproject-euler-23-implementation%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

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          TypeError: fit_transform() missing 1 required positional argument: 'X'