![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/images/you_are_here_red.gif)
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/default/files/beta-site.gif)
|
Volume Number: | 9 | |||
Issue Number: | 12 | |||
Column Tag: | Programmers’ Challenge |
Programmers’ Challenge
By Mike Scanlin, MacTech Magazine Regular Contributing Author
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
PRESENT PACKING
The gift giving season is here and it’s time to figure out how to most efficiently store all the presents you’re going to receive. Let’s suppose you have a 100cm x 100cm area where you can put presents. Anything that doesn’t fit in there will have to be burned. And let’s suppose one of the following: (1) presents are infinitely tall or (2) presents may not be wrapped well and may contain fragile things. In either case, it’s clear you can’t stack them on top of each other. Over the course of the gift giving season you will to be presented with exactly 100 presents where each has a length and width between 5cm and 15cm (randomly distributed in that range using the Mac’s Random() function).
Each time you receive a present (via a callback function described below) you must first decide if you want to keep it or burn it. If you keep it you must decide where to put it in your storage area (and you can’t move it or remove it later once you’ve placed it). If you burn it then you will be preserving unused storage space for other presents you haven’t yet received (but burning the 100th present if you have room for it doesn’t make any sense cause that’s the last one you’re going to get). And you can’t put it aside and decide later; once you decide not to keep it and store it, it goes into the fireplace.
The goal is to store as many presents as possible (even if they’re all very tiny) so that when the day comes to open them all you have many things to open. The joy of opening one great big present is, for purposes of this challenge, short-lived and dwarfed by the joy of opening tens of small to medium sized presents. This challenge is not about code speed as much as it is about getting lots of presents (i.e. he who dies with the most toys wins this challenge).
The prototype of the function you write is:
void PackPresents(numPresents, nextPresentProc, storePresentProc) unsigned short numPresents; NextPresProcnextPresentProc; StorePresProc storePresentProc;
Where the two procs are defined as:
typedef void (*NextPresProc) (unsigned short *widthPtr, unsigned short *lengthPtr); typedef void (*StorePresProc) (unsigned short xPos, unsigned short yPos);
Your PackPresents routine should call nextPresentProc exactly numPresents times (which will be 100). For each present that it decides to keep it should call storePresentProc with the location it wants to store it. If you do not call storePresentProc before calling nextPresentProc again then the host calling you will assume you burned the last present it gave you. In addition, if you attempt to store a present at a place where there is already a present stored, the host will ignore your store request and will instead burn the present. Your PackPresents routine should return to the host after it has packed all it can or after numPresents have been asked for and dealt with.
Here’s a shell you might want to start with:
/* 1*/ void PackPresents(numPresents, nextPresentProc, storePresentProc) unsigned short numPresents; NextPresProcnextPresentProc; StorePresProc storePresentProc; { /* init storage area... */ i = numPresents; do { (*nextPresentProc)(&width, &length); canBeStored = blah... yesIWantIt = blah... if (canBeStored && yesIWantIt) { xPos = blah... yPos = blah... (*storePresentProc)(xPos, yPos); /* update storage area... */ } while (--i); }
and some example callbacks:
/* 2 */ MyNextPresProc (widthPtr, lengthPtr) unsigned short *widthPtr; unsigned short *lengthPtr; { *widthPtr = (abs(Random()) % 11) + 5; *lengthPtr = (abs(Random()) % 11) + 5; } MyStorePresProc (xPos, yPos) unsigned short xPos; unsigned short yPos; { if (/* no previous pres in the way */) gNumStored++; }
Good luck and may you get lots of presents!
TWO MONTHS AGO WINNER
Of the 17 entries I received for the ASCII85 Encoding challenge, only 6 worked perfectly. An additional 6 worked correctly except for the last few remainder bytes of input (where you have less than 4 bytes). Congratulations to James Goebel (location unknown) for his somewhat large but definitely fast entry. Right on his heels with an entry about half as large and nearly as fast was the Name No One Man challenge winner Stepan Riha (Austin, TX).
Here are the times for 2 tests and sizes of each entry. Numbers in parens after a person’s name indicate how many times that person has finished in the top 5 places of all previous programmer challenges, not including this one. A ‘*’ after a person’s name indicates someone whose solution worked correctly except for the last few remainder bytes (they were disqualified but there were so many of them and they were so close to working correctly that I decided to list them here).
Name bytes ticks 1 ticks 2
James Goebel 1302 77 143
Stepan Riha (4) 734 81 151
Larry Landry 442 94 175
Kevin Cutts 476 103 201
Allen Stenger (1) 438 113 208
Jeff Mallett (3) 446 119 221
Bob Boonstra (3) * 432 133 265
Steve Israelson (1) * 352 142 266
Tom Elwertowski (1) * 414 142 264
Dave Darrah * 300 152 284
Vladimir Makovsky * 212 202 379
Eric Josserand * 278 212 395
The key to writing a fast ASCII85 encoder is to come up with a clever way to multiply and divide by 85 and/or powers of 85. As you know, you want to do as little multiplication and division as possible if you want fast code. If you have a loop with a constant divisor, for instance, then you can usually craft a special piece of code that will outperform the 680x0’s built in divide instruction. Nearly every entrant in this challenge had come up with a clever way to multiply and divide by 85 or powers of 85. For example, take a look at second place winner Stepan Riha’s set of macros:
/* 3 */ /* Macros for mult with powers of 85 */ #define MultBy85_1(x) { \ /* x = x * 85^1; */ \ x += (x<<2); x += (x<<4); } #define MultBy85_2(x) { \ /* x = x * 85^2; */ \ register uLong a = (x<<3) + \ (x<<4) + (x<<5); \ x += a + (a<<7); } #define MultBy85_3(x) { \ /* x = x * 85^3; */ \ register uLong a, b;\ a = x + (x<<3); \ b = (a<<2) + (a<<6);\ x = (x<<12) + a + (a<<16) + b + \ (b<<5); } #define MultBy85_4(x) { \ /* x = x * 85^4; */ \ register uLong a, b; \ a = x + (x << 4) + (x << 5); \ b = (x << 7) + (x << 10); \ x = (x << 19) + a + (a << 20) + b + \ (b << 8); } /* Macros for x / (85^n) and x % (85^n). * The following are approximations for * the divisions: * x / 85^1 >= x * 3 / 2^8; * x / 85^2 >= x * 9 / 2^16; * x / 85^3 >= x * 27 / 2^24; */ #define AprxDiv85_1(x) (((x<<1)+x) >> 8) #define AprxDiv85_2(x) (((x<<3)+x) >> 16) #define AprxDiv85_3(x) (((x<<4)+(x<<3)+ \ (x<<1)+x) >>24)
I thought the description of how to handle the last few bytes of input in the October issue was clear but apparently I was wrong. Here’s an example. Suppose you want to ASCII85 encode the hex bytes 0x00, 0x01. Since you have less than 4 bytes you append two zero bytes to get 0x00, 0x01, 0x00, 0x00 as your 32 bits of input. You convert to 5 base 85 bytes and get 0, 0, 9, 6, 1. The algorithm says to output (n + 1) bytes where n is the number of input bytes (1 to 4), which is 2 in this example. So you add ‘!’ (33) to each of the first 3 bytes and output 33, 33, 42, followed by the end of input marker ~>. In fact, you didn’t even need to convert the last 2 base 85 bytes (6 and 1) because they weren’t used in the final output.
Here’s James’ winning solution:
/********************************************************* Author : Clement J Goebel III Routine converts bianary data to ASCII85 ascii format for transfering data via methods that are not bianary friendly, such as e-mail. Such that : (i1 * 256^3)+(i2 * 256^2)+(i3 * 256)+i4 == (o1 * 85^4)+(o2 * 85^3)+(o3 * 85^2)+(o4 * 85)+o5 The output must include one carrige return at least every 80 characters. This routine inserts a cr after every 8 longs of input, which represent at most 40 chars of output. It could be once every 16 longs of input representing at most 80 chars of output, but then the max line len could be interpereted as 81 characters. One other oddity of this implementation is that the output may begin with a newline char. The output buffer passed to the routine needs to account for the probable expansion of the data. Len(Output) = ((Len(Input)) * 5 + 3) / 4 + 2; plus room for the newline characters. *********************************************************/ #define ASCII_BANG '!' #define ASCII_Z 'z' #define ASCII_TILDE'~' #define ASCII_GREATER_THAN'>' #define ASCII_CR 0x0d #define INPUTS_BETWEEN_CR 0x07 #define k85 85L #define k85_2 7225L #define k85_3 614125L #define k85_4 52200625L /*------------------------------------------------------ The processor's general purpose division is slow, instead I use a routine that is accurate only for results between 0 and 127. And to avoid speed loss, which would result from calling the routine hundreds of thousands of times, it is inserted inline via a macro. Note this routine is only fast if all of the parameters, except lDivisor, are registers. lRemain starts as the number to divide and ends up containing the remainder. ------------------------------------------------------*/ #define DIV_ANS_LT_128( lRemain, lDivisor, lAns, lT ) \ { \ lT = (lDivisor << 6); \ \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x40; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x20; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x10; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x08; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x04; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x02; } \ lT = ( lT >> 1 ); \ if ( lRemain >= lT ) { lRemain -= lT; lAns += 0x01; } \ } /*------------------------------------------------------ ASCII85Encode ------------------------------------------------------*/ void ASCII85Encode( char *pcInput, unsigned long ulInputBytes, char *pcOutput, unsigned long *pulOutputBytes ) { unsigned char *pcIn = (unsigned char*)pcInput; unsigned char *pcOut = (unsigned char*)pcOutput; unsigned long *plIn; unsigned long ulIn; unsigned long ulOut; unsigned long ulInput; unsigned long l; unsigned long ulCRs; unsigned char ucC; ulCRs = ulOut = 0; ulIn = ulInputBytes >> 2; /* longwords to read */ if ( ((unsigned long) pcIn & 0x01 ) == 0 ) { /*------------------------------------------------------ Input data is word aligned ------------------------------------------------------*/ plIn = (unsigned long*)pcInput; while ( ulIn ) { if (((ulIn--) & INPUTS_BETWEEN_CR) == 0 ) { *pcOut++ = ASCII_CR; ulCRs++; } if ( ! ( ulInput = *plIn++ ) ) { *pcOut++ = ASCII_Z; ulOut++; } else { ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_4, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_3, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_2, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85 , ucC, l ); *pcOut++ = ucC; *pcOut++ = ulInput + ASCII_BANG; } } pcIn = (unsigned char*)plIn; } else { /*------------------------------------------------------ Else input data is NOT word aligned ------------------------------------------------------*/ while ( ulIn ) { if (((ulIn--) & INPUTS_BETWEEN_CR) == 0 ) { *pcOut++ = ASCII_CR; ulCRs++; } ulInput = (((unsigned long)(*pcIn++)) << 24); ulInput = ulInput | ((*(unsigned long*)pcIn ) >> 8 ); pcIn += 3; if ( ! ulInput ) { *pcOut++ = ASCII_Z; ulOut++; } else { ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_4, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_3, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_2, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85 , ucC, l ); *pcOut++ = ucC; *pcOut++ = ulInput + ASCII_BANG; } } } /*------------------------------------------------------ ulOut contains number of longs that were 0 ------------------------------------------------------*/ ulIn = ulInputBytes; l = (ulIn >> 2) - ulOut;/* l = # nonzero longs */ ulOut += ( l << 2 );/* add l * 4 */ ulOut += ( l ); /* one more for * 5 */ ulOut += ulCRs; /* # of carrige rtns */ ulOut++; /* for last carrige rtn */ /*------------------------------------------------------ take care of leftover tail end bytes ------------------------------------------------------*/ *pcOut++ = ASCII_CR; ulIn = ulIn & 0x03; if ( ulIn ) { ulInput = ((unsigned long)(*pcIn++)) << 24; if ( ulIn > 1 ) { ulInput = ulInput | ((unsigned long) (*pcIn++) << 16); if ( ulIn == 3 ) ulInput = ulInput | ((unsigned long) (*pcIn++) << 8); } ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_4, ucC, l ); *pcOut++ = ucC; ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_3, ucC, l ); *pcOut++ = ucC; if ( ulIn > 1 ) { ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85_2, ucC, l ); *pcOut++ = ucC; if ( ulIn == 3 ) { ucC = ASCII_BANG; DIV_ANS_LT_128( ulInput, k85, ucC, l ); *pcOut++ = ucC; } } ulOut += ( ulIn + 1 ); } /*------------------------------------------------------ write end of data marker ------------------------------------------------------*/ *pcOut++ = ASCII_TILDE; *pcOut++ = ASCII_GREATER_THAN; *pulOutputBytes = ulOut + 2; }
The Rules
Here’s how it works: Each month there will be a different programming challenge presented here. First, you must write some code that solves the challenge. Second, you must optimize your code (a lot). Then, submit your solution to MacTech Magazine (formerly MacTutor). A winner will be chosen based on code correctness, speed, size and elegance (in that order of importance) as well as the postmark of the answer. In the event of multiple equally desirable solutions, one winner will be chosen at random (with honorable mention, but no prize, given to the runners up). The prize for the best solution each month is $50 and a limited edition “The Winner! MacTech Magazine Programming Challenge” T-shirt (not to be found in stores).
In order to make fair comparisons between solutions, all solutions must be in ANSI compatible C (i.e., don’t use Think’s Object extensions). Only pure C code can be used. Any entries with any assembly in them will be disqualified (except for those challenges specifically stated to be in assembly). However, you may call any routine in the Macintosh toolbox you want (i.e., it doesn’t matter if you use NewPtr instead of malloc). All entries will be tested with the FPU and 68020 flags turned off in THINK C. When timing routines, the latest version of THINK C will be used (with ANSI Settings plus “Honor ‘register’ first” and “Use Global Optimizer” turned on) so beware if you optimize for a different C compiler. All code should be limited to 60 characters wide. This will aid us in dealing with e-mail gateways and page layout.
The solution and winners for this month’s Programmers’ Challenge will be published in the issue two months later. All submissions must be received by the 10th day of the month printed on the front of this issue.
All solutions should be marked “Attn: Programmers’ Challenge Solution” and sent to Xplain Corporation (the publishers of MacTech Magazine) via “snail mail” or preferably, e-mail - AppleLink: MT.PROGCHAL, Internet: progchallenge@xplain.com, CompuServe: 71552,174 and America Online: MT PRGCHAL. If you send via snail mail, please include a disk with the solution and all related files (including contact information). See page 2 for information on “How to Contact Xplain Corporation.”
MacTech Magazine reserves the right to publish any solution entered in the Programming Challenge of the Month and all entries are the property of MacTech Magazine upon submission. The submission falls under all the same conventions of an article submission.
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/img/search_text.gif)
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine