Re: DIS: Proto: Increase privatization
On Fri, Dec 19, 2008 at 23:36, Charles Reiss wrote: > On Fri, Dec 19, 2008 at 23:25, Ed Murphy wrote: >> woggle wrote: >> Cleanliness is a public contract switch with values Unclean (default) and Clean. Changes to Cleanliness are secured. >>> tracked by whom? >> >> The Janitor. >> * Murphy and the AFO agree to the following public contract, and Murphy consents to be its contestmaster. >>> I don't like doing such consent by proposal. Can you create a bootstrapping >>> rule >>> for the contestmaster flipping and the like? >> >> What's wrong with it? The proposal is itself an instrument with >> Power=2, so it can perform the various secured changes directly. > > Doing it in the form suggests that the proposal is forcing > R101(iv)-consent on Murphy and the AFO. This is, of course, not true I, of course, meant R101(iii), which is more relevant when plenty of notice would be provided as here. -woggle
Re: DIS: Proto: Increase privatization
On Fri, Dec 19, 2008 at 23:25, Ed Murphy wrote: > woggle wrote: > >>> Cleanliness is a public contract switch with values Unclean >>> (default) and Clean. Changes to Cleanliness are secured. >> tracked by whom? > > The Janitor. > >>> * Murphy and the AFO agree to the following public contract, and >>> Murphy consents to be its contestmaster. >> I don't like doing such consent by proposal. Can you create a bootstrapping >> rule >> for the contestmaster flipping and the like? > > What's wrong with it? The proposal is itself an instrument with > Power=2, so it can perform the various secured changes directly. Doing it in the form suggests that the proposal is forcing R101(iv)-consent on Murphy and the AFO. This is, of course, not true since Murphy would be submitting the proposal causing such agreement... -woggle
Re: DIS: Proto: Increase privatization
woggle wrote: >> Cleanliness is a public contract switch with values Unclean >> (default) and Clean. Changes to Cleanliness are secured. > tracked by whom? The Janitor. >> * Murphy and the AFO agree to the following public contract, and >> Murphy consents to be its contestmaster. > I don't like doing such consent by proposal. Can you create a bootstrapping > rule > for the contestmaster flipping and the like? What's wrong with it? The proposal is itself an instrument with Power=2, so it can perform the various secured changes directly.
DIS: BF joust pre-contest
BF Joust Pre-Contest I've built a BF Joust Hill (as in "king of the hill") of 10 jousters for the initial contest start. Anyone who submits a program to me before the contest starts will get a report as to how well it does against those 10. Entries won't be shared, and I won't really "examine" them other than to cut/paste. The purpose now is to see if anything needs adjusting before the contest begins (e.g. max cycles, scoring, etc.) If you send a program in now, I'll put it in the challenge queue once the program starts in the order it's received, so there may be some benefit to an early submission (go up against easier opponents perhaps). The 10 on the hill are not optimized or tuned to each other in particular, they represent about an hour of trying to come up with several straightforward (and somewhat orthogonal) strategies and also a few counter-strategies. -Goethe
Re: DIS: Proto: Increase privatization
On Fri, Dec 19, 2008 at 20:44, Ed Murphy wrote: > Proto-Proposal: Increase privatization > (AI = 2, II = 3, please) [snip] > Create a rule titled "Laundromats" with Power 2 and this text: > > Cleanliness is a public contract switch with values Unclean > (default) and Clean. Changes to Cleanliness are secured. tracked by whom? [snip] > * Murphy and the AFO agree to the following public contract, and > Murphy consents to be its contestmaster. I don't like doing such consent by proposal. Can you create a bootstrapping rule for the contestmaster flipping and the like?
DIS: Proto: Increase privatization
Proto-Proposal: Increase privatization (AI = 2, II = 3, please) Change the title of Rule 2126 to "Salaries", and amend it to read: Employership is a public contract switch, tracked by the Payroll Clerk, with values Non-Employer (default) and Employer. Changes to Employership are secured. A player CAN flip a public contract's Employership without 3 objections. Career is a player switch, tracked by the Payroll Clerk, with values null (default) and all Employer contractss. Changes to Career are secured. A player CAN flip eir Career if it is null, or if e has not already flipped it in this way during the current month. The Payroll Clerk is an office, and the recordkeepor of Employers and Careers. Salaries are gained as follows. The specific effect (if any) of gaining a salary depends on a player's Career. Gaining salaries is secured. (1) At the end of each week, for each player, let X be the number of eir interested proposals that were adopted during that week, and let Y be the number of eir interested quorate proposals that were rejected during that week with VI >= AI/2; e gains a legislative salary as follows: (a) If X > Y > 0, then majority-approval. (b) If X > Y = 0, then unanimous-approval. (c) If X = Y > 0, then middle-of-the-road. (d) If Y > X = 0, then unanimous-controversial. (e) If Y > X > 0, then majority-controversial. (f) Otherwise, none due to this clause. (2) (a) At the end of each week, each player who completed the non-empty set of weekly duties of at least one office during that week gains a weekly executive salary whose rating is the highest interest index among all such offices. (b) At the end of each month, each player who completed the non-empty set of monthly duties of at least one office during that month gains a monthly executive salary whose rating is the highest interest index among all such offices. (3) At the end of each week, each player who published at least one on-time judgement during that week gains a judicial salary whose rating is the highest interest index among all such cases. (4) (a) At the end of each week, each player who gained at least one Point during that week due to being a contestant in a contest gains a contestant salary. (b) At the end of each week, each player who awarded at least one Point during that week due to being the contestmaster of a contest gains a contestmaster salary. (5) (a) At the end of each week, each player who authored at least one proposal with an Interest Index of 2 that passed during that week gains a medium-complexity legislative salary. (b) At the end of each week, each player who authored at least one proposal with an Interest Index of 3 that passed during that week gains a high-complexity legislative salary. Create a rule titled "Social Climbing" with Power 2 and this text: Influence is a public contract switch, tracked by the Grand Poobah, with values Uninfluential (default) and Influential. Changes to Influence are secured. A player CAN flip a public contract's Influence without 3 objections. A player CAN increase or decrease the caste, or the voting limit on an individual ordinary proposal, of a specified player as permitted by an Influential contract. If changes to caste are secured, then changes to assets backed by an Influential contract by methods other than those stated by that contract are secured with the same power threshold. Change the title of Rule 2228 to "Blots", and amend it to read: Blots are a fixed asset, whose recordkeepor is the Janitor. The creation and destruction of Blots is secured with a power threshold of 1.7, and a person CANNOT destroy Blots except as permitted by rules explicitly stating methods by which Blots in particular CAN be destroyed. Ownership of Blots is restricted to first-class persons. If, in the absence of this restriction, a number (N) of Blots would be created in the ownership of a non-first-class person, then for each member of that person's basis, N Blots are created in that member's possession. The Janitor is an office, and the recordkeepor of Blots. Create a rule titled "Laundromats" with Power 2 and this text: Cleanliness is a public contract switch with values Unclean (default) and Clean. Changes to Cleanliness are secured. A player CAN flip a public contract's Cleanliness without 3
Re: DIS: Re: BUS: PBA Report
On 19 Dec 2008, at 21:47, Roger Hicks wrote: What coins? somebody left a while ago
Re: DIS: Re: BUS: PBA Report
On Fri, Dec 19, 2008 at 14:43, Elliott Hird wrote: > CoE: not an actual report, you didn't act on behalf of me. Also, the PBA > owns coins. > What coins? BobTHJ
DIS: Re: BUS: PBA Report
On 19 Dec 2008, at 21:35, Roger Hicks wrote: People's Bank of Agora CoE: not an actual report, you didn't act on behalf of me. Also, the PBA owns coins.
Re: DIS: Re: BUS: bf joust programs wanted
On Fri, Dec 19, 2008 at 4:34 PM, Charles Schaefer wrote: > But other people could gain points off the lambs too. > Not if you design your lambs right. What I mean (and should have spelled out) was e.g. that I could submit 100 variations on the same standard program that should do OK against all the others, and submit 1 program that is specifically designed to exploit a hidden flaw in the lamb series (something the other programs are highly unlikely to do without having seen the lamb first). BP
Re: DIS: Re: BUS: bf joust programs wanted
On Fri, 19 Dec 2008, Elliott Hird wrote: > On 19 Dec 2008, at 21:21, Jamie Dallaire wrote: > >> Perhaps the round robin should exclude matches between programs submitted by >> the same author, though. Nice artificial way to boost one's score would >> otherwise be to submit a hundred sacrificial lambs. > > this was done for iterated prisoner's dilemma. I say bring it on :-) > > But don't allow trivial variations. I was thinking of going "King of the Hill" Style. The Hill is P programs. Each program submitted fights all the programs on the Hill (and they fight each other). Single lowest score falls off the hill. You get points for having a program that survives N challenges while staying on the hill. A hundred sacrificial lambs don't help unless their base programming is good enough for the hill, so that's limiting. Though if you have a good one, you could send in a set of trivial variations (maybe solution is to discount multiple hill entries). I've written a starting hill, with admittedly at least one sacrifice: I'm wondering about an initial Enigma puzzle "beat all of Goethe's hill to solve this puzzle". -Goethe
Re: DIS: Re: BUS: bf joust programs wanted
But other people could gain points off the lambs too. 2008/12/19, Jamie Dallaire : > > Perhaps the round robin should exclude matches between programs submitted > by the same author, though. Nice artificial way to boost one's score would > otherwise be to submit a hundred sacrificial lambs.
Re: DIS: Re: BUS: bf joust programs wanted
On 19 Dec 2008, at 21:21, Jamie Dallaire wrote: Perhaps the round robin should exclude matches between programs submitted by the same author, though. Nice artificial way to boost one's score would otherwise be to submit a hundred sacrificial lambs. this was done for iterated prisoner's dilemma. I say bring it on :-) But don't allow trivial variations.
Re: DIS: Re: BUS: bf joust programs wanted
Perhaps the round robin should exclude matches between programs submitted by the same author, though. Nice artificial way to boost one's score would otherwise be to submit a hundred sacrificial lambs. On Fri, Dec 19, 2008 at 4:18 PM, Elliott Hird < penguinoftheg...@googlemail.com> wrote: > Let an arbitrary amount. > On 19 Dec 2008, at 21:15, Charles Schaefer wrote: > > Since it seems like most people are writing multiple programs (at least for > test purposes), will people be allowed to submit multiple programs in the > contest? Maybe with a fixed limit or some discouraging factor built in to > the rules (such as losing a certain fraction of your contest winnings for > each extra program). > > >
Re: DIS: Re: BUS: bf joust programs wanted
Let an arbitrary amount. On 19 Dec 2008, at 21:15, Charles Schaefer wrote: Since it seems like most people are writing multiple programs (at least for test purposes), will people be allowed to submit multiple programs in the contest? Maybe with a fixed limit or some discouraging factor built in to the rules (such as losing a certain fraction of your contest winnings for each extra program).
Re: DIS: Re: BUS: bf joust programs wanted
Since it seems like most people are writing multiple programs (at least for test purposes), will people be allowed to submit multiple programs in the contest? Maybe with a fixed limit or some discouraging factor built in to the rules (such as losing a certain fraction of your contest winnings for each extra program). -- Charles Schaefer
Re: DIS: Re: BUS: bf joust programs wanted
2008/12/19, Kerim Aydin : > > > Change already: increased max #cycles/charge from 1,000 to 100,000 Thank you. -- Charles Schaefer
Re: DIS: Re: BUS: bf joust programs wanted
On Fri, 19 Dec 2008, Elliott Hird wrote: > seems very easy > > [129 +s, then a large, large amount of >s] I started with 2 or 3 different "trivial and obvious" strategies that worked (no comment on this one) and was then able to then beat each one with something slightly fancier. Not to say someone won't find an unbeatable simple strategy, but finding one might be as least as challenging as an Enigma puzzle. Hmm, that's a thought... Change already: increased max #cycles/charge from 1,000 to 100,000 (tested on a tiny array, 1,000 was then not enough to traverse larger array and do anything worthwhile). -G.
Re: DIS: Re: BUS: bf joust programs wanted
On Fri, Dec 19, 2008 at 10:45 AM, Elliott Hird wrote: > On 19 Dec 2008, at 15:33, comex wrote: > >> That's an easy way to lose, yes, since you'd be zeroing your own flag. > > put the > first Then you run off the edge of the array, since you don't know what size it is. I think this is sound, although I think the concept of being able to mess with each others' code is more exciting. You could just have each player's instruction pointer point to somewhere in the data, perhaps like [player 1 flag] [player 1 code] --- [player 2 code] [player 2 flag] or even circular < - [player 1 flag] [player 1 code] --- [player 2 code] [player 2 flag] --- < wraparound although I guess corewars/assembly is a lot better suited to that kind of play than brainfuck.
Re: DIS: Re: BUS: bf joust programs wanted
On 19 Dec 2008, at 15:33, comex wrote: That's an easy way to lose, yes, since you'd be zeroing your own flag. put the > first
Re: DIS: Re: BUS: bf joust programs wanted
On Fri, Dec 19, 2008 at 10:10 AM, Elliott Hird wrote: > seems very easy > > [129 +s, then a large, large amount of >s] That's an easy way to lose, yes, since you'd be zeroing your own flag.
DIS: Re: BUS: bf joust programs wanted
On 19 Dec 2008, at 08:37, Kerim Aydin wrote: Ok, I've got a Brainfuck Joust tournament runner working. Before making this an official contest I'd like to see if the rules are interesting. (I tried a few random warriors and it looks ok, or at least it seemed like it wasn't wholly degenerate). Anyone willing to write a warrior or three? (I wrote three in about 20 minutes, all less than 20 characters). If submitted to me to help test before the "Agoran" contest begins, I won't share or study the code. Tournament runner code available on request. When I get five or more warriors and/or a few days have passed I'll run a test tournament and share results (though will not share code until some Official Agoran Contesting). Rules for test: 1. A Jousting Match between two BF programs consists of 20 Charges. For each Charge: 2. Two BF programs face off on the "jousting" array (the standard BF memory space, shared). Each BF's code is not part of the array. No code size limit. The length of the array is 151 +/- 16 (uniform random each Charge, exact length is unknowable to the code). No code length limit. 3. Each program's array pointer starts at one far end of the array, on its flag. Each flag starts at 128. All the other cells (between the two opponents' flags) initialized to 0 (reminder: these are unsigned chars with 255+1=0). 4. Standard BF code, except that IO (. and ,) do nothing. 5. 'The enemy's gate is right'. > is defined for each program as the direction (at the start of the round) towards the enemy's flag, and < is the direction away from the enemy's flag. 6. Code execution is simultaneous between competitors, but [ and ] comparisons for both competitors occur before + and - (only place order matters in a cycle). + and - are cumulative. Every symbol takes one cycle to execute. 7. Winning The Charge: a. If your flag is set to exactly 0, you lose (tested after each cycle). b. If your pointer runs off either end of the array (one step past either flag) you lose. c. If you both lose simultaneously, you both lose. d. If you cease execution (reach end of your code), you do not lose, though of course the opponent then has free reign on the array for the remainder of the charge. e. If 1000 cycles pass with no winner as above, you both lose. f. If the opponent loses and you don't, you win! 8. Scoring: 1 point for winning a Charge, 0 for ties or losses. 9. A full tournament is a full pairwise round robin of jousting matches, with scores summed for the final winner. -Goethe seems very easy [129 +s, then a large, large amount of >s]
