[QUIZ] FizzBuzz (#126)

[Christian_Roese]

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 Roese
# Date: 2007-06-01
###########################
# Ruby Quiz - 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 Roese
# 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!!
--
Christian Roese

[Mike_Moore]

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

[Ivo_Dancet]

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

#### 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}

[Forum]

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

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

···

On 6/4/07, Mike Moore <blowmage@gmail.com> wrote:

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

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

[Forum]

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

[Bill_Kelly]

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.

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

···

From: "Robert Dober" <robert.dober@gmail.com>

[CHubas]

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

[Bill_Guindon1 (Bill Guindon)]

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

···

On 6/4/07, Bill Kelly <billk@cts.com> 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} "}

--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".

[Peter_Cooper]

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!

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

···

--
Peter Cooper

Ruby Inside: The Ruby Blog

[Forum]

> 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.

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)
Robert

···

On 6/5/07, CHubas <CHubas7@gmail.com> wrote:

__________________________________________

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

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

[CHubas]

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.

···

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

[Forum]

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 - 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

Cheers
Robert

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

···

On 6/5/07, CHubas <CHubas7@gmail.com> wrote:

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

[CHubas]

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

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

ASDFGHJK
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.

···

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

[Forum]

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
BTW I cannot figure ASDFGHJK out
Robert

···

On 6/5/07, CHubas <CHubas7@gmail.com> wrote:

> 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

> 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

ASDFGHJK
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.

--
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw

[Rick_DeNatale1 (Rick DeNatale)]

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. <G>

···

On 6/5/07, CHubas <CHubas7@gmail.com> 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.

--
Rick DeNatale

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

[Guillaume_Theoret]

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

···

On 6/6/07, Rick DeNatale <rick.denatale@gmail.com> wrote:

On 6/5/07, CHubas <CHubas7@gmail.com> 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. <G>

--
Rick DeNatale

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

[Daniel_N1 (Daniel N)]

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