 |
esoforum.kidsquid.com Esoteric programming forum
|
View previous topic :: View next topic |
Author |
Message |
calamari Site Admin

Joined: 21 Jan 2005 Posts: 161 Location: Tucson, Arizona
|
Posted: Sat Nov 05, 2005 2:44 pm Post subject: Brainf***: Canonical non-context-free language (Nov 7-Dec 5) |
|
|
If you notice any typos, ambiguities, or problems, please let me know. Thanks a lot, and enjoy the competition.
Task
Write a Brainf*** program that accepts the language:
L := { ai bj ck : i = j = k }
Where a, b, and c are the ASCII characters 'a', 'b', and 'c'.
The language accepts the set of all input strings consisting of a
sequence of a's, followed by a sequence of b's, followed by a sequence
of c's, having the same number of a's, b's, and c's. All other strings
are rejected. It is considered the canonical example of a
non-context-free (stack based) language, meaning that it may only be
computed by a machine equivalent in power to a Turing machine. Since
BrainF*** is Turing complete, it should be up to the task.
Examples
The string 'aaaabbbbcccc' is in the language L, as it is a4b4c4, so i = 4, j = 4, and k = 4, thus i = j = k.
The string 'aaabccc' is not in the language L, as i = 3, j = 1, k = 3, and so i ≠ j.
The string 'bac' is not in the language L, despite i = j = k, as it
is not a sequence of a's, followed by b's, followed by c's. Similarly,
'abcabc' is not in the language L, as 'a' cannot follow 'c'.
The input 'ab' is valid input, but is not in the language L, as j =
1 and k = 0, so j ≠ k. Any arrangement of a's b's and c's is valid
input string, but not all strings are in the language L, as above.
The empty string '' is in the language L, as i = j = k = 0.
Input and Output
The input may be assumed to consist only of the letters 'a', 'b',
'c', and '\n' (newline character). Other input is undefined and will
not be considered for the purposes of the contest.
Input consists of a string of 'a', 'b', and 'c' characters (as given in
the above examples), terminated by '\n' (the newline character,
linefeed ASCII character 10, NOT the characters '\' 'n'). Every string,
including the empty string, must be followed by the newline character.
Once the '\n' newline character is detected, no further input may be
read. It is not necessary to read all the input (for example, if a
determination can be reached before the newline is encountered).
The program output must be one of: 'accepted\n' (meaning that the
string was found to be in the language L) or 'rejected\n' (the string
was not in the language L), where '\n' is again the newline character.
The input string may be of any length. Therefore, imposing an
arbitrary limit, such as accepting a maximum of 255 a's, is unwise. It
should be assumed that this will be tested with extremely long inputs.
Language details
The interpreter used will have 8-bit memory cells. Memory will be
unbounded to the right (within the limits of the machine it is being
run on). Programs must not wrap cell values (either by executing '-' on
a cell with the value 0 or '+' on a cell with the value 255). Programs
must not wrap the memory array (by executing '<' at cell 0).
Scoring
The winning entry must first be correct. If an entry does not conform to the above specification, it is disqualified.
Ranking is then by the shortest stripped code length (only counting
Brainf*** instructions). If two programs are tied in code length, the
winner shall be the program that was submitted first.
Multiple entries are allowed. Entry corrections will require a new entry. Do not modify old entries.
Reference interpreter and code stripper
I have provided a compliant Brainf*** interpreter at http://kidsquid.com/programs/bf/bfgolf.tar.gz or, if you prefer, http://kidsquid.com/programs/bf/bfgolf.zip.
It requires an ANSI C compatible compiler. Also included is a program
that strips a program of all non-Brainf*** characters. Please let me
know if you run into any problems.
Contest deadline
The contest will start Monday, November 7, and end Monday, December 5,
11:59pm, and entries will be scored. Please do not post code until
after the ending time. Contest entries should be posted to this thread
in the form of an md5 hash. Please also include the stripped length of
the program. The date and time of the forum will be considered the
official date and time for the contest and contest entries. Once the
contest has ended, entries will be matched against their MD5 hash. Any
found to be different will be disqualified.
Prizes
The contest winner will receive a free abacus by mail. It is a
generic abacus with 9 rods. I reserve the right not to award the prize
if there is only a single contest entry.
Have fun!
calamari
Last edited by calamari on Sat Nov 12, 2005 12:38 pm; edited 5 times in total |
|
Back to top |
|
 |
lvl
Joined: 06 Nov 2005 Posts: 1
|
Posted: Sun Nov 06, 2005 1:59 am Post subject: |
|
|
you didn't define the ASCII value of '\n'. is it 10, or 13?
Laurent |
|
Back to top |
|
 |
ORBAT Guest
|
Posted: Sun Nov 06, 2005 2:03 am Post subject: newline |
|
|
Isn't the "standard" interpretation supposed to be that 10 (LF) == \n?
Like anyone adheres to standards in the esoteric world anyhow :) |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Sun Nov 06, 2005 7:34 am Post subject: |
|
|
Indeed, it's not defined, but I'd say it's 10. |
|
Back to top |
|
 |
