Project Euler 23 implementation
$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 +))
performance clojure
$endgroup$
add a comment |
$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 +))
performance clojure
$endgroup$
add a comment |
$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 +))
performance clojure
$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
performance clojure
edited 12 mins ago
Jamal♦
30.3k11116227
30.3k11116227
asked Nov 5 '18 at 9:33
nakiyanakiya
1266
1266
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$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
$endgroup$
$begingroup$
Thank you for the time and suggestions. Withfilterv
, 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 wholesub-ab
calc and by simply usingabundants
instead orsub-ab
inis-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
add a comment |
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
});
}
});
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%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
$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
$endgroup$
$begingroup$
Thank you for the time and suggestions. Withfilterv
, 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 wholesub-ab
calc and by simply usingabundants
instead orsub-ab
inis-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
add a comment |
$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
$endgroup$
$begingroup$
Thank you for the time and suggestions. Withfilterv
, 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 wholesub-ab
calc and by simply usingabundants
instead orsub-ab
inis-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
add a comment |
$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
$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
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. Withfilterv
, 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 wholesub-ab
calc and by simply usingabundants
instead orsub-ab
inis-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
add a comment |
$begingroup$
Thank you for the time and suggestions. Withfilterv
, 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 wholesub-ab
calc and by simply usingabundants
instead orsub-ab
inis-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
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.
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%2f206966%2fproject-euler-23-implementation%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