sum([x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0])
sum([x for x in xrange(1, 101) if x % 15 == 0])
Re:Collection Of Puzzles For Programmers
by jgeralnik on Saturday August 18, 2012 @02:18PM
(#4401807)
You're better off making that a generator:
sum((x for x in xrange(1, 101) if x % 3 == 0 and x % 5 == 0))
Notice the parenthesis instead of square brackets. Your version actually creates a list in memory. A generator generates the items one by one and doesn't need to store them all at the same time.
You can just write it as
sum(x for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0)
Re:Collection Of Puzzles For Programmers
by darkestkhan on Sunday August 19, 2012 @03:34AM
(#4403496)
Can't you all think for a bit? All of These solutions are
O (n) in both time and space... there is solution that will take O (1) time and space - and I think that you learned it in math class at (latest) high school (hint: arithmetic progression)
Seriously? The discussion is about language features, not optimal algorithms.
One could imagine the question was actually "sum BusyBeaver(n) for n divisible by 3 and 5 between 1 and 100", i.e. no closed form. In Python:
sum(BusyBeaver(x) for x in xrange(1,101) if x % 3 == 0 and x % 5 == 0)
Re:Collection Of Puzzles For Programmers
by darkestkhan on Sunday August 19, 2012 @03:57AM
(#4403522)
The thing is that people start using those libraries w/o thinking before - and theirs' solutions end up doing much more work than is needed
This could be said of most anything high level.
Re:Collection Of Puzzles For Programmers
by the_cat_kittles on Saturday August 18, 2012 @04:12PM
(#4402168)
true, but xrange(1,101) is so tiny, who cares!
Despite the answers provided by fellow HNers, even if there wasn't a loop-less way to handle the scenario in Python, I assert that taking advantage of a language feature doesn't necessarily equate to "altering your thinking". You may find yourself, though, altering your thinking after defining language features have accumulated to a certain degree.
I agree, the quote is more applicable to conceptually very different languages (e.g. Lisp, Forth, and Smalltalk) than to clever features of particular languages.
Or in javascript..
new Array(100).join(1).split(1)
.map((function() { var i = 0; return function() {return ++i;}})())
.filter(function(x) { return !(x % 15); })
.reduce(function(x, a) { return a += x; }, 0);
As to ruby/python, I only have a superficial knowledge of Python, so please correct me if I'm wrong, but my understanding is that ruby blocks let you do thinks you can't in python. Rspec is one of the examples that gets talked about a lot. But if I were asked to sum all the numbers divisible by both 3 and 5 between 1 and 100 in Ruby, I'd do it like this
In my mind, that is a completely different way of solving the problem than by running a loop. My understanding is that you can't really do something like that conveniently in Python. Though, like I said, I really don't know python, so please do correct me if I have that wrong.