Dec 93 Challenge
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 its time to figure out how to most efficiently store all the presents youre going to receive. Lets suppose you have a 100cm x 100cm area where you can put presents. Anything that doesnt fit in there will have to be burned. And lets 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, its clear you cant 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 Macs 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 cant move it or remove it later once youve placed it). If you burn it then you will be preserving unused storage space for other presents you havent yet received (but burning the 100th present if you have room for it doesnt make any sense cause thats the last one youre going to get). And you cant 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 theyre 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.
Heres 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 persons 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 persons 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 680x0s 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 Rihas 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. Heres 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 didnt even need to convert the last 2 base 85 bytes (6 and 1) because they werent used in the final output.
Heres 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
Heres 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., dont use Thinks 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 doesnt 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 months 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.