Dialogue Box

By Neil Ticktin, Editor

Math Equations Ommission

I just received my writer's letter for my contribution to MacTutor. Thank you for the complimentary copy of July's MacTutor and thanks for the handsome cheque!

OOPs. Unfortunately you omitted the listing of the file CustomFn.c. In its place you printed Demo.c. CustomFn.c is an integral part of the compiler and the missing code will leave your readers wondering. [For those readers who need it, write to Xplain Corp. for the source code disk. This listing is on it. - Ed.]

How many suggestions can you make in a letter?

l am very excited at the rebirth of MacTutor. As a person living in a foreign country, it is very difficult to find information on programming in English (especially stuff that does not cost a fortune). MacTutor provides a source of information on programming as well as tools that are available. l would like to offer my input on the following things.

1. Please make sure to include the fax and phone numbers for things mentioned in your magazine. [We give the fax numbers whenever we are given them. We’ll try even harder to get them in the future. - Ed.]

2. l would also like to see a classified listing in the magazine. For example, I am trying to do some programming in assembly language but l can not find any books in print regarding the subject. l would like to be able to place an ad requesting or offering these types of materials as well as others. [We are looking into such a section for later this year. - Ed.]

3. l would also like to see a greater diversity of types of programs. For example, programs that read and write data to the SCSI port, input device manipulation, and communications. [We are working on getting hardware articles that address some of these topics. - Ed.]

Again, l look forward to many interesting and helpful articles in the future and l wish MacTutor the best of luck.

- Brett Bibby, Kanebo, Ltd.

Modify Print Dialogs Article Corrections

First let me thank you for publishing my article “Modify Print Dialogs” in the June 1992 issue of MacTutor. It was a thrill to see it in print.

There where a couple of minor bugs in the code. The program usually operates “As Advertised”, but under some conditions the wrong radio button could be disabled.

In the DisableDraftMode routine there are three lines which look like:

if ((*the_title)  -=  (*draft_title))

This really only checks that the first letter of the title matches (in this case) draft_title. These lines should be changed to use strcmp, as in:

if (Istrcmp(the_title,  draft_title))

I also left out a small block of code at the end of the DisableDraftMode routine. After the end of the main for loop and before the ) which ends the routine, add the following lines:

/* 1 */
if (  draft_selected  )  {
/*  draft  mode  was  selected,  so  select  the  next  best  */ 
 if  (  better_item_no  )  item_no  =  better_item_no, else
 if  (  best_item_no  )  item_no  =  best_item_no,

GetDItem((DialogPtr)  theDialogPtr,  item_no,  &the_type,  &the_item, 
 &the_box), SetCtlValue((ControlHandle)  the_item,  1),
}

The variables better_item_no and best_item_no should also be initialized to zero at the start of the routine.

I hope this didn’t cause anyone too much grief. Boy, is my face red!

- Greg WiIson, Ontario , Canada

Two Seconds

I take 2 seconds to drop you a word:

Carry on the good work !!

We like and need you.

- JC Hadorn

How Long can an article be?

BigNum Article

You say you knew you were not including all the code? My goodness!! If you knew, you could have at least put in an editor's comment in brackets to tell readers where the code was. [You are right, we should have and will try to do so in the future. - Ed.]

I still think massive shrinking of the code to a very tiny size would be the best alternative to elimination of code. [Our readers have told us not to do this because they want to be able to read the code. If it is small they can’t read it.- Ed.]

I never send to MacTutor any code that is not relevant, and I explain in minute detail what's what.

[The reason that the code was cut was because the article was already 12 pages long and the rest of the code would not fit. Although Lisp is of interest to our readers, we need to make sure that we stay reasonable on the amount of Lisp in the magazine. If the code was put in, almost 25% of the magazine would have been Lisp. The real solution here is to give the readers the important information and not hold their hand through the code. Of course, as always, ALL the code is available on the source code disk which anyone can get by calling MacTutor. - Ed.]

