Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #16015 > unrolled thread

Fizz Buzz Zoom

Back to article view | Back to comp.lang.forth

Contents

  Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-07 09:19 -0700
    Re: Fizz Buzz Zoom mhx@iae.nl (Marcel Hendrix) - 2012-10-07 20:33 +0200
      Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-07 11:43 -0700
        Re: Fizz Buzz Zoom mhx@iae.nl (Marcel Hendrix) - 2012-10-07 21:09 +0200
          Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-07 12:18 -0700
            Re: Fizz Buzz Zoom ouatubi@gmail.com - 2012-10-08 01:15 -0700
              Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 09:37 -0700
                Re: Fizz Buzz Zoom ouatubi@gmail.com - 2012-10-09 01:16 -0700
    Re: Fizz Buzz Zoom Doug Hoffman <glidedog@gmail.com> - 2012-10-07 14:45 -0400
      Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-07 12:28 -0700
        Re: Fizz Buzz Zoom Doug Hoffman <glidedog@gmail.com> - 2012-10-07 21:06 -0400
          Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-07 21:32 -0700
            Re: Fizz Buzz Zoom Doug Hoffman <glidedog@gmail.com> - 2012-10-08 06:06 -0400
              Re: Fizz Buzz Zoom Mark Wills <forthfreak@gmail.com> - 2012-10-08 05:24 -0700
    Re: Fizz Buzz Zoom anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-08 14:02 +0000
      Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 08:38 -0700
        Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 08:43 -0700
        Re: Fizz Buzz Zoom "A. K." <akk@nospam.org> - 2012-10-08 18:03 +0200
        Re: Fizz Buzz Zoom anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-08 16:08 +0000
          Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 09:23 -0700
            Re: Fizz Buzz Zoom anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-08 17:11 +0000
              Re: Fizz Buzz Zoom Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 22:12 +0200
              Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 13:16 -0700
                Re: Fizz Buzz Zoom Hannu Vuolasaho <hannu.vuolasaho@nospam.tut.fi.invalid> - 2012-10-08 21:06 +0000
                  Re: Fizz Buzz Zoom "Elizabeth D. Rather" <erather@forth.com> - 2012-10-08 11:57 -1000
                    Re: Fizz Buzz Zoom Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:26 -0700
                      Re: Fizz Buzz Zoom George Hubert <georgeahubert@yahoo.co.uk> - 2012-10-09 08:38 -0700
                        Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-09 09:03 -0700
                      Re: Fizz Buzz Zoom "Elizabeth D. Rather" <erather@forth.com> - 2012-10-09 08:44 -1000
                Re: Fizz Buzz Zoom anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-10 12:32 +0000
                  Re: Fizz Buzz Zoom Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-10 16:59 +0200
                    Re: Fizz Buzz Zoom anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-10 16:42 +0000
                  Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-12 21:18 -0700
                    Re: Fizz Buzz Zoom "Elizabeth D. Rather" <erather@forth.com> - 2012-10-12 21:06 -1000
        Re: Fizz Buzz Zoom Doug Hoffman <glidedog@gmail.com> - 2012-10-10 09:02 -0400
    Re: Fizz Buzz Zoom Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-08 17:50 +0100
      Re: Fizz Buzz Zoom Paul Rubin <no.email@nospam.invalid> - 2012-10-08 10:15 -0700

Page 1 of 2  [1] 2  Next page →

#16015 — Fizz Buzz Zoom

This works in gforth.  I'm not sure if it's valid ANS Forth, since it
requires multiple s" ..." string literals to be alive at the same time.
Coding and testing wasn't difficult in absolute terms, since the program
is so small, but it still took multiple tries and head-scratching, and
the result seems unmodular compared to a Python version.  Maybe there
was something I could have done better.

    : fb0 ( flag sa su n d -- flag )
        mod 0= if type -1 else 2drop 0 then or ;

    : fb ( n -- flag ) >r
        0 ( flag )
        s" Fizz" r@ 3 fb0
        s" Buzz" r@ 5 fb0
        s" Zoom" r> 7 fb0 ;

    : f ( n -- ) dup fb ( flag ) 0= if . else drop then cr ;

    : run ( -- ) \ run to 120 so that 3*5*7=105 is included
        120 1 do i f loop ;