jix
Joined: 05 Nov 2005 Posts: 1
|
Posted: Sun Nov 06, 2005 7:44 am Post subject: |
|
|
\n is newline
\r is carriage return
ascii defines newline as 10 and carriage return as 13... where is the problem? |
|
Back to top |
|
 |
ORBAT Guest
|
Posted: Sun Nov 06, 2005 11:10 am Post subject: |
|
|
Gotcha!
At least in C \n does NOT equal LF
(10). It's implementation-specific, and when you're reading or writing
a file in text mode, it translates to the implementation's native
newline (CR for old Macs, CR+LF for Windozes, LF for UN*X). When you're
using binary mode, it translates to LF.
The problem here is that all versions of Windows use CR+LF as their
newline character, so any BF interpreter that assumes 10 to be "\n",
will be caught off guard by the extra 13 that comes around the corner.
I love standards: there's so many of them |
|
Back to top |
|
 |
calamari Site Admin

Joined: 21 Jan 2005 Posts: 161 Location: Tucson, Arizona
|
Posted: Sun Nov 06, 2005 10:33 pm Post subject: |
|
|
Let's use '\n' = 10. |
|
Back to top |
|
 |
calamari Site Admin

Joined: 21 Jan 2005 Posts: 161 Location: Tucson, Arizona
|
|
Back to top |
|
 |
calamari Site Admin

Joined: 21 Jan 2005 Posts: 161 Location: Tucson, Arizona
|
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Sat Nov 12, 2005 12:33 pm Post subject: This ought to do the job.. |
|
|
Here's my first submission.
Keymaker
15f3841715a134387bc663687daf6167
(Edit by calamari: entry was approximately 570 bytes, original timestamp before I edited was 12 Nov 2005 12:33 pm) |
|
Back to top |
|
 |
calamari Site Admin

Joined: 21 Jan 2005 Posts: 161 Location: Tucson, Arizona
|
Posted: Sat Nov 12, 2005 12:44 pm Post subject: |
|
|
It
seems that I forgot to request a length with entries. I've amended the
rules... so any further entries will require a program length as well.  |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Tue Nov 22, 2005 1:43 pm Post subject: |
|
|
Here's my second entry. I finished this one days ago, but finally got myself posting it.
Keymaker
3792badda159e66d363aec0f4b7d52e1
402 bytes
|
|
Back to top |
|
 |
Bertram Guest
|
Posted: Fri Dec 02, 2005 7:41 pm Post subject: |
|
|
Here's my first entry - I've finally got around to code one :)
Bertram (int-e)
f1b04426325ad75f0d06872bdd3f4481
349 bytes |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Sat Dec 03, 2005 3:50 am Post subject: Aaaaaaargh! |
|
|
I just knew this would happen.. Well, enjoy your abacus.. |
|
Back to top |
|
 |
Bertram Guest
|
Posted: Sat Dec 03, 2005 8:37 pm Post subject: |
|
|
Some hours of micro-optimization later ...
Bertram (int-e)
1aaa945c464dec3ac855434befa15a80
332 bytes |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Sun Dec 04, 2005 5:59 am Post subject: My third and my last. |
|
|
This
entry isn't very big improvement to my previous entry; it's only two
instructions smaller. Oh well, at least the amount of instructions in
this one is a nice number.
Keymaker
08eec49920ac38499f569c9c3feb0aae
400 bytes
|
|
Back to top |
|
 |
Bertram Guest
|
Posted: Sun Dec 04, 2005 6:03 am Post subject: |
|
|
This will probably not cause problems, but the
Code: | realloc(mem, (maxmp + 1024) * sizeof(unsigned char)) |
should be
Code: | realloc(mem, (maxmp + 1 + 1024) * sizeof(unsigned char)) |
or maxmp should be one larger throughout the program - that'd be more C-like |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Mon Dec 05, 2005 4:35 am Post subject: Hello. |
|
|
I procrastinated as usual, but here's my first entry
Daniel Cristofani
266 bytes
d20b981fbed760f6ee25e8c0f577fda0 |
|
Back to top |
|
 |
