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/
> 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?
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
- 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 -- 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/
>>>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.
>> - 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
-- 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/
> 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.
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'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.
On Sun, 25 Dec 2005 18:05:37 +0100, 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.
What is your algorithm for determining "shortest" program? Are you counting tokens, lines or characters? Does whitespace count?
Steven D'Aprano wrote: > On Sun, 25 Dec 2005 18:05:37 +0100, 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.
> What is your algorithm for determining "shortest" program? Are you > counting tokens, lines or characters? Does whitespace count?
If whitespace and var names count, these things are going to be ugly :)
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.
they should have taken this as a second challenge :-) -- 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/
On Sun, 25 Dec 2005 19:14:43 -0500, rbt wrote: > Steven D'Aprano wrote: >> On Sun, 25 Dec 2005 18:05:37 +0100, 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.
>> What is your algorithm for determining "shortest" program? Are you >> counting tokens, lines or characters? Does whitespace count?
> If whitespace and var names count, these things are going to be ugly :)
Yes, but the question is, is two lines and 347 characters ugly enough to win?
> 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?
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).
> 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).
> 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.
|