[toc] | [next] | [standalone]

#16018

Paul Rubin <no.email@nospam.invalid> writes Re: Fizz Buzz Zoom
[..]
> This works in gforth.  I'm not sure if it's valid ANS Forth, since it
> requires multiple s" ..." string literals to be alive at the same time.
> Coding and testing wasn't difficult in absolute terms, since the program
> is so small, but it still took multiple tries and head-scratching, and
> the result seems unmodular compared to a Python version.  Maybe there
> was something I could have done better.

Unmodular? As there is no firm specification, go for the obvious:

\ ?AT ( -- column row ) tests cursor position
: 3/5/7/n? ( n -- )
    #120 1 DO
	      CR DUP 3 MOD 0= IF ." Fizz" ENDIF
		 DUP 5 MOD 0= IF ." Buzz" ENDIF
		 DUP 7 MOD 0= IF ." Zoom" ENDIF	
		 ?AT  DROP 0= IF . ELSE DROP ENDIF 
   	 LOOP ;

-marcel

[toc] | [prev] | [next] | [standalone]

#16019

mhx@iae.nl (Marcel Hendrix) writes:
> Unmodular? As there is no firm specification, go for the obvious:
> \ ?AT ( -- column row ) tests cursor position

I don't think relying on the cursor position is especially modular.
Also, it extends reasonably well to n=11:

  DUP 11 MOD 0= IF ." Blarg" ENDIF

but fails for n=13, which is an unlucky number and should therefore
print as the empty string.

[toc] | [prev] | [next] | [standalone]

#16021

Paul Rubin <no.email@nospam.invalid> writes Re: Fizz Buzz Zoom

> mhx@iae.nl (Marcel Hendrix) writes:
>> Unmodular? As there is no firm specification, go for the obvious:
>> \ ?AT ( -- column row ) tests cursor position

> I don't think relying on the cursor position is especially modular.

You mean portable?

> Also, it extends reasonably well to n=11:

>  DUP 11 MOD 0= IF ." Blarg" ENDIF

> but fails for n=13, which is an unlucky number and should therefore
> print as the empty string.

I don't know anything about 13. Your program is my specification.

But I should have tested better. Here it is again with Blargh, 11 and 13.

: 3/5/7/11/n? ( -- )
    #120 1 DO
	      CR i   3 MOD 0= IF ." Fizz"   ENDIF
		 i   5 MOD 0= IF ." Buzz"   ENDIF
		 i   7 MOD 0= IF ." Zoom"   ENDIF	
		 i #11 MOD 0= IF ." Blargh" ENDIF	
		 ?AT DROP 0=  
		 I #13 <> AND IF i  .       ENDIF 
   	 LOOP ;

-marcel

[toc] | [prev] | [next] | [standalone]

#16022

mhx@iae.nl (Marcel Hendrix) writes:
>> I don't think relying on the cursor position is especially modular.
> You mean portable?

I mean separating compuational from i/o concerns, that sort of thing.

> I don't know anything about 13. Your program is my specification.

The idea was that readers would be familiar with the original FizzBuzz
problem, but maybe you weren't.  My bad.

> 		 ?AT DROP 0=  
> 		 I #13 <> AND IF i  .       ENDIF 

This extra test seems rather ad-hoc.  

[toc] | [prev] | [next] | [standalone]

#16040

On Sunday, October 7, 2012 10:18:58 PM UTC+3, Paul Rubin wrote:
> mhx@iae.nl (Marcel Hendrix) writes:
> 
> >> I don't think relying on the cursor position is especially modular.
> 
> > You mean portable?
> 
> 
> 
> I mean separating compuational from i/o concerns, that sort of thing.

Hi Paul!
A-solution tests + :)

variable offs
: PAD+	( ca u -- )
	PAD offs @ tuck + swap 80 swap -
	rot umin dup offs +! move ;

: i/o	PAD offs @ type space ;

: main	( n -- )
	1 DO
		0 dup offs !
		I 3 mod 0= IF s" fizz" PAD+ -1 OR THEN
		I 5 mod 0= IF s" buzz" PAD+ -1 OR THEN
		I 7 mod 0= IF s" zoom" PAD+ -1 OR THEN
		IF I 0 <# #S #> PAD+ i/o THEN	
	LOOP ;