Guest
|
Posted: Mon Dec 05, 2005 5:48 am Post subject: Re: Hello. |
|
|
Congratulations. I can't wait to see how you did it :)
Bertram |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Mon Dec 05, 2005 7:33 am Post subject: Nice job. |
|
|
Woah, now there's some byte-magick! Can't wait either. |
|
Back to top |
|
 |
Guest
|
Posted: Mon Dec 05, 2005 3:40 pm Post subject: |
|
|
It's
great to see so many entries.. I'm afraid I probably won't be able to
personally enter before the deadline (I really wanted to). Too much
going on.
I will be able to write up testcases and judge the entries after finals
week (so basically a couple weeks from now). Or, if I have time, I'll
do it sooner
Good luck everyone!
calamari
Edit: hmm why I am I not logged in.. ahh well, hehe |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Mon Dec 05, 2005 10:06 pm Post subject: |
|
|
Second
entry. By the way, this problem actually doesn't need a Turing-complete
language; a language with power equivalent to a linear bounded
automaton will do.
Daniel Cristofani
263 bytes
9654d61a53a7d779253113425acd1c68 |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Tue Dec 06, 2005 12:11 am Post subject: Okay. |
|
|
Since it's just past the deadline, here's the code for my second entry.
Daniel Cristofani
263 bytes
+>+>>+[,-[>++++<[[->]<<]<[>]>]>[-[<<<+>+>+>-]<<<-[-[-[<[-]>-]]]+++>[<->-]>[-[>]+>]>>>[>>>]+[<<<]<[-<]>+<]>]+<+<+[>>+>]<<[>+>>]<<[<<<]+<<[>>+>]>>[>>>]>+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<-[-[-[>>.++..++.<--.++>>]]]>[.>++++.+++++.-----.--.++>>]<<<++.>.-.>>>. |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Tue Dec 06, 2005 12:53 am Post subject: more formatted code |
|
|
Code: | +>+>>+[
,-[>++++<[[->]<<]<[>]>]>[
mod 5
cutdown
-[<<<+>+>+>-]<<<-[-[-[<[-]>-]]]+++>[<->-]
compare and prev=current
>[-[>]+>]>>>[>>>]+[<<<]<[-<]>+<
increment appropriate stack
]>
]+<+<+[>>+>]<<[>+>>]<<[<<<]+<<[>>+>]>>[>>>]
fuse stacks
>+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<< setup for print
-[-[-[>>.++..++.<--.++>>]]]
print
"accep"
>[.>++++.+++++.-----.--.++>>]
print "rejec"
<<<++.>.-.>>>.
print "ted\n" |
And an explanation. My basic method was to keep count of the number of
'a', 'b', and 'c' using three interspersed stacks of cells set to 1.
Also a flag which starts with a value of 1, but is zorched if any input
letter has a smaller ASCII value than the preceding one. This continues
until a linefeed is read. I tried a variety of methods for cutting the
ASCII values down to size, and for comparing each number with the
previous one, but I didn't try all possible combinations and it didn't
seem to change the total outcome by more than 15 bytes or so anyway.
The method used in this submission uses a distorted mod-5 operator
to cut the ASCII values down, resulting in a value of a=2, b=1, c=0;
whereas the previous value is stored in the form a=1, b=2, c=3. Thus,
the previous letter had a larger ASCII value if (prev+current) > 3;
this is a mildly counterintuitive comparison operation. The overall
data layout is
flag prev x x x 0 c b a c b a c b a c b a ... where "x" are cells
used during the process of reading the current value and comparing it
with the previous.
Once the linefeed is read, my original plan was to merge all three
stacks into a single stack, and merge the flag with them; if the last
cell of the combined stack has a value of 4, the string is accepted;
otherwise, it is rejected. I ended up using a slight variant of that
method, as it happens.
Further questions or comments welcomed.
-Daniel Cristofani. |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Tue Dec 06, 2005 3:34 am Post subject: |
|
|
Woah, very nice! :) I need to inspect it a bit more to understand it fully, though. Seems we have quite a different solutions.
Here is my first entry, 574 instructions (yes, I'm embarassed):
+>>>>>+>+++<<,----------[-----<<+>+++++++++[>---------<-]+>[-<->>>>+>+<<<<[[-]<+>>>>->-<<<<]]<[<<<->>>-]>]<<[>>+<<-]+>>[-[----<+++++++++[>---------<-]>[<+<<+>>>-]<++<[>-<-]<[>+<-]+>>[-[-<<->>[->+<[-<<+>>>-<]]]]<<[-<[-]>>>>[<+>-]>>[>>]<<[[-]+<<]<[>+<-]<<]>>>[->[>>]<<[-<<]>>+<]>[>>]+>+<[<<]>],----------]>>[>>]<<[>+<[-[-[->[-]<]]]>[[-]<<<[<<]<<<<[-]>>>>>>[>>]>]<<<]<<<+<[>++++++++[<+++++++++++>-]<---.++..++.+++++++++++.++++.---------------.-.[-]++++++++++.[-]]>[+++++++++[<+++++++++++>-]<++++.-------------.+++++.-----.--.+++++++++++++++++.---------------.-.[-]++++++++++.>]
Here is my second entry, 402 instructions:
+>>>>>+>+++<<+[-[----<+++++++++[>---------<-]>[<+<<+>>>-]<++<[>-<-]<[>+<-]+>>[-[-<<->>[->+<[[-]<<+>>>-<]]]]<<[-<[-]>>>>>>[>>]<<[[-]+<<]<<<]>>>[->[>>]<<[-<<]>>+<]>[>>]+>+<[<<]>],----------]>>[>>]<<[>+<[-[-[->-<]]]>[-<<<[<<]<<<<[-]>>>>>>[>>]>]<<[-]<]<<[-]<+<[+++++++++++++++[>++++++>+++++++<<-]>.++..++.>.++++.<.-.[-]<]>[+++++++++++++[>+++++++>++++++++<<-]>>++.<+++.+++++.-----.--.>++.<++.-.<]++++++++++.
And here is the third, that is only two instructions shorter than the previous, thus 400 instructions:
+>>>>>+>+++<<+[-[-<++++++++++++[>-------<-]>[<+<<+>>>-]<++<[>-<-]<[>+<-]+>>[-[-<<->>[->+<[[-]<<+>>>-<]]]]<<[-<[-]>>>>>>[>>]<<[[-]+<<]<<<]>>>[->[>>]<<[-<<]>>+<]>[>>]+>+<[<<]>],----------]>>[>>]<<[>+<[-[-[->-<]]]>[-<<<[<<]<<<<[-]>>>>>>[>>]>]<<[-]<]<<[-]<+<[+++++++++++++++[>++++++>+++++++<<-]>.++..++.>.++++.<.-.[-]<]>[+++++++++++++[>+++++++>++++++++<<-]>>++.<+++.+++++.-----.--.>++.<++.-.<]++++++++++.
It was a nice competition overall.
Daniel, please post the picture of that abacus on your site when you receive it. :) Congratulations. |
|
Back to top |
|
 |
