Re: Beyond Golf - reading between the tokens
by gjb (Vicar) on Dec 28, 2002 at 01:27 UTC
|
- That will cost you a penny ;-)
- Such a competition would be nice since it's more "semantic" than "pure golf" and should yield nicer code.
- What about the semi-colon, I'd guess it doesn't count? It should be possible to automate the count using a lexer for Perl if it isn't sensitive to $$a[0] vs. $a->[0] et al. differences.
- How about Croquet?
- At least 5, but I guess you held back a little ;-)
How about Polo, getting the task done fastest using Benchmark.pm?
Just my 2 cents, -gjb-
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
The semicolon is an interesting case. I'm leaning towards not counting it, as I can't think of a case where the shorter of two solutions would turn out to be longer depending on semicolon sensitivity. If such a case exists, this would take further thought.
As for automated counting, my idle musing was to abuse the Perltidy code for that purpose.
I don't like the Benchmark.pm idea - you'd have to specify the exact environment (Perl version+patches, OS, hardware, modules' versions) to be able to decide on a reproducibly and unambiguously winning entry. It's just too fickle a goal.
Makeshifts last the longest.
| [reply] [Watch: Dir/Any] |
|
The Benchmark.pm idea could be done if the code were submitted to run on a particular computer, if someone is crazy enough to risk something like that ;-)
Seriously, it could be done in the sense that everyone is able to confirm the results on his own machine with its specific setup. The format of submission would be a function that can be run using Benchmark so that the "competition" could be compared by just pasting the code and running the benchmarks.
I agree that you won't see a clear winner, but it would give those of us interested in raw performance a number of alternative implementations and hence an opportunity to learn. It's all about taking part, not about winning ;-)
Just my 2 cents, -gjb-
Update: It would be possible to get a machine/OS/etc. independent comparison by using some "gauge code", ie. a standard piece of code. The benchmark for the Perl Polo code would then be calculated proportional to the time it takes the "gauge code" to execute.
| [reply] [Watch: Dir/Any] |
Re: Beyond Golf - reading between the tokens
by MarkM (Curate) on Dec 28, 2002 at 07:44 UTC
|
Like obfuscation, golf is an art. Most excellent golf entries are the result of evolution, experimentation, and creativity - the solution is not approached the same way one would approach a practical programming problem. Fewest characters is actually a sensible criteria as it adds a fun twist that skews the rules sufficiently to ensure that the game is not boring. Experienced programmers no longer have an untouchable edge when it comes to golf.
If another scoring mechanism was used, my personal preference would be - fewest nodes in the compiled op tree. Of course, this breaks down when eval"" is used, but the idea still stands - the eval"" case is just hard to calculate.
| [reply] [Watch: Dir/Any] |
|
Yes, I thought about eval, that would need special rules indeed. The "nodes in the compiled tree" approach is a good proposal - I was trying to formulate the rules in such a way as to be unambiguous, and that would be a watertight way to get it right. Kudos to Juerd for a great suggestion on how to implement that with very little effort.
As to the point, it's true that these rules favour experienced programmers, but then these folks tend to be hard to beat in the pro league anyway. What usually leaves me unsatisfied at least about most simpler golf challenges is that concise in terms of expressiveness approaches tend to be too long when written out, so simplistic, brute force approaches, often really hackish ones, are favoured.
Basically, what I'd like to see is a challenge to use the language's expressive power to the maximum.
Makeshifts last the longest.
| [reply] [Watch: Dir/Any] |
Re: Beyond Golf - reading between the tokens
by Juerd (Abbot) on Dec 28, 2002 at 12:51 UTC
|
perl -MO=Concise -e'foo' | wc -l
Example:
5;0 juerd@atlas:~$ perl -MO=Concise /usr/bin/cpanp | wc -l
/usr/bin/cpanp syntax OK
260
The cpanp binary has a score of 260.
5;0 juerd@atlas:~$ perl -MO=Concise -e'$t' 2> /dev/null | wc -l
5
5;0 juerd@atlas:~$ perl -MO=Concise -e'$$t' 2> /dev/null | wc -l
6
5;0 juerd@atlas:~$ perl -MO=Concise -e'$$t[0]->{x}' 2> /dev/null | wc
+-l
11
5;0 juerd@atlas:~$ perl -MO=Concise -e'$$t[0]{x}' 2> /dev/null | wc -l
11
5;0 juerd@atlas:~$ perl -MO=Concise -e'print $$t[0]{x}' 2> /dev/null |
+ wc -l
13
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
|
I thought of that too, but it does have some problems. Eval-string is very cheap in that accounting. print 'a'.'b'; is cheaper then print 'a','b'; (the former constant-folds to print 'ab';).
This is why print "a"."b"; is faster and more efficient than print "a","b";. I think it is *good* to have the former be less points.
When not using constants, it's a different story: print "a".$_; is 9 concise-lines while print "a",$_; is 8.
I think eval-string should be avoided anyhow, in a golf contest like this one.
- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|