On a computer science lesson, I was tasked to write a simple piece of code. Program receives a sequence of integers, and it should output the length of the longest same-integer sequence. It also stops after reading two zeros.
Here is the code:
type int64array = array[1..10000] of int64;
var n,x,counting,buffer:int64;
var nlist:int64array;
function counter(list:int64array): int64;
var i,j,a,b:int64;
begin
for i:=1 to 10000 do
begin
if list[i]=0 then Break;
a:=1;
for j:=i+1 to 10000 do
begin
if ((list[i]=list[j]) and (list[i]=list[j-1])) then a:=a+1;
end;
if a>b then b:=a;
end;
counter:=b;
end;
begin
n:=1;
buffer:=1;
while True do
begin
readln(n);
x:=counter(nlist);
if ((n=0) and (buffer=0)) then Break;
counting:=counting+1;
nlist[counting]:=n;
buffer:=n;
writeln()
end;
writeln(x);
end.
It produces the wanted result and works correctly, but creates unnecessary empty lines.
Losing the writeln()
in line 30 messes with output and the program produces rubbish numbers.
Here's the input for both programs:
1
1
0
0
The output with the writeln()
line:
2
The output without it:
140735786777216
The end goal is to create a program that works correctly, but doesn't produce empty lines.
The output with the
writeln()
line: […] The output without it: […]
I’m sorry to break it to you, pal, but the problem is you must be using a broke processor. This is indeed a change in code that should not affect the remainder of your program’s behavior.
The end goal is to create a program that works correctly, but doesn't produce empty lines.
The best solution is to switch to a processor that ain’t broke. The worst solution is, of course, addressing your processor’s bugs, yet it can also improve your program’s design. In particular, your algorithm should by design not read uninitialized data.