Bertram Guest
|
Posted: Tue Dec 06, 2005 4:49 am Post subject: |
|
|
First entry:
+>+>>+[->>>++++++++[<+++++++++++>-],----------]<[-]<+<[>-<[[<->-]+<[->->+<<[->>->+<<<]]<<]>>>>>[>>>]<[>>>]+<[>>>]+>>[<+>-]<[<->[-]]<[[[[>>>]<<<-<<<[<<<]+<<<[>>>-<<<-]>>>]<<[>>>>]>>>[>>>]<]>>[>]>>[<+>-]<[<+>-]<[>>]<[<<<]]]>>[-]>[-]++>[-]+++++++++++[<<<<+>>+++++++++>++++++++++>-]<<<[>--.++..++.>.>>[-]]<[>>>++.--<++.+++++.-----.--.++>>]<++++.<.-.<<-.
Second entry:
>+[->>>,<++++++++++[<+++++++++>>-<-]>]<<<[[[>-<-]>-[[>]+[<]>-]+[>]+<[-<]<<<]+>>>>>>>>[>>>]<[>>>]+<[>>>]+>>[<+>-]<[<->[-]]<[[[[>>>]<<<-<<<[<<<]+<<<[-<]>>>]>-<<[>>>]>>[>>>]>]>[>]>>[<+>-]<[<+>-]<[>>]<[<<<]]]>>[-]>[-]++>[-]+++++++++++[<<<<+>>+++++++++>++++++++++>-]<<<[>--.++..++.>.>>[-]]<[>>>++.--<++.+++++.-----.--.++>>]<++++.<.-.<<-.
Somewhat more formatted:
Code: | >+[->>>,<++++++++++[<+++++++++>>-<-]>]<<<
Setup the data like this: (the ? are the characters read minus 11) 0 90 0 ? 90 0 ? :: *? 90
[ if not empty (if empty accept)
[[>-<-]>-[[>]+[<]>-]+[>]+<[-<]<<<]
encode the characters in a sort of unary code: *0 90 0 0 0 (: 0 0 1 / 0 1 0 / 1 0 0 :)
+>>>>>>>>[>>>]<[>>>]+<[>>>]+>>[<+>-]<[<->[-]]<
[ we get here if the input was in the language a*b*c*c
[
This is actually similar to Daniel's approach: move the 1s into each other
[[>>>]<<<-<<<[<<<]+<<<[-<]>>>]
1st iteration: 0 0 90 *0 1 0 0 (: 1 0 1 / 0 1 0 :)
2nd iteration: 0 0 89 0 *0 1 0 (: 1 1 1 :)
>-<<[>>>]>>[>>>]>
]
check if stacks merged cleanly
>[>]
>>[<+>-]<[<+>-]<
[>>]
check if merged stack length is divisible by 3
<[<<<]
]
]
print result
>>[-]>[-]++>
[-]+++++++++++[<<<<+>>+++++++++>++++++++++>-]
<<<[>--.++..++.>.>>[-]]
<[>>>++.--<++.+++++.-----.--.++>>]
<++++.<.-.<<-. |
Interesting problem... and the mod 5 idea is great. |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Tue Dec 06, 2005 11:13 am Post subject: You know... |
|
|
Keymaker's
algorithm was actually better than mine. And that makes me wonder if we
should start a new custom: after each brainfuck contest, see if we can
collaboratively find anything shorter than the winning solutions. At
least, when the problem is hard enough that all submitted programs are
likely to be suboptimal. Anyone want to work on improving this 252-byte
program?
Code: | >>>>>+++<<<<+[
-[
[<+>>+<-]>[[->]<<]<[>>+<]>>[<+>>]
<[[-]>>+[>>]+[[-]<<]<]<[>]
<[>>>+<<<-]>>>>>>[>>]+>+<[<<]<<<
],----------
]>>>>[+>>]>>[[>>]>>]
+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<
-[-[-[>>.++..++.<--.++>>]]]
>[.>++++.+++++.-----.--.++>>]
<<<++.>.-.>>>. |
Also, if anyone is interested, here is my first submission, trivially different than my second:
+>+>>>+[,-[<+++++[[->]<<]<[>]>>]<[-[<<+>+>-]<<-[-[-[<[-]>-]]]+++>[<->>+<-]>[-[>]+>]>>>[>>>]+[<<<]<[-<]>>+<]>]+>+<<+[>>+>]<<[>+>>]<<[<<<]+<<[>>+>]>>[>>>]>+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<-[-[-[>>.++..++.<--.++>>]]]>[.>++++.+++++.-----.--.++>>]q<<<++.>.-.>>>.
or formatted:
Code: | +>+>>>+[
,-[<+++++[[->]<<]<[>]>>]<[
-[<<+>+>-]<<-[-[-[<[-]>-]]]+++>[<->>+<-]
>[-[>]+>]>>>[>>>]+[<<<]<[-<]>>+<
]>
]+>+<<+[>>+>]<<[>+>>]<<[<<<]+<<[>>+>]>>[>>>]
>+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<
-[-[-[>>.++..++.<--.++>>]]]
>[.>++++.+++++.-----.--.++>>]
<<<++.>.-.>>>. |
One more thing--should we call the contest we just finished Brainfuck Golf contest #3?
-Daniel. |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Tue Dec 06, 2005 1:07 pm Post subject: |
|
|
Quote: | Keymaker's
algorithm was actually better than mine. And that makes me wonder if we
should start a new custom: after each brainfuck contest, see if we can
collaboratively find anything shorter than the winning solutions. At
least, when the problem is hard enough that all submitted programs are
likely to be suboptimal. Anyone want to work on improving this 252-byte
program? |
Wow, thanks. The idea is good, although I couldn't get that any shorter.. 252 instructions, that's amazing size.
As for Golf #3, yeah, I guess this could be called BF Golf #3, since
1. This uses the usual Golf implementation (8-bit non-wrapping cells, non-wrapping array)
2. The shortest code wins
3. Calamari has made this whole section called Golf, and described it "Esoteric language Golf games, in the spirit of Perl Golf"
This was a great competition, thanks for everyone taking part.
Now, the obvious question is, what's up next?  |
|
Back to top |
|
 |
