python coding contest
Simon Hengel
we are hosting a python coding contest an we even managed to provide a
price for the winner...
The contest is coincidentally held during the 22c3 and we will be
present there.
https://events.ccc.de/congress/2005/wiki/Python_coding_contest
Please send me comments, suggestions and ideas.
Have fun,
--
Simon Hengel
Christian Tismer
> Hello,
> we are hosting a python coding contest an we even managed to provide a
> price for the winner...
>
> http://pycontest.net/
Nice idea to have a contest, of course!
What I dislike a bit is the winning criterion:
Shortest possible Python module?
I'm envisioning lots of convoluted one-liners which
are more suitable to a different P-language... :-)
How about """best compromize between shortness and readibility
plus elegance of design"""?
Well, this slightly raises the skill level of the reviewers,
but will clearly make the results more enjoyable...
cheers - chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Simon Hengel
Hash: SHA1
> I'm envisioning lots of convoluted one-liners which
> are more suitable to a different P-language... :-)
I feel that python is more beautiful and readable, even if you write
short programs.
> How about """best compromize between shortness and readibility
> plus elegance of design"""?
I would love to choose those criteria for future events. But I'm not
aware of any algorithm that is capable of creating a ranking upon them.
Maybe we can come up with a solution. Any ideas?
Cheers, Simon.
- --
python coding contest - http://www.pycontest.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDrtFhd4QlweXdn3ERAn7tAJ9PEpOdqyfDhvHo7+TVy7RravwA/QCg4g9g
TdCYEDqOsL5qxQarsUI7jow=
=/KN6
-----END PGP SIGNATURE-----
Christian Tismer
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I'm envisioning lots of convoluted one-liners which
>> are more suitable to a different P-language... :-)
> I feel that python is more beautiful and readable, even if you write
> short programs.
>
>> How about """best compromize between shortness and readibility
>> plus elegance of design"""?
> I would love to choose those criteria for future events. But I'm not
> aware of any algorithm that is capable of creating a ranking upon them.
> Maybe we can come up with a solution. Any ideas?
Me neither :-)
Maybe a compromize proposal could be like this:
- Squeezing many lines into one using semicola does not help,
the program will be expanded to use one statement per line
- blank lines are allowed and not counted if they are not
needed as part of the code
- the length of names does not count, unless the code depends on it.
Some harmonization procedure might be applied to every solution
before counting lines, in order to avoid spectacular cryptic stuff.
I have no idea whether I'm serious about this.
Having this said, I'm trashing my one-liner :-))
if-it-doesn't-look-like-Python-it-is-not-Python - ly y'rs -- chris
Tim Hochberg
> Simon Hengel wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>>I'm envisioning lots of convoluted one-liners which
>>>are more suitable to a different P-language... :-)
>>
>>I feel that python is more beautiful and readable, even if you write
>>short programs.
>>
>>
>>>How about """best compromize between shortness and readibility
>>>plus elegance of design"""?
>>
>>I would love to choose those criteria for future events. But I'm not
>>aware of any algorithm that is capable of creating a ranking upon them.
>>Maybe we can come up with a solution. Any ideas?
>
>
> Me neither :-)
>
> Maybe a compromize proposal could be like this:
>
> - Squeezing many lines into one using semicola does not help,
> the program will be expanded to use one statement per line
>
> - blank lines are allowed and not counted if they are not
> needed as part of the code
These two would be easy to acomplish using something like:
def countchars(text):
n = 0
for line in text.split('\n'):
n += len(line.strip())
return n
This would ignore leading and trailing white space as well as blank lines.
Also makes
a=5; b=10
measure as one character longer than
a = 5
b = 10
which can only be good.
>
> - the length of names does not count, unless the code depends on it.
Probably too hard.
>
> Some harmonization procedure might be applied to every solution
> before counting lines, in order to avoid spectacular cryptic stuff.
I thought the metric was characters, not lines. At least that's what the
'about' page says. You still get hit by leading whitespace on multiple
line programs though.
-tim
Christian Tismer
> Christian Tismer wrote:
...
>> - Squeezing many lines into one using semicola does not help,
>> the program will be expanded to use one statement per line
>>
>> - blank lines are allowed and not counted if they are not
>> needed as part of the code
>
> These two would be easy to acomplish using something like:
>
> def countchars(text):
> n = 0
> for line in text.split('\n'):
> n += len(line.strip())
> return n
>
> This would ignore leading and trailing white space as well as blank lines.
>
> Also makes
>
> a=5; b=10
>
> measure as one character longer than
>
> a = 5
> b = 10
>
> which can only be good.
Good point!
>> - the length of names does not count, unless the code depends on it.
>
> Probably too hard.
I don't want to reward people for using ultra-short, unreadable
variable names, but also not to enable them to code algorithms
by them :-)
My idea was to rename all variables by a simple transformation
of the code objects, with the side rule that the program still works.
This can be automated rather easily.
> I thought the metric was characters, not lines. At least that's what the
> 'about' page says. You still get hit by leading whitespace on multiple
> line programs though.
So why not simply count length of code objects? :-)
Plus count every changeable name as one, others by length.
Same for constants, so we don't get tricked by encoding
the whole program by a tuple engine :-)
ciao - chris
Alex Martelli
...
> Maybe a compromize proposal could be like this:
>
> - Squeezing many lines into one using semicola does not help,
> the program will be expanded to use one statement per line
>
> - blank lines are allowed and not counted if they are not
> needed as part of the code
I would suggest that all whitespace (except within string literals)
should be ignored, as well.
Alex
Alex Martelli
...
> These two would be easy to acomplish using something like:
>
> def countchars(text):
> n = 0
> for line in text.split('\n'):
> n += len(line.strip())
> return n
>
> This would ignore leading and trailing white space as well as blank lines.
However, it would still make
a=23
"better" than
a = 23
and there's really no reason for that. I would instead suggest using
the tokenize module.
> > - the length of names does not count, unless the code depends on it.
>
> Probably too hard.
Ignoring the length of identifiers is easy if you're tokenizing anyway.
Checking if "the code depends on" the exact spelling of its identifiers
is a lot harder, admittedly -- you could try emitting a variant of the
code where all identifiers which are not builtins are systematically
replaced with 'x0001', 'x0002', etc, and verify that the variant still
passes the test, but it's definitely a nontrivial one. I think we'll
have to accept the fact that the "shortest program" will use one-letter
identifiers for everything except builtins.
> > Some harmonization procedure might be applied to every solution
> > before counting lines, in order to avoid spectacular cryptic stuff.
>
> I thought the metric was characters, not lines. At least that's what the
> 'about' page says. You still get hit by leading whitespace on multiple
> line programs though.
Definitely, characters. A high-granularity measure is essential to
reduce the chance of ties. Even so there may well be equal-first-place
winners -- hope they're not solved in terms of first submission, since
submitting at 14:00 UTC is WAY easier for Europe residents (residents of
the Americas would have to go to bed VERY late, get up VERY early, or
spend extra effort setting up cron jobs), and that would bias everything
in a most unfair manner.
Alex
André
I'm far from being a decent Python programmer but I managed (for fun)
to do it in a one-liner; however, it was definitely longer (in term of
number of characters) than the more readable multi-line solution.
André
Tobias Bell
> Neat idea!
Indeed
>
> I'm far from being a decent Python programmer but I managed (for fun)
> to do it in a one-liner; however, it was definitely longer (in term of
> number of characters) than the more readable multi-line solution.
I made a readable version with 352 bytes and a non-readable with 290
bytes. But it's a really ugly lambda, map, reduce kludge. Looks like Perl.
>
> André
>
Tobias
Steven D'Aprano
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I'm envisioning lots of convoluted one-liners which
>> are more suitable to a different P-language... :-)
> I feel that python is more beautiful and readable, even if you write
> short programs.
>
>> How about """best compromize between shortness and readibility
>> plus elegance of design"""?
> I would love to choose those criteria for future events. But I'm not
> aware of any algorithm that is capable of creating a ranking upon them.
What is your algorithm for determining "shortest" program? Are you
counting tokens, lines or characters? Does whitespace count?
--
Steven.
rbt
Christian Tismer
>> I would suggest that all whitespace (except within string literals)
>> should be ignored, as well.
> Good point, but i assume that is not possible with regular expressions.
No, but a trivial task using the compiler.
they should have taken this as a second challenge :-) -- chris
Simon Hengel
> should be ignored, as well.
Cheers, Simon
Steven D'Aprano
Yes, but the question is, is two lines and 347 characters ugly enough to
win?
--
Steven.
Simon Hengel
> reduce the chance of ties. Even so there may well be equal-first-place
> winners -- hope they're not solved in terms of first submission, since
> submitting at 14:00 UTC is WAY easier for Europe residents (residents of
> the Americas would have to go to bed VERY late, get up VERY early, or
> spend extra effort setting up cron jobs), and that would bias everything
> in a most unfair manner.
Not sure what to do about it, is there something more fair
than first come first serve?
Simon Hengel
> counting tokens, lines or characters? Does whitespace count?
like:
$wc -c seven_seg.py
At the moment we have to live with characters, and yes whitespace
characters do count. Sorry for that.
Have fun,
Simon Hengel
André Malo
> is two lines and 347 characters ugly enough to win?
Nope. 3 lines / 179 chars here >:->
Yes, it's quite unreadable.
(The problem is that I need to find an internet cafe on 28/29th in order to
be able to submit)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #########################
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () # André Malo #
=> @japh; # http://www.perlig.de/ #
rbt
Does positioning matter? For example, say I give it '123' is it ok to
output this:
1
2
3
Or does it have to be 123
Tim Hochberg
No. I have 8 lines and 175 chars at present. And, I expect that's gonna
get beaten.
-tim
Tim Hochberg
Is it necessary to keep the input parameter as 'input'? Reducing that to
a single character drops the length of a program by at least 8
characters. Technically it changes the interface of the function, so
it's a little bogus, but test.py doesn't check. (Personally I prefer
that if be illegal, but if it's legal I'll have to do it).
-tim
rbt
isn't the word 'input' a special word anyway???
Simon Hengel
> a single character drops the length of a program by at least 8
> characters. Technically it changes the interface of the function, so
> it's a little bogus, but test.py doesn't check. (Personally I prefer
> that if be illegal, but if it's legal I'll have to do it).
You may change input to something more short, like x. Everything that
passes the test, has a good chance to be accepted.
Cheers,
Simon Hengel
Justin Azoff
>>> len(c)
251
>>> len(c.replace(" ",""))
152
:-)
Knowing me, I'll forget to submit it.
Remi Villatel
>>is two lines and 347 characters ugly enough to win?
> Nope. 3 lines / 179 chars here >:->
> Yes, it's quite unreadable.
I'm in for the second place with 4 lines / 228 chars.
> (The problem is that I need to find an internet cafe on 28/29th in order to
> be able to submit)
Do your best! I'd really like to see your code. Right now, 179 chars
doesn't seem enough for me to write a "Hello world". ;-)
--
==================
Remi Villatel
maxilys_@_tele2.fr
==================
Steven D'Aprano
> * Steven D'Aprano wrote:
>
>> is two lines and 347 characters ugly enough to win?
>
> Nope. 3 lines / 179 chars here >:->
> Yes, it's quite unreadable.
I think Perl coders should be banned from this contest, as they have an
unfair advantage in that they have more experience with write-only code.
*grin*
--
Steven.
Alex Martelli
> Simon Hengel wrote:
> >> I would suggest that all whitespace (except within string literals)
> >> should be ignored, as well.
>
> > Good point, but i assume that is not possible with regular expressions.
>
> No, but a trivial task using the compiler.
Actually, the tokenize module of the standard library is plenty for this
(and any other merely lexical-level task).
> they should have taken this as a second challenge :-) -- chris
I guess there can be more challenges, particularly because I don't think
having the prize is really that important -- one does it for fun and
kudos (a nicely designed, color-printed certificate of victory, suitable
for framing and displaying prominently, would be better, if there are
funds to make it, than a keyboard which one might not use...;-).
Alex
Alex Martelli
> > Definitely, characters. A high-granularity measure is essential to
> > reduce the chance of ties. Even so there may well be equal-first-place
> > winners -- hope they're not solved in terms of first submission, since
> > submitting at 14:00 UTC is WAY easier for Europe residents (residents of
> > the Americas would have to go to bed VERY late, get up VERY early, or
> > spend extra effort setting up cron jobs), and that would bias everything
> > in a most unfair manner.
>
> Not sure what to do about it, is there something more fair
> than first come first serve?
Random choice between entries with identical number of characters would
be more fair, because "first come first served" strongly favours
European residents, given the timing at which entries are first
accepted, as I mentioned. Time of entry could be made a factor if the
geographical bias was removed (all entries in the first N hours of the
context could be considered as "postmarked" at the same instant, with N
computed so as to ensure some reasonable time in the evening for
residents of Asia and the Americas -- for later entries, using time of
submission is indeed fine).
If you just sent PDFs of a nicely designed color certificate of "First
Prize Ex Aequo" to all entrants who are tied for victory on the basis of
number of characters, I would not mind if the keyboard went to the
"first tied winner to submit" (since I'm not particularly keen to get
the keyboard, just the fun and kudos of claiming I'm the/a winner, in
the unlikely event my submission should be among the shortest;-).
Alex
Alex Martelli
> Tim Hochberg wrote:
> >
> > Is it necessary to keep the input parameter as 'input'? Reducing that to
> > a single character drops the length of a program by at least 8
> > characters. Technically it changes the interface of the function, so
> > it's a little bogus, but test.py doesn't check. (Personally I prefer
> > that if be illegal, but if it's legal I'll have to do it).
>
> isn't the word 'input' a special word anyway???
No, just the name of a builtin -- no problem overriding it.
Alex
Tim Hochberg
> André Malo wrote:
>
>
>>>is two lines and 347 characters ugly enough to win?
>
>
>>Nope. 3 lines / 179 chars here >:->
>>Yes, it's quite unreadable.
>
>
> I'm in for the second place with 4 lines / 228 chars.
>
>
>>(The problem is that I need to find an internet cafe on 28/29th in order to
>>be able to submit)
>
>
> Do your best! I'd really like to see your code. Right now, 179 chars
> doesn't seem enough for me to write a "Hello world". ;-)
>
I'm down to below 160 characters at this point. And 9 lines, so 22 of
those characters are leading white space or returns :( I'd really like
to get down to 150, but I'm having a hard time figuring where I can do
any more compaction.
-tim
Remi Villatel
> Does positioning matter? For example, say I give it '123' is it ok to
> output this:
>
> 1
> 2
> 3
>
> Or does it have to be 123
Download the test suite and you'll see that only 123 on one line passes
the test. Sorry...
Tim Peters
http://spoj.sphere.pl/problems/SIZECON/
the task is to come up with the shortest program that solves a
different problem. There's a twist in this one:
Score equals to size of source code of your program except symbols with
ASCII code <= 32.
So blanks, newlines and tabs aren't counted at all. However, no
"control characters" of any kind are counted, and I found a convoluted
way to transform any Perl program so that only 7 "readable" characters
remain. That's currently the shortest solution known (given the
stated metric -- my Perl source is actually over 400 bytes! all but 7
of them have ord < 33, though).
There's probably still room for improvement in the "shortest" Python
program known for this task. No deadlines, no prizes, and you don't
get to see anyone else's code, but as a form of programming
masturbation it's great ;-)
http://spoj.sphere.pl/problems/KAMIL/
is another program-size task, but this one counts all bytes.
phil_nosp...@yahoo.com
> No. I have 8 lines and 175 chars at present. And, I expect that's gonna
> get beaten.
I wasn't going to get into this, but I couldn't resist :).
I'm already behind though... 198 characters on 1 line. It's ugly, but
it works.
tar...@gmail.com
spaces/newlines. (it'd be three characters shorter if it didn't have
to end with a "\n")
-T. "unclean... unclean..."
Peter Otten
>> Is it necessary to keep the input parameter as 'input'? Reducing that to
>> a single character drops the length of a program by at least 8
>> characters. Technically it changes the interface of the function, so
>> it's a little bogus, but test.py doesn't check. (Personally I prefer
>> that if be illegal, but if it's legal I'll have to do it).
>
> You may change input to something more short, like x. Everything that
> passes the test, has a good chance to be accepted.
How good is "good" for
import test_vectors
seven_seg = test_vectors.test_vectors.get
or code using the test suite in general?
Peter
anonymous
Brian Beck
> are you importing zlib or bz2 ?
I don't think either of these would help in this case. While the
length of the compressed string might be significantly shorter than
your solution, the resulting string *literal* you decompress will
contain a bunch of \-escaped characters, so it will end up being longer.
Brian Beck
> length of the compressed string might be significantly shorter than
> your solution, the resulting string *literal* you decompress will
> contain a bunch of \-escaped characters, so it will end up being longer.
PS: I'm at 155, damn you taroso...
tar...@gmail.com
Nope - no imports at all. The horrible thing is it's NOT the the most
unpleasant piece of Python I've written.
-T. "A gentleman is someone who knows how to play the bagpipes but
doesn't"
André Malo
> are you importing zlib or bz2 ?
Haha, I've tried that myself. Funnily the bz2 result had exactly the same
length as the original. Code with that entropy is... nasty ;)
Still 179. It seems, I need to rethink the algorithm ;-)
nd
--
die (eval q-qq:Just Another Perl Hacker
:-)
# André Malo, <http://www.perlig.de/> #
Bengt Richter
>Hello,
>we are hosting a python coding contest an we even managed to provide a
>price for the winner...
^^^^^
>
How much are you going to sell him or her for? ;-)
Regards,
Bengt Richter
Tim Hochberg
> Currently I'm on 149 characters in <urgh> one line - 128 without
> spaces/newlines. (it'd be three characters shorter if it didn't have
> to end with a "\n")
It'll be interesting to see what the short 1-line answers look like. I
have a hard time seeing how that's done. It'll especially be interesting
to see if we're all using similar tricks or if the multiline attemps
take a distinctly different tack than the single line attempts.
Currently, I'm down to 137 characters now in 6 lines. There's very
little left to trim at this point, so I don't know that I'll be able to
knock it down any further using my current approach. And since I don't
have any other approaches in the wings, I may be about washed up.
-tim
André Malo
> Currently, I'm down to 137 characters now in 6 lines. There's very
> little left to trim at this point, so I don't know that I'll be able to
> knock it down any further using my current approach. And since I don't
> have any other approaches in the wings, I may be about washed up.
grmpf. Just reached 143 chars / 2 lines ;-)
There seems to be some more room for optimization...
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://pub.perlig.de #
Yaccck
You guys are pretty agressive!
Dody Suria Wijaya
lines. hint please... :D
Claudio Grondi
shortest program beeing able to output own source was the job to code.
The jury had a big trouble to justify why not give the prize to the one
who posted an empty file ...
I am currently at 39 bytes following the requirements and the principle
given above (my module passes the test). Anyone able to beat that?
Claudio
Tim Hochberg
> Peter Otten wrote:
[SNIP]
>>How good is "good" for
>>
>>import test_vectors
>>seven_seg = test_vectors.test_vectors.get
>>
>>or code using the test suite in general?
>>
>>Peter
>>
>
> This started to remind myself about the story of the contest where the
> shortest program beeing able to output own source was the job to code.
> The jury had a big trouble to justify why not give the prize to the one
> who posted an empty file ...
>
> I am currently at 39 bytes following the requirements and the principle
> given above (my module passes the test). Anyone able to beat that?
Wow! It'll be interesting to see how to do that. The obvious way gives
53 bytes. Hmmm, I'll have to see what can be done...
However they do say "We use a very *similar* test suite to either accept
or reject pending submissions." (Emphasis mine) So, it's possible, even
probable, that the file test.py either won't be available or won't be
helpful.
-tim
Duncan Booth
I think my main interest will be to see what different algorithms are
successful. I suspect I may have chosen the wrong approach to start with
since I stuck at 150 characters (1 line, no extraneous whitespace), but
then I started again with a different algorithm and I'm down to one line of
137 characters but nowhere obvious to go from there...
Malte Dik
Wouldn't using test_vectors.py somehow be lame?
Steven D'Aprano
> Claudio Grondi wrote:
>> I am currently at 39 bytes following the requirements and the principle
>> given above (my module passes the test). Anyone able to beat that?
>
> Wow! It'll be interesting to see how to do that. The obvious way gives
> 53 bytes. Hmmm, I'll have to see what can be done...
OBVIOUS???
The only algorithm obvious to me came to two lines and about 300
characters with all the pruning I could come up with. Changing algorithms
made it longer. I am finding it hard enough to credit that half a dozen
people are claiming lengths of around 130-180 characters -- 39 or 53 bytes
just seems physically impossible to me, especially given that nine of
those bytes are the name of the function!
The identity function seven_seg=lambda s:s takes 20 bytes and does
nothing. That leaves NINETEEN bytes to implement the functionality. In the
immortal words of Bill and Ted: "No way dude!"
You excellent dudes are righteously bodacious!
--
Steven.
Christian Tismer
> On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:
>
>> Claudio Grondi wrote:
>
>>> I am currently at 39 bytes following the requirements and the principle
>>> given above (my module passes the test). Anyone able to beat that?
>> Wow! It'll be interesting to see how to do that. The obvious way gives
>> 53 bytes. Hmmm, I'll have to see what can be done...
>
> OBVIOUS???
The obvious way seems to be to import the test_vectors.py file,
which gives me
import test_vectors as x;seven_seg=x.test_vectors.get
as one possible "obvious" solution with 53 chars.
But
from test_vectors import*;seven_seg=test_vectors.get
has only 52.
And if you observe that their "test.py" file already does
all the imports we want, you can get to
from test import*;seven_seg=test_vectors.get
with 44 chars.
But I simply cant see how to get below that.
And I think this is not the wanted solution at all,
which is why I have no problem posting it here :-)
ciao - chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/