1. More bugs
- Posted by "Wallace B. Riley" <wryly at MINDSPRING.COM>
Jun 18, 1998
-
Last edited Jun 19, 1998
Take a deep breath, everybody. This is a long post.
Thanks to Graeme, Ad, Isaac, and anyone else I might have overlooked, for
their suggestions to get my program to run.
Graeme, my program doesn't seem to hang up any more, but it doesn't produce
any output either. I tried your "Before" and "After" tricks (neat-o!) on
each side of various statements, including the statement that is supposed to
print a result. The Before and After statements both appear, but the result is
"The result is what?" you ask. That's it, right there. Namely nothing
.
There isn't even a blank space between "Before" and "After" where the output
should go.
I also added several other lines that are supposed to print out something
indicating what the program is doing at that moment. They all show proper
partial results.
The program contains an infinite loop 'while 1 do' with a condition that
causes 'exit'. This difficulty that I am experiencing arises several
statements before the 'exit' is encountered.
The guilty line used to say 'outlist = outlist & td'. The variable
'outlist' is declared as a sequence, but at the beginning of the program it
is blank, defined as {}. The variable td is declared as an atom. It
doesn't work. Somebody (Colin Taylor?) told me recently that when
concatenating an atom to a sequence, the atom should be made to look like a
one-element sequence by putting brackets around it. I did, but it doesn't
work. I changed the name of the variable 'outlist' to 'outlisu' so that it
wouldn't be confused with the variable being added to, later copying
'outlisu' into 'outlist'. No good. I changed the whole statement to
'outlisu' = append(outlist, td)'. Still no good.
After starting, the program changes a variable 'fd' from 0 to 1 to show that
something has happened already. This might be on the first pass through the
infinite loop, or on a later pass, or possibly never, but there is a
provision to guarantee the eventual 'exit' in any case. I changed the
'outlist' statement to an 'if-then' statement: 'if fd = 0 then outlist =
{td} else outlist = append(outlist,{td})'.
No output.
I put a dummy factor {99} as an initial value in 'outlist'. It doesn't work.
Clearly there is something wrong with my use of concatenation and with
'append'. If the manual has something about it that I am overlooking, it is
very well hidden. (A reminder: I have Euphoria 1.5, or is it 1.5a? and
Windows 3.1.)
I retract the remark I made about "treacherous 'get' statements". There are
none in this part of the program.
Thanks, Graeme, for your suggestion about a statement, 'if get_key then end
if' inside the 'while 1 do' loop so that a Ctrl-C stops the program. I
haven't done that yet because the program seems to be running all the way
through, even though it doesn't produce an output.
Ad, I tried your suggestion about 'with trace' (before getting your
message). It didn't help. In most cases I find that Euphoria's 'trace'
capability is not very helpful. It just slows things down enormously and
doesn't show me what is wrong. More likely, it does show me, but I'm too
stupid to recognize it. Its only advantage is that it can be used on part
of a program without bogging down the rest. I like that, even though I
haven't gotten any real good out of it so far.
Yes, I can always use Ctrl-Alt-Del to get out of a real difficulty. The
trouble is, that goes all the way back to a C-prompt or the Program Manager
or some similar level, from which rebuilding the path to the program and
then restarting it can be somewhat arduous.
There doesn't seem to be any difficulty on the hard disk. I clean it up
more or less regularly with 'defrag'. If I run 'chkdsk' it doesn't say
"Hey, you blithering idiot" or anything equally obvious.
Well, fooey. No, Ad, my program isn't secret. It's just stupid. I
undertook it partly as an update of a program that I originally wrote a long
time ago, and partly as a means of learning more about Euphoria. So far
Euphoria is outsmarting me and my 'stupid' program.
The program accepts a number and looks for either its prime factors or its
divisors; or, if the number is prime, it says so. (I assume you know what
prime factors are.) I wrote it originally for an HP 11-C calculator, which
I don't seem to have any more -- I can't find it, anyhow. Later I revised
it for an HP32S II calculator, where it resides at this moment and runs very
well, although slowly for large numbers.
Still later, I rewrote the program in QBasic. For small numbers, the QBasic
version produces correct results; for sufficiently large numbers, QBasic
overflows and drops dead. For large numbers that are not large enough to
overflow, the program runs to completion but sometimes produces wrong
answers. I discovered this just recently, while preparing to write the
Euphoria version. I haven't checked it out yet.
The Euphoria version has a bug that I know about but haven't tried yet to
eradicate. If the prime factorization of a number has some factors repeated
(e.g. 60 = {2,2,3,5}) this program won't repeat them. This other bug about
no output seems to be more serious.
If you still want to see the Euphoria version, I'll send it. It has 151
lines at present, including some extras thrown in to help while debugging,
and some sections that haven't been debugged yet.
Okay, you can breathe now.
Wally Riley
wryly at mindspring.com
2. Re: More bugs
At 09:43 PM 6/18/98 -0400, Wally wrote:
>The guilty line used to say 'outlist = outlist & td'. The variable
>'outlist' is declared as a sequence, but at the beginning of the program it
>is blank, defined as {}. The variable td is declared as an atom. It
>doesn't work.
It should work fine, if you're sequence wasn't
building as you expected, you'll have to look at
where the atom td gets it's value from.
{}&a1 = {a1}
{a1}&a2 = {a1,a2}
{a1,a2}&a3 = {a1,a2,a3} ... etc
>After starting, the program changes a variable 'fd' from 0 to 1 to show that
>something has happened already. This might be on the first pass through the
>infinite loop, or on a later pass, or possibly never, but there is a
>provision to guarantee the eventual 'exit' in any case. I changed the
>'outlist' statement to an 'if-then' statement: 'if fd = 0 then outlist =
>{td} else outlist = append(outlist,{td})'.
If length(outlist) then ... would have worked
for this, but I don't think it's what you want:
append({a1},{a2}) = {a1,{a2}}
append({a1,{a2}},a3) = {a1,{a2},{a3}} ... etc
>No output.
I think this where you have to start.
How are you printing the output to the screen?
if you use print(1,outlist) you should see
something. Even if outlist is an empty
sequence print() will display "{}"
Maybe, for debugging purposes, you could put
print(1,outlist)
puts(1,"\n")
immediately after the
"outlist=outlist&td" line.
Then you could watch the sequence build.
>If you still want to see the Euphoria version, I'll send it. It has 151
>lines at present, including some extras thrown in to help while debugging,
>and some sections that haven't been debugged yet.
I'd be interested in taking a look at it.
Hope this helps,
Graeme.
----------------------------------------------------