ADC #2 Results

Printable View

08-09-2003
Prelude

ADC #2 Results

Sorry about the crappy reviews. The code was a smidge too long and being rushed and sleepy makes for weird looking code. ;) Anyway, I'm pretty sure the scores are correct enough to determine winners:

Beginner
--------

KurtSerge - 39
XSquared - 40
vasanth - 35
ygfperson - 34

Winner: XSquared!

Intermediate
------------

XSquared - 5
vasanth - 20
Sean345 - 35
ygfperson - 32
ClownPimp - 39

Winner: ClownPimp!

Advanced
--------

XSquared - 5
vasanth - 20
ClownPimp - 36

Winner: ClownPimp!

The reviews will not include source code, and most of them won't have an extensive code review. Any contestants who want their code viewed should post it in reply to these results.

Concerning the next ADC, we'll take a break for me to catch my breath and resume shortly. Probably sometime in the next few days. Thanks for participating so far! :)
08-09-2003
Prelude

KurtSerge
---------

Beginner
--------

Summary: Good algorithm, noce and quick. Well done.

Code Review: None for this task

Correctness: 10
Speed: 9
Elegance: 10
Portability: 10
08-09-2003
Prelude

XSquared
--------

Beginner
--------

Summary: Good algorithm, well done. :)

Code Review: None for this task

Correctness: 10
Speed: 10
Elegance: 10
Portability: 10

Intermediate
------------

Summary: XSquared completely missed the point of arbitrary length numbers.

Code Review: Maybe it's just me, but declaring

Code:

typedef double Integer;

and then working with Integers using the built in arithmetic operators doesn't quite cut it. Expecially when my tests used number strings along the lines of "100000000000000000000000000000000000000000000 00". :p

XSquared also tried to return a locally declared array, thus crashing my test program. Not conductive to good scores, sorry.

Correctness: 0
Speed: 0
Elegance: 0
Portability: 5

Advanced
--------

Summary: XSquared completely missed the point of arbitrary length numbers.

Code Review: See Intermediate comments

Correctness: 0
Speed: 0
Elegance: 0
Portability: 5
08-09-2003
Prelude

vasanth
-------

Beginner
--------

Summary: Not bad, I expected the use of digRev from the last contest though. The only problem is that it slows things down a bit.

Code Review: I wondered about the use of n = n + rev(n);, it caught me off guard when n += rev(n); would work just as well and be less likely to trip up readers.

Correctness: 10
Speed: 7
Elegance: 9
Portability: 9

Intermediate
------------

Summary: Once again, the purpose is not to rename int to Integer, but to create a type that represents numbers of any length (until you run out of memory).

Code Review: None for this task

Correctness: 5
Speed: 5
Elegance: 0
Portability: 10

Advanced
--------

Summary: Once again, the purpose is not to rename int to Integer, but to create a type that represents numbers of any length (until you run out of memory).

Code Review: None for this task

Correctness: 5
Speed: 5
Elegance: 0
Portability: 10
08-09-2003
Prelude

Sean345
-------

Intermediate
------------

Summary: One of the few entries that actually did as requested. Nice algorithm, well implemented. Could be faster, but still nice. :)

Code Review: None for this task

Correctness: 10
Speed: 7
Elegance: 8
Portability: 10
08-09-2003
Prelude

ygfperson
---------

Beginner
--------

Summary: I like your attempt to "cut corners", but all in all the algorithm was the slowest of the batch.

Code Review: None for this task

Correctness: 10
Speed: 6
Elegance: 9
Portability: 9

Intermediate
------------

Summary: Nice algorithm. I like how you reused addInteger to implement subInteger.

Code Review: None for this task

Correctness: 8 (Works well in most cases)
Speed: 9
Elegance: 7 (Looks like a decent solution)
Portability: 8 (Uses C99 which isn't heavily implemented)
08-09-2003
Prelude

ClownPimp
---------

Intermediate
------------

Summary: The first entry to meet requirements as well as run quickly. Very nice work. :)

Code Review: None for this task

Correctness: 10
Speed: 10
Elegance: 10
Portability: 9 (Assumes that int can hold 1000000000)

Advanced
--------

Summary: Nice implementation, but the speed suffers considerably with longer numbers. A different algorithm could have solved this problem.

Code Review: None for this task

Correctness: 10
Speed: 8
Elegance: 9
Portability: 9 (Assumes that int can hold 1000000000)
08-10-2003
vasanth

wow.. i guess the question needs to be more specific.. because the question said "Integer are irrelevant as long as the interface is as above".. well i guess i did not bother about the length.. any way....

Nice review.. but the review style of previous contest was better...

and yes i would like my source to be reviewed so that i can learn and correct my mistakes..
08-10-2003
Prelude

