FizzBuzz (#126)

Great quiz, really got me thinking about other ways to solve this
simple problem, but I settled on this clear and easy method.
Anyway, here we go:

====CODE BEGIN====

#!/usr/bin/ruby -w
###########################

Filename: fizzbuzz.rb

Author: Christian R.

Date: 2007-06-01

###########################

Ruby Q. - FizzBuzz (#126)

This program will print out the numbers from 1 to 100,

replacing multiples of 3 with “Fizz”, the multiples of

5 with “Buzz”, and the multiples of 3 and 5 with “FizzBuzz”

I love me some constants!

START, STOP, FIZZ, BUZZ, BOTH = 1, 100, 3, 5, 15

START.upto(STOP) do |n|
result = if (n % BOTH == 0) then “FizzBuzz”
elsif (n % FIZZ == 0) then “Fizz”
elsif (n % BUZZ == 0) then “Buzz”
else n
end
puts result
end

====CODE END====

After seeing the post about making the core loop

(1…100).each { |x| p x }

I came up with this little ditty:

====CODE BEGIN====

#!/usr/bin/ruby -w
###########################

Filename: fizzbuzz2.rb

Author: Christian R.

Date: 2007-06-01

###########################

change the way Fixnum’s spit out their value

class Fixnum
FIZZ, BUZZ, BOTH = 3, 5, 15
def inspect
result = if (self % BOTH == 0) then “FizzBuzz”
elsif (self % FIZZ == 0) then “Fizz”
elsif (self % BUZZ == 0) then “Buzz”
else self
end
end
end

main loop

(1…100).each { |x| p x }

====CODE END====

Not too shabby for only a couple weeks of using Ruby!
I love this language!!

I didn’t spend any time golfing this quiz, so I don’t have anything
crazy to
share. I tried to implement it as I would in an interview - so my
intent
was clear.

My first attempt was procedural. The only thing that may be tricky is
that
I don’t t have any logic specific for printing “FizzBuzz”, I build that
value when the number is divisible by both 3 and 5.

(1…100).each do |i|
result = ‘’
result += ‘Fizz’ if i % 3 == 0
result += ‘Buzz’ if i % 5 == 0
result = i if result.empty?
puts result
end

That is how I would solve it if I was at a whiteboard. Afterwards I
would
explain how I would refactor this out to make it reusable, and I would
end
up with this:

class Integer
def fizz_buzz
result = ‘’
result += ‘Fizz’ if self % 3 == 0
result += ‘Buzz’ if self % 5 == 0
result = self if result.empty?
result
end
end

(1…100).each { |i| puts i.fizz_buzz } if FILE == $0

~Mike

On 6/4/07, Mike M. [email protected] wrote:

result += ‘Fizz’ if i % 3 == 0
result += ‘Buzz’ if i % 5 == 0
result = i if result.empty?
puts result
end

Wait a second you might be the first to provide a correct solution, I
just had this crazy idea, so I checked the Quiz. And yes indeed nobody
asked us to print newlines, just the numbers and their substitutes!!!
Too bad you spoiled it with puts at the end, that adds one newline
that is not part of the spec. But only one, so you are much closer
than most others.
Maybe nobody will get the job, as nobody can program up to an easy
spec, putting fancy newlines in there that have not been asked for!

Cheers
Robert

Sorry I cannot read code, but the idea stands no newlines at all.

From: “Robert D.” [email protected]

Wait a second you might be the first to provide a correct solution, I
just had this crazy idea, so I checked the Quiz. And yes indeed nobody
asked us to print newlines, just the numbers and their substitutes!!!
Too bad you spoiled it with puts at the end, that adds one newline
that is not part of the spec. But only one, so you are much closer
than most others.
Maybe nobody will get the job, as nobody can program up to an easy
spec, putting fancy newlines in there that have not been asked for!

I wasn’t going to post my solution, since it was so mundane
(and doesn’t necessarily meet the “how I would do it on an
interview” part… Although, if I had an irb prompt at the
interview, maybe this is exactly what I would have done. :slight_smile:

Anyway, my solution was to just type the following into IRB.
Very plain… but no newlines. (Note: My email client will
probably wrap these at 132 columns… They are supposed to
be in one line.)

1.upto(100) {|i| m3 = i%3 == 0; m5 = i%5 == 0; x = if m3 && m5;
“FizzBuzz”; elsif m3; “Fizz”; elsif m5; “Buzz”; else i; end; print
"#{x} " }

After that, I modified it slightly to remove some duplication:

1.upto(100) {|i| m3 = i%3 == 0; m5 = i%5 == 0; x=“”; x<<“Fizz” if m3;
x<<“Buzz” if m5; x=i unless m3||m5; print "#{x} "}

Regards,

Bill

On 6/4/07, Bill K. [email protected] wrote:

After that, I modified it slightly to remove some duplication:

1.upto(100) {|i| m3 = i%3 == 0; m5 = i%5 == 0; x=“”; x<<“Fizz” if m3; x<<“Buzz” if m5; x=i unless m3||m5; print "#{x} "}

That’s a bit long for golfing, but it’s probably the most readable
one-liner I’ve seen so far.

Some of my solutions:

The one I like:

1.upto(100) do |i|
a, b = i%3, i%5

print “fizz” if a==0
print “buzz” if b==0
print i if a!=0 && b!=0
puts
end

The first one, 4 mins, but not something I would leave on a page

100.times do |i|
j = i + 1
if j%15 == 0
puts “fizzbuzz”
next
end
if j%3 == 0
puts “fizz”
next
end
if j%5 == 0
puts “buzz”
next
end
puts j
end

hmmm, that wasn’t so good :slight_smile:

My one liner (and I spend quite some time to shorten it from 76

to 70 chars, damn, but then again, I never tried to write as-short-as-
possible-one-liners before)

1.upto(100){|i|a=(i%3==0?“fizz”:"")+(i%5==0?“buzz”:"");puts a[1]?a:i}

Wait a second you might be the first to provide a correct solution, I
just had this crazy idea, so I checked the Quiz. And yes indeed nobody
asked us to print newlines, just the numbers and their substitutes!!!
Too bad you spoiled it with puts at the end, that adds one newline
that is not part of the spec. But only one, so you are much closer
than most others.
Maybe nobody will get the job, as nobody can program up to an easy
spec, putting fancy newlines in there that have not been asked for!

So, if the new boss tells you to make a program to print the salary of
the employees, you would print them without any spaces nor newlines?

Doing something they don’t tell you to do is not the same than doing
something you are not supposed to do. The lack of context doesn’t
leave much room to make assumptions, but I guess no newlines would
make the output unreadable, and that is generally not good.


Dictionary is the only place that success comes before work. - Vince
Lombardi

After that, I modified it slightly to remove some duplication:

1.upto(100) {|i| m3 = i%3 == 0; m5 = i%5 == 0; x=""; x<<“Fizz” if m3;
x<<“Buzz” if m5; x=i unless m3||m5; print "#{x} "}

I like this solution, but I’m sorry… I just had to golf it! :slight_smile:

1.upto(100) {|i| x = “Fizz” if i%3 == 0; x = (x || “”) + “Buzz” if i%5
== 0;
print x||i,’ '}

On 6/5/07, CHubas [email protected] wrote:

the employees, you would print them without any spaces nor newlines?

Doing something they don’t tell you to do is not the same than doing
something you are not supposed to do. The lack of context doesn’t
leave much room to make assumptions, but I guess no newlines would
make the output unreadable, and that is generally not good.
So if I tell you to write a program that prints “Goolge” you will
write a program that prints “Google”, well I guess you are hired (but
I meant fired) :wink:
Robert

I would make a program that prints
“ASJusiajKk"kAIJSMM"Goolge"OOPksjj"jmnsKI"Imns”, unless they tell me
just to print “Goolge”. ;D

Not intended to be rude, but is just a little remark on how much you
should follow instructions when working. Again, the problem is a
little tricky, because it is ambiguous in what it wants to accomplish.
I think its trivial to put a space or a new line if you want to prove
the ability of the programmer, but it’s important if you want to know
if the programmer is able to follow instructions, to improve
readability of the output, etc.

I don’t say it’s wrong, but I would have put spaces or newlines, in
lack of more precise instructions and clear objectives.

On 6/5/07, CHubas [email protected] wrote:

I would make a program that prints
“ASJusiajKk"kAIJSMM"Goolge"OOPksjj"jmnsKI"Imns”, unless they tell me
just to print “Goolge”. ;D

Not intended to be rude,
But you are not rude, just wrong :wink: - kidding.
but is just a little remark on how much you
should follow instructions when working. Again, the problem is a
little tricky, because it is ambiguous in what it wants to accomplish.
I think its trivial to put a space or a new line if you want to prove
the ability of the programmer, but it’s important if you want to know
if the programmer is able to follow instructions, to improve
readability of the output, etc.

I don’t say it’s wrong, but I would have put spaces or newlines, in
lack of more precise instructions and clear objectives.
Sure who would not but I think I merit a little more acclamation for
my clever plot, did you think I was serious, I almost feel bad about
it.

[Now some serious considerations]
However it might be a good idea - if you the formal guy and want to
find out if they are on the same line - to ask if they want newlines
or if they would mind newlines, if they do not like the question the
probably would not like your style(*). I really liked Rick’s ideas
about what a Job Interview shall be, it is also for you to decide if
you want to work for the guys across the table.

And it is all about communication anyway, and we just did that very
fine, I feel :wink:

Cheers
Robert

(*)Don’t do that if you are unemployed of course.

To ask if they want newlines
or if they would mind newlines, if they do not like the question the
probably would not like your style(*).

Communication indeed is the base of a good relationship, of any kind.
If that does not succeed, you can always punch your almost-boss in the
face :smiley:

I really liked Rick’s ideas
about what a Job Interview shall be, it is also for you to decide if
you want to work for the guys across the table.

There are from jobs to jobs, but when one has to sell his own soul to
the devil, at least has to impress him a little.

And it is all about communication anyway, and we just did that very
fine, I feel :wink:

ASDFGHJK :smiley:
That’s why I love this community.

And, to not off-topic this conversation that much, I would say that
there are some other elements few people has looked into, such as
modularization and comments.

On 6/5/07, CHubas [email protected] wrote:

about what a Job Interview shall be, it is also for you to decide if

And, to not off-topic this conversation that much, I would say that
there are some other elements few people has looked into, such as
modularization and comments.
Hmm this too is an interesting point, would people ask you for
FizzBuzz to check these things? You know sometimes a cigar is just a
cigar (guess my nationality now :wink:
BTW I cannot figure ASDFGHJK out :wink:
Robert

On 6/5/07, CHubas [email protected] wrote:

I really liked Rick’s ideas
about what a Job Interview shall be, it is also for you to decide if
you want to work for the guys across the table.

There are from jobs to jobs, but when one has to sell his own soul to
the devil, at least has to impress him a little.

Sorry if you’re in the position of selling your soul, but if you are,
I’d suggest that you might not understand the particular devil you’re
trying to impress and do the opposite.

Last night, our local Agile meetup group had a talk by Ken Auer of
Role Model Software. He said some things which seem relevant to this
discussion.

First, he said that he wasn’t looking for ‘clever’ people when he
forms teams, he looks for people with a commitment to delivering
software and satisfying the client/customer. Too many programmers get
carried away with being clever and miss the goal, wasting resources
along the way.

He told of a time some years ago when a new guy who’d been there a few
months called him over to show off what he’d been working on. He had
spent a week writing a binary search for a list being used in the
application. Ken asked why he’d done that, and he said because linear
search is slow. Ken then asked him how many elements were typically
in the list, and after thinking about it a few minutes the guy said
that he figured that there might be as many as TWENTY-FIVE! To top it
off, this was a Smalltalk project, and he’d been applying the C-level
knowledge he’d gained in his undergraduate data structures class,
duplicating things which were already implemented in the Smalltalk
collection classes.

Personally I’m on the same wavelength as Ken. Better to have someone
with the basics, the right attitude towards the goals, and the
willingness and ability to help the team learn what’s needed when
needed.

Now this isn’t to say that there are devils out there who would be
impressed, a lot of hiring managers aren’t programmers themselves and
are easily impressed (or maybe I should say conned). I don’t know how
many of those guys I’ve run into over my career who say “I’m not
technical” with a certain amount of pride in their tone, and even more
who thought they were technical and either never knew what that meant
or had forgotten it. Just between us, it seems to me that this whole
idea of using fizz buzz to screen applicants probably came from the
fevered mind of one of these latter types.

Another thing Ken said that specifications on the whole are 15%
complete and 7% accurate. This is one of the main things which make
agile project management valuable. The specs WILL change, so be
prepared to change as you go. Build a little, find out where it’s
wrong or where putting it in front of the user changes the perception
of the requirements, fix it, set the new short term goal and move on.

It’s interesting that the late recognition that the spec is ambiguous
shows this even at such a micro scale.

Personally, being retired with some pension, I can choose which jobs I
want to work on, so I can try to find devil’s with a compatible
perspective. What I look for are projects where I can first be
valuable and deliver whats needed as it’s discovered, and second
educate myself along the way.

If you hear of any such projects, drop me a line off-forum.


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

The point of giving FizzBuzz as a screening question was nothing more
than that. A screen. It’s just to know if the person can write any
code at all. The initial poster of FizzBuzz didn’t say he was looking
for some of the crazy solutions people have been coming up with ever
since, he was just looking to screen out the candidates who can’t
write code. I think FizzBuzz is a perfectly acceptable first question
to ask someone. It’s a question to know if you’re not hiring the
person. Not a question to know if you are. To know if you are going to
hire the person there are much better questions to ask of course.

And personally, I love all these FizzBuzz solutions that pop up
everywhere. I think so far my favourite is Ruby interpreting Prolog’
interpreting Lisp interpreting Lisp solving FizzBuzz :
http://eigenclass.org/hiki/lisp-in-lisp-and-prolog-and-ruby

Avert your eyes!!!

(1…100).each{ |x|
out=""
(!!((x%3).zero? && out<<“Fizz”) & !!((x%5).zero? && out<<“Buzz”))
out=x if out==""
puts out }
end