31–40 of 47 posts
It turned out the compiler (clang and I think gcc as well) had converted the branchy version into a lookup table, that ran a tiny bit faster then the lookup table by hand. The assembly looked fairly similar so it was something fairly subtle, but I was out of my depth at that point.
Apparently the Rust compiler produces a slightly different branch-free FizzBuzz[1] involving this delightful snippet: static OUT: &'static [u8] = b"\ 1\n2\nFizz\n4\nBuzz\nFizz\n7\n8\nFizz\nBuzz\n11\nFizz\n13\n14\nFizzBuzz\n\ 16\n17\nFizz\n19\nBuzz\nFizz\n22\n23\nFizz\nBuzz\n26\nFizz\n28\n29\nFizzBuzz\n\ 31\n32\nFizz\n34\nBuzz\nFizz\n37\n38\nFizz\nBuzz\n41\nFizz\n43\n44\nFizzBuzz\n\ 46\n47\nFizz\n49\nBuzz\nFizz\n52\n5…
By my reading that implementation was assembled by humans, not the optimizer. Although, there's certainly nothing magical that prevents the optimizer from generating such code. Here's something[1] I just threw together that (ab)uses constexpr to do just that. On my machine, building with: $ clang++ -std=c++14 fizzbuzz.cpp -O2 -S Gives code similar to: main: # @main .cfi_startproc # BB#0: pushq %rax .Ltmp0: .cfi_def_c…
Random fizzy buzzy observation: Always a little baffled when I see three cases (fizz, buzz, and fizzbuzz) rather than both fizz and buzz handled well such that modulo 15 gets a fizz and a buzz. The normal fizz buzz is divisible by 3 gives a fizz, divisible by 5 gives a buzz. It so happens that 15 is both, so should exhibit both. But as I see it, handling the 15 right should be emergent behavior of a correctly written…
I consider as broken all interviewers who extrapolate a candidate's decision on this issue to real-world "business requirement changes."
"Take 10 minutes to write out code for this simple, abstract, poorly defined problem. Okay, now I'm going to ding you because you didn't write it using the same mindset you'd use when writing a large application tailored towards a specific domain and given a detailed set of constraints."
Maybe we should call this sort of cargo-cultism Schroedinger interviews. If you make your code simple and easily readable in order to solve the problem in the most intelligible way, you get penalized for not making your solution scalable/easily adaptable to "business requirement changes". If you structure your code so that it can easily be extended or modified you get penalized for YAGNI and premature optimization. Of course, exactly what the interviewer is looking for is never actually specified as part of the problem statement, because it exists in a state of quantum superposition until right before the interviewer decides whether or not he or she likes your physical appearance/sense of humor/"cultural fit".
Earlier quoted context omitted.
Oh cool! I always thought of a branch as a conditional jump - I guess I was wrong. It appears that even unconditional branches are still branches! "A branch is an instruction in a computer program that may, when executed by a computer, cause the computer to begin execution of a different instruction sequence. Branch (or branching, branched) may also refer to the act of beginning execution of a different instruction s…
I wouldn't be surprised if there was some place that used "branch" to indicate conditional-only. Assembly language terminology seems to be wonderfully inconsistent. But typical usage these days seems to be as you quoted.
Random fizzy buzzy observation: Always a little baffled when I see three cases (fizz, buzz, and fizzbuzz) rather than both fizz and buzz handled well such that modulo 15 gets a fizz and a buzz. The normal fizz buzz is divisible by 3 gives a fizz, divisible by 5 gives a buzz. It so happens that 15 is both, so should exhibit both. But as I see it, handling the 15 right should be emergent behavior of a correctly written…
for i in fizzbuzz range fizz = i % 3 == 0 buzz = i % 5 == 0 if fizz and buzz print fizzbuzz else if fizz print fizz else if buzz pritn buzz else print i
If you want to see how they react to changing requirements, then ask them to change it. It's stupid to look at someone's answer to a toy problem and treat it like it's production code.
Random fizzy buzzy observation: Always a little baffled when I see three cases (fizz, buzz, and fizzbuzz) rather than both fizz and buzz handled well such that modulo 15 gets a fizz and a buzz. The normal fizz buzz is divisible by 3 gives a fizz, divisible by 5 gives a buzz. It so happens that 15 is both, so should exhibit both. But as I see it, handling the 15 right should be emergent behavior of a correctly written…
It's interesting that you can't imagine code that explicitly prints fizzbuzz with a third conditional. It's as simple as this: for i in fizzbuzz range fizz = i % 3 == 0 buzz = i % 5 == 0 if fizz and buzz print fizzbuzz else if fizz print fizz else if buzz pritn buzz else print i If you want to see how they react to changing requirements, then ask them to change it. It's stupid to look at someone's answer to a toy pro…
There are no toy problems in interviews. The way you approach a toy problem says everything about how you would write production code according to the 'how to hire programmers' manual v 3.3.
Obviously that's not how it should be but if you're going to places where they think 'fizzbuzz' is going to weed out the ones they don't want then you'd better be showing off your capabilities.
Random fizzy buzzy observation: Always a little baffled when I see three cases (fizz, buzz, and fizzbuzz) rather than both fizz and buzz handled well such that modulo 15 gets a fizz and a buzz. The normal fizz buzz is divisible by 3 gives a fizz, divisible by 5 gives a buzz. It so happens that 15 is both, so should exhibit both. But as I see it, handling the 15 right should be emergent behavior of a correctly written…
EDIT: Or SETcc, minus 1, and use it as data mask.
I stopped at 110 bytes .text and 49 bytes .data: http://pastebin.com/bPfrB165
Random fizzy buzzy observation: Always a little baffled when I see three cases (fizz, buzz, and fizzbuzz) rather than both fizz and buzz handled well such that modulo 15 gets a fizz and a buzz. The normal fizz buzz is divisible by 3 gives a fizz, divisible by 5 gives a buzz. It so happens that 15 is both, so should exhibit both. But as I see it, handling the 15 right should be emergent behavior of a correctly written…
Why overthink a toy example? The only purpose served by fizzbuzz is to weed out people who can't write any code.
If you want to know anything else, ask a more relevant technical question. It's downright lazy to simply jump to conclusions, and as a result you end up hiring the wrong person.