>but the review style of previous contest was better...
I agree, but I was totally not feeling up to it at the time. And getting the results out by the deadline was my top priority. Sorry. :( I think maybe I'll hire Hammer or whoie or someone else who's pedantic to do the reviews when I'm overwhelmed. That's a good idea, I'll start taking applications immediately. :)

>because the question said "Integer are irrelevant as long as the interface is as above"
And right before that it said:

Quote:

Your task is to create an integer type of arbitrary length

Of course, I don't care if you simply typedef int as Integer and implement the interface that way, but you wouldn't get good scores because it wouldn't be able to handle arbitrary lengths.

>i guess the question needs to be more specific..
I don't see how I could be more so. I made it very clear that the tests would use very large numbers in three ways:

Quote:

makeInteger("12345");

By using a string, I imply that int, double, even long double are all too small to hold some values. This is a stretch, but still... ;)

Quote:

create an integer type of arbitrary length

This is the most explicit I could be.

Quote:

run in a reasonable amount of time for very large numbers

This tells you that I'm going to make sure it does so by actually using huge numbers.
08-10-2003
vasanth

thanx..
i think you can forget about my code review.. dont want to burden you.. When will the next contest start... Cant wait
08-10-2003
ygfperson

Why didn't my source compile? I don't have access to the microsoft C compiler, but GCC compiles it with no errors.

Oh... I used a variable length array in the program. It's allowed in C99, isn't it?

Anyway, uncomment the line 'zip_start = (block_t*)calloc... ', and comment the three lines below that one. This way it should run fine on all compilers.

(On another note, I needed to add a '+1' to every malloc and calloc (besides the char* one)... that's my own dumb mistake, and that'll probably crash the program with a false 'out of memory' error.)
08-10-2003
ygfperson

Here's the code with the changes I talked about
08-10-2003
XSquared

How come you didn't post the source code this time? I really wanted to see ClownPimp's source.
08-10-2003
Prelude

>I don't have access to the microsoft C compiler, but GCC compiles it with no errors.
I was in a hurry and didn't test it on GCC. However, VC++ 6 didn't like your use of max as a macro, nor your use of snprintf (which is only standard in C99). However, it is fast now that I've tested it, but it has a few problems with long strings of 0's. I'll update the scores.
08-10-2003
Prelude

Kudos to golfinguy who, sadly, submitted too late to be judged. However, the entry was creative (if difficult to expand upon and dangerous with unchecked array boundaries):

Code:

//very simple, just a look-up table int palNum(int i) { static int array[50]={0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 11, 33, 44, 55, 66, 77, 88, 99, 121, 22, 33 ,22, 55, 66, 77, 88, 99, 121, 121, 33, 44, 55, 33, 77, 88, 99, 121, 121, 363, 44, 55, 66, 77, 44, 99, 121, 121, 363, 484}; return *(array + i); }
08-10-2003
ygfperson

Quote:

Originally posted by Prelude
>I don't have access to the microsoft C compiler, but GCC compiles it with no errors.
I was in a hurry and didn't test it on GCC. However, VC++ 6 didn't like your use of max as a macro, nor your use of snprintf (which is only standard in C99). However, it is fast now that I've tested it, but it has a few problems with long strings of 0's. I'll update the scores.

k, thanks. :)
08-10-2003
*ClownPimp*

Hey Prelude, do you turn off compiler optimizations when you test the code?

Heres the source for those who care. I hope you can understand it, I didnt do hardly any commenting
08-10-2003
ygfperson

I'm just wondering...

Which would have been faster: using 4-byte integers to store 9 base-10 digits, or using all of the integer to hold a number? (ie: filling it with 32 base-2 digits)
08-10-2003
Prelude

>Hey Prelude, do you turn off compiler optimizations when you test the code?
Yes.

>Which would have been faster: using 4-byte integers to store 9 base-10 digits, or using all of the integer to hold a number?
It's easier to work with n base-10 digits than n base-2. You would have to jump through some hoops for base-2 and that could potentially slow things down, not to mention confuse the hell out of some readers. ;)
08-10-2003
golfinguy4

Quote:

Originally posted by Prelude
Kudos to golfinguy who, sadly, submitted too late to be judged. However, the entry was creative (if difficult to expand upon and dangerous with unchecked array boundaries):

Code:

//very simple, just a look-up table int palNum(int i) { static int array[50]={0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 11, 33, 44, 55, 66, 77, 88, 99, 121, 22, 33 ,22, 55, 66, 77, 88, 99, 121, 121, 33, 44, 55, 33, 77, 88, 99, 121, 121, 363, 44, 55, 66, 77, 44, 99, 121, 121, 363, 484}; return *(array + i); }

Yeah, I took your words to heart.;)

EDIT: BTW, what would that have scored?
08-11-2003
Prelude

>BTW, what would that have scored?
It could likely have won.