Bertram Guest
|
Posted: Tue Dec 06, 2005 10:44 pm Post subject: |
|
|
Here's a 250 byte version:
Code: | >>>>>+++<<+<<+[
-[
[<+>>+<-]>
[[->]<<]<[>>+<]>>[<+>>]
<[[-]>>+[>>]+[[-]<<]<]<[>]
<[>>>+<<<-]> >>>>>[>>]+>+<[<<]<<<
],----------
]+[+>>]>>[[>>]>>]
+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<
-[-[-[>>.++..++.<--.++>>]]]
>[.>++++.+++++.-----.--.++>>]
<<<++.>.-.>>>. |
The algorithm is great and Daniel's code is quite impressive. |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Wed Dec 07, 2005 2:11 am Post subject: |
|
|
That's excellent. Now how about if we also reconsider the linefeed detection method... 247 bytes
Code: | >>>>>+++<<+[
<<,----------[
[<+>>+<-]>
[[->]<<]<[>>+<]>>[<+>>]
<[[-]>>+[>>]+[[-]<<]<]<[>]
<[>>>+<<<-]>>>>>>[>>]+>+<[<<]
]<
]>+[+>>]>>[[>>]>>]
+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<
-[-[-[>>.++..++.<--.++>>]]]
>[.>++++.+++++.-----.--.++>>]
<<<++.>.-.>>>. |
(Another thing, notice that the <[>] at the end of the end of the
fifth line can be moved to the beginning of that line without changing
the outcome...that should be true of any of these recent variants. Or
for that matter, it can be wrapped around the fifth line:
Code: | <[[[-]>>+[>>]+[[-]<<]<]>]
<<[>>>+<<<-]>>>>>>[>>]+>+<[<<] |
-Daniel. |
|
Back to top |
|
 |
Daniel Guest
|
Posted: Fri Dec 09, 2005 12:10 am Post subject: |
|
|
Dunno why I didn't spot this before:
Code: | >>>>>+++<<+[
<<,----------[
[<+>>+<-]>[[->]<<]<[>>+<]>>[<+>>]
<[[-]>>+[>>]+[[-]<<]<]<[>]
<[>>>+<<<-]>>>>>> look [>] here +>+<[<<]
]<
]>+[+>>]>>[[>>]>>]
+++++[<++++>>++<-]<-[<<++++++>+++++>-]<++<<
-[-[-[>>.++..++.<--.++>>]]]
>[.>++++.+++++.-----.--.++>>]
<<<++.>.-.>>>. |
I always feel bad when one of my programs can be improved purely by
deletion. It's happened five or ten times I think. 246 bytes.
New question. This is based on
an idea of Keymaker's, and I'm interested to see other people try it.
How short a program can output its own instruction count in bytes as a
decimal number, followed by a linefeed? This is too small a contest to
count as Golf. 31 is possible; is 30?
Last edited by Daniel on Fri Dec 09, 2005 4:17 am; edited 1 time in total |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Fri Dec 09, 2005 1:58 am Post subject: |
|
|
Hehe, yeah, that has happened to me sometimes too. Another byte out; excellent!
About Daniel's question; yeah, it'd be very interesting to see. Personally I've got to 32 bytes;
http://bf-hacks.org/hacks/selfsize.b |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Fri Dec 09, 2005 6:18 am Post subject: |
|
|
I just got to 31 too.
Code: | ++++++++++[>+++++>+<<-]>+.--.>. |
I'll need to update my site later.. |
|
Back to top |
|
 |
Keymaker Guest
|
Posted: Fri Dec 09, 2005 7:06 am Post subject: Hmmm.. |
|
|
Not sure if it's possible to get it any shorter than 31 bytes in a non-wrapping implementation. At least I haven't succeeded in it yet, although that doesn't mean anything.
However, with wrapping 8-bit cells it's possible to get it down to 30 bytes;
Code: | >-[-----<+>]++++++++++<.---.>. |
Haven't tested that program since I don't have a wrapping interpreter, but I hope it'll work. |
|
Back to top |
|
 |
|
|
You can post new topics in this forum You can reply to topics in this forum You can edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB 2.0.11 � 2001, 2002 phpBB Group
|