| |
Here are some general basic tips on debugging routines written for Derive 5.
At the time of writing, Derive does not have any kind of debugging facility, or any
other means of trouble-shooting a program. So, when a program:
 | Does not work; |
| Fails to produce the expected output; |
| Displays the dreaded "you have performed an illegal operation. This
program will terminate ..." message; |
| Plus numerous other frustrations, |
what do we do?
With some other programming languages and compilers, it is possible to 'step
through' a program. We can then see what is happening to the variables as we
progress through the routine, and certain errors can be identified more easily.
In Derive, there is no specific method for debugging a program that does not
work correctly - one generally has to adopt a combination of ingenuity and
experience.
| It is crucial to regularly 'save' all current work - not just the algebra
window being worked on, but all other algebra windows. In particular, get
into the habit of hitting the 'save' button just before running a routine,
especially if the routine is not working correctly. |
| Try to test the routine throughout its' construction. Write a few lines of
code, then if possible try some sample data. Add a few more lines, then test
with other data. Attempt to build up the routine in stages, rather than
going for broke in one go. |
| Sometimes, even the most simple of routines can not work correctly. We
have all spent many frustrating hours wondering why it does not work. We say
to ourselves: "Well, it SHOULD work, but doesn't!". Try
introducing the RETURN (x) command at various stages of the routine.
Obviously, when running the program, it will terminate at the first call on
'RETURN'. By making the argument of RETURN to be some known variable, we are
able to compare what the routine returns, with what we think it should be.
For example: |
| The make_variables
routine, due to its' complexity, could be difficult to debug. 'Why does
it not work'???
Sometimes we have to go back to the very basics of a routine, and
slowly work forwards (or 'more difficult'). If we now insert the return
statement, just before the loop.
Now use the arguments of say return
[p_of_10, prefix]. Obviously, the routine will immediately
quit at this first call on routine,
but it should return the hand calculated values of
p_of_10
and prefix.
[2, x00].
We now remove this call on
return,
and place it at the next stage, say after the first
if
statement. |
| From personal experience, the most common debugging faults are:
1. Incorrect loop conditions
2. Improper use of variable names. For example, we may have a
function variable 'n', but we may use 'n' again, within the same
function, but in a different context, such as the
vector(...n)
command. Another example: we have an external variable, say x,
and forget to declare an internal variable of the same name.
3. Variable or command spelling mistakes!!! Simple, but
true!!! |
Testing, testing!
Another programming tip: when we write a program, it is almost always
vital to test the program to destruction. Where possible, we need to provide a
certain input, and study the output to see if it what we expect. Sometimes, it
is possible to compare the output with that of Derive's internal
functions.
Using the Fibonacci programmes (Internal and user-defined) as an example, with the vector
command:
VECTOR([fi(n), FIBONACCI(n)], n, 0, 10)
The following solution allows us to compare, at a glance, our
output with that of Derive's internal equivalent. Errors should be readily
obvious.
Time is Money!
When we write a routine, then run it, quite often we look at the timer to see
how long (i.e. how efficient) the routine is. We often then 'tweak' the routine
run faster, if possible. Due to the way Derive stores functions in memory, it is
recommended to run each routine we create at least twice. The second, and
subsequent, calls on the function are very often substantially faster than the
first call.
|
