[Purdue-pm] perl quotw
Mark Senn
mark at ecn.purdue.edu
Wed Mar 24 07:40:51 PDT 2010
Rick Westerman <westerman at purdue.edu> wrote Wed, 24 Mar 2010 09:05:04 -0400
> Yes, that is a good one. Let's use it for the April challenge. I
> am not sure how we will judge the quality of the programs. It seems
> to me (without actually having written the program) that the run time
> will be in the seconds (or less). Perhaps we can judge on (a)
> "beauty" of the code and (b) robustness -- I have a couple ideas in
> regards to difficult or invalid input. In any case this is suppose
> to be a learning exercise for all and not a "my code is better than
> your code" contest.
>
> See you April 20th!
I'm not sure how we will judge the quality of the programs either.
The specs at
http://perl.plover.com/qotw/r/006
are too loose. Are only positive integers allowed? Will format_number_list
input always use numbers instead of strings so wo don't have to worry
about positive integers specified as, for example, '--42'? Will the input
to the functions always be in sorted order? What should happen with no input?
What should expand_number_list do with zero length input? And so on.
I suggest we use
YES (is checked before function is called, smallest number used is 1,
largest 1000---for extra credit, smallest number used is 1,
largest a google (1 followed by 100 zeroes))
YES (is checked before function is called)
YES (so any sorting won't have to be part of any "Big O" discussions,
sorted order checking is done before the functions are called)
CAN'T HAPPEN (is checked by other code before the functions are called)
CAN'T HAPPEN (is checked by other code before the functions are called)
Other questions assume the simple case of specified input like the
example with no other complications.
(I'll be doing a Big O (see http://en.wikipedia.org/wiki/Big_O_notation)
analysis of my solution for time and space.)
-mark
More information about the Purdue-pm
mailing list