7
\$\begingroup\$

Let's consider a QBasic solution to FizzBuzz. The code works correctly, printing the required output from 1 all the way up. The problem is, since there's a lot of output, some of it scrolls off the screen. What you see when you run the program is this:

Fizz
79
Buzz
Fizz
82
83
Fizz
Buzz
86
Fizz
88
89
FizzBuzz
91
92
Fizz
94
Buzz
Fizz
97
98
Fizz
Buzz

Press any key to continue

Unlike with C and its descendants, output is not a stream, but is sent directly to the screen. This means that 1) you can't scroll back in the terminal and see the previous lines, and 2) you can't redirect output to a file to save the lines.1 Once they scroll off the screen, they're gone.

So is this a valid FizzBuzz program, if it doesn't observably display all 100 lines?

If not, does it help to add a 1-second pause or wait for user keypress after printing each line?

1 Erik the Outgolfer informs me that redirecting output to a file is possible when running QBasic in DOSBox (or in actual DOS, presumably). So that takes away the specific example I used here. I think the general question is still good to ask and might apply in some cases--for example, if LOCATE is used, as this isn't recorded in the output buffer.

\$\endgroup\$
5
  • 3
    \$\begingroup\$ What determines how many lines are displayed? Does it depend on the terminal? \$\endgroup\$
    – xnor
    Jun 2, 2018 at 18:03
  • \$\begingroup\$ @xnor 25 lines is AFAIK always the default, except in a couple of screen modes where it's 30. QBasic has a WIDTH command that lets you set the width and height (in characters) of the display, but there's a limited number of options. The width can be either 80 or 40. About the height, the help file says, "The value can be 25, 30, 43, 50, or 60, depending on your display adapter and screen mode." So it seems to be partially system-dependent, but in any case never enough lines for a full FizzBuzz. \$\endgroup\$
    – DLosc
    Jun 4, 2018 at 3:36
  • \$\begingroup\$ I think it will "flash" the output on the screen at some point anyway? \$\endgroup\$
    – DELETE_ME
    Jun 7, 2018 at 1:56
  • \$\begingroup\$ @user202729 Yes, at least in theory. If your CPU/emulator is slow enough, that would make the output observable. On the other hand, to the average person testing the code, it goes by so fast that it's essentially unobservable. \$\endgroup\$
    – DLosc
    Jun 7, 2018 at 6:21
  • 2
    \$\begingroup\$ "essentially unobservable" != "unobservable". Just like how "doesn't terminate in 10^500 years" != "doesn't terminate". \$\endgroup\$
    – DELETE_ME
    Jun 7, 2018 at 6:23

2 Answers 2

Reset to default
25
\$\begingroup\$

Yes, output counts even if you can't see it anymore

The output definitely happened - you just can't see it because additional output caused it to go out of the limited screen space. Just like closing your eyes doesn't make everything poof out of existence1, stuff scrolling out of view in a window doesn't mean it didn't happen.

[1] unless you haven't developed object permanence, or you follow solipsism

\$\endgroup\$
1
  • \$\begingroup\$ Or narcissism. "I'll be right back, everyone stand motionless- or disappear; whatever everyone else does when I leave the room." \$\endgroup\$
    – Magic Octopus Urn
    Jun 12, 2018 at 17:32
1
\$\begingroup\$

It depends

It depends on what you defines to be the "output" -- it's up to you. In particular:

  • If you let the output be "the content on the screen when the program terminates", it doesn't count.
  • If you let the output be "whatever the program writes", it does count.

This is just a small part of "specify your output format" (stdout/stderr/screen).

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .