Re: [spoon-discuss] Re: [Spoon-business] Quick Fix Fix, and a Big heap of Insta-Rules

[Wonko <dplepage@xxxxxxxxxxxx>]

Quoth Glotmorf,

> On 11/27/02 at 12:28 AM Wonko wrote:
> 
>>>> I amend my proposal entitled __Never again__ to be:
>>> 
>>> I appreciate the thought, though I'd wondered about replacing the names
>> of me
>>> and my Underlords to "The Overlord and any Underlords".  But I haven't
>> quite
>>> decided what authority CFIs should have on petition rulings...We'll talk
>>> later.
>> 
>> I think at the very least the Overlord should be unable to alter CFIs. As
>> it
>> is, the OL could change any CFI e wanted by petitioning emself, then
>> reviewing and implementing it. That makes me nervous.
> 
> Yes, though at the same time should Overlord rulings be immune to CFIs?
> Otherwise there might be a lot of nuisance suits.
> 
> How would we layer your definitions, the definition of player and admin, CFIs
> and The Overlord?  I'd see it as something like this...
> 
> TOP
> -----
> Rule 0
> -----
> definitions of basic concepts
> -----
> definitions of player and admin
> -----
> CFI mechanism
> -----
> The Overlord
> other rule-changing rules
> -----
> everything else
> -----
> BOTTOM
> 
> Players and the Administrator would have to be defined below the basic
> concepts, since they're dependent on the basic concepts.  The CFI mechanism
> would have to be below the player and admin defs because it depends on them.
> That could leave CFIs out of reach of the Overlord.

That looks good to me.

Say, here's an idea: what if, instead of making bandwidth cost dependant on
the number of rules changed, it depended on the level of the most powerful
modified rule? Or, we could give each player a 'Power' attribute; one would
have to spend greater quantities of power to amend more powerful rules, and
there could be ways of gaining extra power, say from Bonus Boxes or the
consumption of Insta-Rules, or something crazy like that?

>>> You have me curious.  What's BrainF*ck?
>> 
>> BrainFuck, often referred to as BF, BrainFork, or BrainF***, is designed to
>> be simplest possible programming language that is Turing complete. I've
>> seen
>> the source code for it - there's a C++ version of the interpreter that's
>> about half a page long. Basically, you have an array of 3000 unsigned
>> bytes,
>> and a pointer. Initially, the array is all 0's, and the pointer's at the
>> first one. You have the following commands:
>> '>' : increment pointer
>> '<' : decrement pointer
>> '+' : increment the byte being pointed at
>> '-' : decrement the byte being pointed at
>> ';' : get a character from the input stream, store its ASCII to the pointed
>> byte
>> '.' : print the character whose ASCII is the current byte to the output
>> stream
>> '[' : if the current byte is zero, skip ahead to just after the next ']'
>> ']' : if the current byte is nonzero, skip back to just after the last '['
>> 
>> 
>> Here's an example of a BF code. This prints "hello world":
> 
>> +++++++++[<++++++++>-]<.>++++++[<+++++>-]<-.+++++++..+++.>>+++++++[<++++++>-]
>> <+
> +.------------.<++++++++.--------.+++.------.--------.>+.>++++++++++.
> 
> I'm having a little trouble following that...The way I see it, first the
> pointer is moved to location 1, then location 1 is incremented to 9, then
> location 1 is tested to see if it's zero, then since it's not zero the pointer
> is moved to location 0, which is incremented to 8, then location 1 is
> decremented, then location 0 (8) is printed, then location 1 is incremented to
> 14, then since it's not zero the pointer is moved to location 0, which is
> incremented to 13, then location 1 is decremented, then location 0 (13) is
> decremented and printed, then incremented to 19, then printed twice...
> 
> The problem I'm having with all this is that 'a' has the ASCII value 97, or
> thereabouts; if you're printing anything less than an ASCII value of 28,
> you're printing control characters...?

It does this:
Increment loc1 to 9. Then, test 1; it's postitive, so add 8 to loc0 and
subtract 1 from loc1. Then control hits the closing bracket; the current
byte (loc1 = 8) is still nonzero, so it adds 8 to loc0 again and decrements
loc1 again. This continues until loc1 is zero; at this point loc0 has 8*9;
72 is the ASCII for 'H'. The same multiplication system is used to increment
the other locations to their respective ASCII values.

-- 
Wonko

_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss