Morning all! My daughter (she's 9) and I are working together on a program, partly for fun and partly for the learning experience. Her teacher doesn't assign specific homework, but asks that the students spend ten to twenty minutes per night drilling on 'math facts.' There's no worksheet, and she suggested parents just download worksheets from the web or make up the problems. Well, that got old about two days into the school year, and I realized that the M100 and BASIC would be perfect for this.
The general algorithm is: 1) Choose whether you want to work on addition, subtraction, multiplication or division 2) Indicate how many problems you want to do 3) Choose a 'difficulty' (which determines whether you're working with one-, two- or three-digit problems) The program then uses a FOR loop as many times as the student indicates and uses two INT(RND(... statements to generate two random numbers for use in the problem. It keeps a running tally of how many questions are answered correctly. At the end the results are displayed (number correct as well as percentage) and can be printed out to include in the homework folder if you want. It's nothing fancy but it gets the job done and it's been fun to work it out. She's had a blast seeing how programs actually work. We're stuck, though, and need advice on the division routine. For adding, subtracting, or multiplying, the program works fine as we've written it. I.e., the random number subroutine returns A and B, and those are then used for the problem. It doesn't matter what the numbers are or what order they're in. Division is a little trickier, though. The kids aren't using decimals or fractions yet, so it's important to divide the larger number by the smaller. And they haven't learned how to disrupt the fabric of space/time yet either, so I need to not divide by zero. My question, though, is where in the logical flow of the program would be the 'best' place to handle those exceptions. Should we compare as soon as the two random numbers come back until A>B and B is not zero? Should we add it as a step at the end of the random number subroutine that only executes if we're doing division? Heck, does it need to be its own subroutine? And in whichever case, if the A>B comparison 'fails' but neither is zero, is it better to re-run the routine from the start or write a way to 'flip' the values? Pretty much all those would work, we were just brainstorming the most 'efficient' way to handle it from a programming perspective. Which is actually kind of funny if you look at the rest of the program and how many times we repeat ourselves in the four different 'modules.' :-D Roger / KM4WVE