- André van Meulebrouck

Sounds good to me!

I was in process of letting my MacTutor subscription drop (again) when you folks took it over. The first couple of issues look pretty good. I hope you work harder than the old owners at showing good, useful code and avoiding their tendency to send out buggy or compatibility-challenged stuff. It is somewhat depressing to see the only technical journal for the Mac publish stuff that consistently ignores both Apple HI and Apple Compatibility standards, because that comes back and hurts the readers when things start breaking (worse, apple gets blamed for it, even though mama apple said "no no!"). I also constantly got heebie-jeebies from the rampant typos and basic copy-editing mistakes (in my other life, I'm a writer). If they couldn't get the article right, how can you trust the code?

[Nowadays, we try to test the code and get a feel for whether it is any good. Although ultimately, the responsibility needs to be both the article’s author and yours because we cannot test every bit of code as extensively as you would like. In the meantime, we are keeping vigilant on reports of problems with code and printing that information. This way, we use the entire Macintosh community to check over code. We hear you and will do the best that we reasonably can. - Ed.]

I'd also like to see more of a focus on the primary languages (Think, MPW) and less on the esoterica (Lisp, Fortran, Forth). Make it a journal for the folks doing the leading edge, which the side languages aren't. They're hobbyist toys.

And does anyone really find the Mousehole stuff useful? I'd rather see a more focussed "Ask the expert" column where questions get real answers rather than a random data stream where I have no clue if they know what they're talking about. [We actually do get a lot of compliments on the Mousehole, but I will keep both your comments in mind. - Ed.]

It was cute when MacTutor was three guys in a garage, but this is a real magazine now.

Dave Mark is a great addition to the team. [We think so too. - Ed.]

Keep it up.

Good luck!

- Chuq Von Rospach

Speeding up Random Numbers

I was glad to see Jon Bell's recap of Lemer's method and Park and Miller's excellent paper on minimal standard random number generators (cacm v31n10). This is an important area for implementers to learn about since the effort required to do it right is very low, and the results of doing it wrong can be disasterous. The further excursion into assembly level coding leaves a bit to be desired, though. If speed is what you're after, the following routine

;2
UpdateSeed
    MOVE.L  seed(A5), D1
    MULU.L#33614, D0:D1
 ; 33614 is 16807 * 2
    LSR.L   #1, D1
    ADD.L   D0, D1
    BPL.S   @1
    ADDI.L  #$80000001, D1
@1  MOVE.L  D1, seed(A5)
    RTS

takes less than half as much time as the one presented in the article, and computes the same result. This code takes advantage of the fact that the modulus is one less than a power of two. There is no need in this case to perform a divide to find the remainder. To convince yourself that it works, think about multiplying mod 9 (one less than a power of 10). (3 * 4) mod 9 = 12 mod 9 = 3, note that 3 is 1 + 2, the digits of the result of the multiplication. The only complication is when the sum overflows (e.g., (8 * 8) mod 9 = 64 mod 9 = 1, 6 + 4 = 10... 1 + 0 = 1). In this case we need to "carry around" in the result as is done by the ADDI above.

Lemer's method is important when the facilities of a CISC processor are not available (as in Pascal or C), but carrying the technique into (CISC) assembly code is inappropriate. In particular, even without the power of two minus one requirement of my implementation, it is not necessary to do two separate multiplies in Update Seed since the M680x0 will do double precision multiplies and divides...

;3
UpdateSeed
    MOVE.L  seed(A5), D0
    MULU.L  #a, D1:D0
    DIVS.L  #m, D1:D0
    MOVE.L  D1, seed(A5)
    RTS

Also, neither of these UpdateSeed routines suffer from the need to artificially restrict the range of the multiplier “a” -- although I've never been tempted to search for my own values: I recommend you stick with the values tested and certified by the experts.

Regards,