\ Tests

s" alfa" PAD+
s" beta" PAD+
PAD offs @ type
cr i/o cr 
cr 120 main cr 
cr .s cr bye

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#16056

ouatubi@gmail.com writes:
> 		IF I 0 <# #S #> PAD+ i/o THEN

That should say

    IF i/o ELSE I . THEN

other than that, the code does about what is asked, though it seems like
more coding effort than some of the other solutions.

[toc] | [prev] | [next] | [standalone]

#16086

On Monday, October 8, 2012 7:37:39 PM UTC+3, Paul Rubin wrote:
> ouatubi@gmail.com writes:
> 
> > 		IF I 0 <# #S #> PAD+ i/o THEN
> 
> 
> 
> That should say
> 
> 
> 
>     IF i/o ELSE I . THEN
> 
> 
> 
> other than that, the code does about what is asked, though it seems like
> 
> more coding effort than some of the other solutions.

Ok! I misunderstand requirements.
But a minimal change should be:
        0= IF I 0 <# #S #> THEN i/o
as you requested to have a separation between `i/o' code and computational code.

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#16020

Don't think there's anything wrong with your solution.

Here's another one I threw together just now:

: divisible-by? ( n1 n2 -- f f ) \ is n1 divisible by n2?
   mod 0= dup ;

: fizz ( n -- f ) \ true if divisible
   3 divisible-by? if ." Fizz" then ;

: buzz ( n -- f ) \ true if divisible
   5 divisible-by? if ." Buzz" then ;

: zoom ( n -- f ) \ true if divisible
   7 divisible-by? if ." Zoom" then ;

: run ( n -- )
    1 do
      cr i fizz
         i buzz or
         i zoom or
         0= if i . then
      loop ;

0 [if]
Comments:
- perhaps more meaningful names
- no need for return stack for keeping i
- a bit less stack thrashing, just 1 dup
- fewer items being tossed around on the stack
- fizz/buzz/zoom could be factored further, not sure it's worth it

No doubt someone else has a more clever solution.
[then]

-Doug

[toc] | [prev] | [next] | [standalone]

#16023

Doug Hoffman <glidedog@gmail.com> writes:
> - perhaps more meaningful names
> - no need for return stack for keeping i
> - a bit less stack thrashing, just 1 dup
> - fewer items being tossed around on the stack
> - fizz/buzz/zoom could be factored further, not sure it's worth it

The fizz/buzz/zoom design seems intended to make the the whole
multi-level program to have the right stuff on the stack all the time,
which is in the Forth spirit, but the lack of factoring doesn't seem
ideal.  More factoring would seem to require passing a lot of args to
the bottom level, like my example did.

My version originally used gforth locals instead of the return stack
stuff, but that seemed like overkill.

[toc] | [prev] | [next] | [standalone]

#16034

On 10/7/12 3:28 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> - perhaps more meaningful names
>> - no need for return stack for keeping i
>> - a bit less stack thrashing, just 1 dup
>> - fewer items being tossed around on the stack
>> - fizz/buzz/zoom could be factored further, not sure it's worth it
>
> The fizz/buzz/zoom design seems intended to make the the whole
> multi-level program to have the right stuff on the stack all the time,
> which is in the Forth spirit, but the lack of factoring doesn't seem
> ideal.  More factoring would seem to require passing a lot of args to
> the bottom level, like my example did.

I was thinking of something like this:

: divisible-by? ( n1 n2 -- f )
   mod 0= ;

: speak? { n1 n2 str -- f }
   n1 n2 divisible-by? dup if str count type then ;

: fizz ( n1 -- f )
   3  c" Fizz"  speak? ;

: buzz ( n1 -- f )
   5  c" Buzz"  speak? ;

: zoom ( n1 -- f )
   7  c" Zoom"  speak? ;

: run ( n -- )
    1 do
      cr i fizz
         i buzz or
         i zoom or
         0= if i . then
      loop ;

I'm not sure the extra factoring was worthwhile, but there it is.

> My version originally used gforth locals instead of the return stack
> stuff, but that seemed like overkill.

I will use locals with no apologies when they suit my purpose, as you 
can see above.

-Doug

[toc] | [prev] | [next] | [standalone]

#16039

Doug Hoffman <glidedog@gmail.com> writes:
> I'm not sure the extra factoring was worthwhile, but there it is.

I see, you got rid of one of the bottom level stack items by using
counted strings instead of addr/u, and got rid of another one by
repeating the "or" after each top level divisor check.  I guess both are
reasonable.

> I will use locals with no apologies when they suit my purpose, as you
> can see above.

Using them does make stuff easier.  I wonder whether typical embedded
Forths support them.

[toc] | [prev] | [next] | [standalone]

#16044

On 10/8/12 12:32 AM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> I'm not sure the extra factoring was worthwhile, but there it is.
>
> I see, you got rid of one of the bottom level stack items by using
> counted strings instead of addr/u, and got rid of another one by
> repeating the "or" after each top level divisor check.  I guess both are
> reasonable.
>
>> I will use locals with no apologies when they suit my purpose, as you
>> can see above.
>
> Using them does make stuff easier.  I wonder whether typical embedded
> Forths support them.
>

Not hard to get rid of locals in this case (often not so easy).  Locals 
are in ANS, btw:

: speak? ( n1 n2 str -- f )
   >r divisible-by? dup if r@ count type then r> drop ;

or maybe just cram the whole thing together, perhaps the obvious thing 
to do for such a simple routine.  Doing so for more complex code is 
usually a mistake, IMO.  A personal style thing perhaps:

: run'
   120 1 do
      cr i 3 mod 0= dup if ." Fizz" then
         i 5 mod 0= dup if ." Buzz" then or
         i 7 mod 0= dup if ." Zoom" then or
         0= if i . then
      loop ;

-Doug

[toc] | [prev] | [next] | [standalone]

#16045

>
> : run'
>    120 1 do
>       cr i 3 mod 0= dup if ." Fizz" then
>          i 5 mod 0= dup if ." Buzz" then or
>          i 7 mod 0= dup if ." Zoom" then or
>          0= if i . then
>       loop ;
>
> -Doug

At last! Somebody posted what I was thinking. I was looking at the
everyone's code thinking "Hmmm... I'm clearly not getting this"

[toc] | [prev] | [next] | [standalone]

#16046

Paul Rubin <no.email@nospam.invalid> writes:
>This works in gforth.  I'm not sure if it's valid ANS Forth, since it
>requires multiple s" ..." string literals to be alive at the same time.

You only use the compilation semantics of S", and the strings from
that live forever, so no need to worry about that.

>Coding and testing wasn't difficult in absolute terms, since the program
>is so small, but it still took multiple tries and head-scratching, and
>the result seems unmodular compared to a Python version.  Maybe there
>was something I could have done better.

What is the specification?  What is the Python version?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#16050

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> What is the specification?  What is the Python version?

It's a version of the famous FizzBuzz interview question:

  http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

The original question only used "Fizz" and "Buzz" and the most common
solution involves dealing with the case n%15==0 separately from the
n%3==0 and n%5==0 cases, which I thought was ugly.  There is not a
canonical Python version.  There's a discussion here of a bunch of
Haskell and Python solutions that I mostly didn't like, because of too
much abstraction (the Haskell monoid versions), or not enough (the
Python version everyone liked handles the empty string incorrectly):

  http://www.reddit.com/r/haskell/comments/10zlyy/fizzbuzz_revisited_using_monoids/ 

FizzBuzz also shows up in the coding game Code Hero:

  http://primerlabs.com/fizzbosses

My preferred version separates the code from the data ("figure out the
data structure, and the code takes care of itself").  First write down
the data:

     spec = [(3, "Fizz"), (5, "Buzz"), (7, "Zoom")]

The following code then flows pretty easily (be aware that ''.join(...)
is a Python idiom for concatenating a list of strings, and that a
boolean test on a list returns true iff the list is non-empty):

     def fb(n):
        ns = [s for (d,s) in spec if n%d==0]
        return ''.join(ns) if ns else str(n)

     for i in xrange(1,121): print fb(i)

This handles arbitrary numbers of divisors and does the right thing if
one or more of the strings is empty.  In Haskell I'd probably code it
the right way, or if I did it with monoids I'd use mconcat instead of
that thing with monad comprehensions (don't worry if that makes no
sense).

According to the Wikipedia article about FizzBuzz which I just read last
night, it was originally a drinking game rather than a programming
challenge, and the syllable for divisor 7 is traditionally "Woof" rather
than "Zoom".  One learns all kinds of things on the internets.

[toc] | [prev] | [next] | [standalone]

#16051

Paul Rubin <no.email@nospam.invalid> writes:
> In Haskell I'd probably code it the right way,

I meant to say "the same way".  Freudian slip, perhaps.

[toc] | [prev] | [next] | [standalone]

#16053

On 08.10.2012 17:38, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> What is the specification?  What is the Python version?
>
> It's a version of the famous FizzBuzz interview question:
>
>    http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
>
> The original question only used "Fizz" and "Buzz" and the most common
> solution involves dealing with the case n%15==0 separately from the
> n%3==0 and n%5==0 cases, which I thought was ugly.  There is not a
> canonical Python version.  There's a discussion here of a bunch of
> Haskell and Python solutions that I mostly didn't like, because of too
> much abstraction (the Haskell monoid versions), or not enough (the
> Python version everyone liked handles the empty string incorrectly):
>
>    http://www.reddit.com/r/haskell/comments/10zlyy/fizzbuzz_revisited_using_monoids/
>
> FizzBuzz also shows up in the coding game Code Hero:
>
>    http://primerlabs.com/fizzbosses
>
> My preferred version separates the code from the data ("figure out the
> data structure, and the code takes care of itself").  First write down
> the data:
>
>       spec = [(3, "Fizz"), (5, "Buzz"), (7, "Zoom")]
>
> The following code then flows pretty easily (be aware that ''.join(...)
> is a Python idiom for concatenating a list of strings, and that a
> boolean test on a list returns true iff the list is non-empty):
>
>       def fb(n):
>          ns = [s for (d,s) in spec if n%d==0]
>          return ''.join(ns) if ns else str(n)
>
>       for i in xrange(1,121): print fb(i)
>
> This handles arbitrary numbers of divisors and does the right thing if
> one or more of the strings is empty.  In Haskell I'd probably code it
> the right way, or if I did it with monoids I'd use mconcat instead of
> that thing with monad comprehensions (don't worry if that makes no
> sense).
>
> According to the Wikipedia article about FizzBuzz which I just read last
> night, it was originally a drinking game rather than a programming
> challenge, and the syllable for divisor 7 is traditionally "Woof" rather
> than "Zoom".  One learns all kinds of things on the internets.
>

Thanks, nice anecdote. :-)

Although I'd say that most of our candidates could solve the problem. 
But perhaps just because we focus on university graduates who still have 
some fresh math in their heads.

[toc] | [prev] | [next] | [standalone]

#16054

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> What is the specification?  What is the Python version?
>
>It's a version of the famous FizzBuzz interview question:
>
>  http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
>
>The original question only used "Fizz" and "Buzz" and the most common
>solution involves dealing with the case n%15==0 separately from the
>n%3==0 and n%5==0 cases, which I thought was ugly.

Ok, that specification is:

|Write a program that prints the numbers from 1 to 100. But for
|multiples of three print "Fizz" instead of the number and for the
|multiples of five print "Buzz". For numbers which are multiples of
|both three and five print "FizzBuzz".

Given the separate case in the spec for Fizz Buzz, having a separate
case in the program looks pretty natural to me.

Anyway, what is the specification of Fizz Buzz Zoom?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#16055

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Given the separate case in the spec for Fizz Buzz, having a separate
> case in the program looks pretty natural to me.

Since you've already done both tests (mod 3 and mod 5), doing them again
has a DRY problem.

> |multiples of five print "Buzz". For numbers which are multiples of
> |both three and five print "FizzBuzz". ...
> Anyway, what is the specification of Fizz Buzz Zoom?

Same thing, except additionally, if n is divisible by 7, print "Zoom".
So for example, for n=21 you'd print FizzZoom, for n=35 you'd print
BuzzZoom, and for n=105 you'd print FizzBuzzZoom.

It could be treated as a two-part question:
  1) solve FizzBuzz
  2) extend FizzBuzz solution to handle Zoom.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web