Nothing seems to work with Forth when submitted but the online interpreter for Forth happily passes the code as correct. Why doesn’t it report its success to the judge so that I can get get the correct answer?
Feb '21
Sep '22
Forth entry for problem TEST2 gets AC.
Are you sure your solutions are correct?
Hi,
Yes the solution is correct using the sample data. Problem seems to be that the data is supplied on the stack and then processed.
Should I redo the program to get numbers one by one as user input?
Sorry, I know nothing about Forth at all.
How does your solution differ from this sample from IDEONE?
create inbuf 16 chars allot
: gobble begin key dup 48 < while drop repeat ;
: readint dup gobble begin dup 47 > while over c! 1+ key repeat drop over - ;
: kthx begin inbuf readint over over s" 42" compare while type cr repeat drop drop ;
kthx bye
The sample solution is very bad Forth considering the problem statement. The code converts numbers into characters and stores them in a buffer. This is both untypical and unnecessary. Forth is a stack language and it is customary to take values directly from the data stack and for a function to consume them immediately.
The problem asks for a brute force solution and by implication to keep things simple.
\ A program to output integers until 42
: printLastNumber . ;
: cleanUp ( x! – ) depth 0 do drop loop ;
: test ( n – n bool ) dup 42 <> ;
: doIt ( – ) Begin test While printLastNumber cr Repeat ;
: Top ( – ) page doIt cr cleanUp ;
8 9 32 42 7 54 2 7 9 0 Top
As you can see the code is very simple to read. The test is factored out and called in the function doIt that takes the numbers from the stack and loops until 42 is encountered. Top just calls the whole thing. You have to remember to put numbers on the stack in reverse order though.
Anyway I can’t see any reason why the program is failing but succeeds on IDEON
Sorry, but both codes are totally meaningless to me.
When I ran your code on IDEONE, it didn’t give any output. But then, I noticed the line
8 9 32 42 7 54 2 7 9 0 Top
Does this put those number on the stack? You do realise you need to read the numbers from the standard input and write the result to the standard output?
Also, the codes writes “e[2Je[1;1H”, is that from the page command? The output from your program needs to match the sample output exactly. No prompts, messages or page commands.
Hi,
Yes the code puts the numbers directly on the stack. I have no idea what Standard input or standard output are. The gForth manual lists them as functions but gives no information as to how they are used. It is not the normal way for to interact with Forth.
I found one discussion about it and quote, “Forth does not know about STDIN. Many Forths, both desktop and embedded, allow I/O through KEY and EMIT and friends to be vectored. This could be through a console, a serial line, a TCP/IP connection. How the vectoring occurs is not (yet) standardised. ACCEPT works with KEY and EMIT and friends and so inherits whatever vectoring the Forth system provides. Note that the current input and output device should be vectored separately.”
So I think I need to research the matter further but might default to a language like Python. The key sentence is the first one! Thanks for your help.
I’m bumping this because I’ve run into the same problem with “TEST - Life, the Universe, and Everything”. I’ve tried reading input from the stack, from argv, and from stdin. All my attempts have all been rejected. I don’t know how I am supposed to read the input.
for example with stdin
\ ################################################
\ 1.fs
80 constant _buff-len
create _buff _buff-len allot
: main
begin
_buff _buff-len stdin read-line
throw nip 0= if exit then
_buff _buff-len s>number d>s ( n )
dup 42 = if exit else . cr then
again
;
main bye
\ ################################################
$ printf "1\n2\n88\n42\n99\n" | gforth 1.fs
1
2
88
$