Re: python coding contest

Discussion in 'Python' started by Tim Hochberg, Dec 25, 2005.

  1. Tim Hochberg

    Tim Hochberg Guest

    Christian Tismer wrote:
    > 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


    >
    > 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, Dec 25, 2005
    #1
    1. Advertising

  2. Tim Hochberg <> wrote:
    ...
    > 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
    Alex Martelli, Dec 25, 2005
    #2
    1. Advertising

  3. Tim Hochberg

    Simon Hengel Guest

    > 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?

    Cheers, Simon

    --
    python coding contest - http://www.pycontest.net/
    Simon Hengel, Dec 26, 2005
    #3
  4. Simon Hengel <> wrote:

    > > 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, Dec 26, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Hengel

    python coding contest

    Simon Hengel, Dec 25, 2005, in forum: Python
    Replies:
    23
    Views:
    706
    Claudio Grondi
    Jan 2, 2006
  2. Simon Hengel

    Re: python coding contest

    Simon Hengel, Dec 25, 2005, in forum: Python
    Replies:
    92
    Views:
    1,425
    Alex Martelli
    Jan 2, 2006
  3. Christian Tismer

    Re: python coding contest

    Christian Tismer, Dec 25, 2005, in forum: Python
    Replies:
    4
    Views:
    295
    Alex Martelli
    Dec 26, 2005
  4. Tim Peters

    Re: python coding contest

    Tim Peters, Dec 26, 2005, in forum: Python
    Replies:
    0
    Views:
    422
    Tim Peters
    Dec 26, 2005
  5. Jean-Paul Calderone

    Re: python coding contest

    Jean-Paul Calderone, Dec 27, 2005, in forum: Python
    Replies:
    2
    Views:
    280
    Tim Hochberg
    Dec 28, 2005
Loading...

Share This Page