Live data from Hacker News

Branch-free FizzBuzz in Assembly

pepijndevos.nl

41–47 of 47 posts

Re: Branch-free FizzBuzz in Assembly

#41

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…

Here I have an explicit "FizzBuzz" but only 2 checks. Do you consider this also broken?

   python3 -c '
     for i in range(1,20):
       print([i,"Fizz","Buzz","FizzBuzz"][int(i%3==0) + 2*int(i%5==0)])'

Re: Branch-free FizzBuzz in Assembly

#42

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…

Well, I'm always a little baffled when I see such great techniques for rejecting potentially awesome candidates. 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.

To be clear, I'm not referring to candidates. I'm referring to the questioners/interviewers suggesting this approach.

Re: Branch-free FizzBuzz in Assembly

#43
post #37

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 don't think you know what the word 'broken' means. You sound like the type of person that would make code as terse as possible with all kinds of traps for future maintainers.

Fizz on /3, Buzz on /5, is the actual requirement. Shortcutting /3 & /5 with a hard coded /15 that has to be edited if /3 or /5 changes, that's the trap.

Re: Branch-free FizzBuzz in Assembly

#44

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…

>But what if the business requirement changes...

Are you kidding? This is FizzBuzz! It is just a quick check to verify that an applicant is even a programmer at all. That's all it is. There is nothing else there.

Re: Branch-free FizzBuzz in Assembly

#45

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…

You assumption that a separate case that prints fizzbuzz will break the code is not correct. With correct code, you get three if checks either way, but the readability is higher, code complexity is lower and cases are nicely separated. bool is3 = i%3 == 0 ; bool is5 = i%5 == 0 ; if( is3 && is5 ) { printf("fizzbuzz\n") ; } else if( is3 ) { printf("fizz\n") ; } else if( is5 ) { printf("buzz\n") ; } else { printf("%d\n"…

And what if there's a is7 woof criteria as well? You going to add another set of special cases for fizzwoof, buzzwoof, and fizzbuzzwoof?

You see the problem, versus just doing fizz, buzz, and woof distinctly?

Re: Branch-free FizzBuzz in Assembly

#46
post #44

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…

>But what if the business requirement changes... Are you kidding? This is FizzBuzz! It is just a quick check to verify that an applicant is even a programmer at all. That's all it is. There is nothing else there.

Depends on how the task is communicated and what's implied.

Also recognize that there are excellent programmers who take to heart Dijkstra's dictum to "Always design your programs as a member of a whole family of programs, including those that are likely to succeed it."

Has AmaTwitBookGooSoft ever asked for a generalization of FizzBuzz? I wouldn't put it pass them.

Re: Branch-free FizzBuzz in Assembly

#47

Earlier quoted context omitted.

You assumption that a separate case that prints fizzbuzz will break the code is not correct. With correct code, you get three if checks either way, but the readability is higher, code complexity is lower and cases are nicely separated. bool is3 = i%3 == 0 ; bool is5 = i%5 == 0 ; if( is3 && is5 ) { printf("fizzbuzz\n") ; } else if( is3 ) { printf("fizz\n") ; } else if( is5 ) { printf("buzz\n") ; } else { printf("%d\n"…

And what if there's a is7 woof criteria as well? You going to add another set of special cases for fizzwoof, buzzwoof, and fizzbuzzwoof? You see the problem, versus just doing fizz, buzz, and woof distinctly?

It is not logical to subvert your code to adhere to some imaginary future requirements.
Post reply on HN