Talk:Hex

Efficiency Tester vs. Code Racer

The Efficiency Tester & Code Racer harnesses produced mutually consistent results for me back when they were both based on llGetTimestamp.

Now with the change to llGetTime, somehow I don't immediately see consistent results ... That could just be the naturally variability in measuring time on a time-shared system ... or the change introduced a significant bug of some kind ... -- Ppaatt Lynagh 18:12, 20 October 2007 (PDT)

llGetFreeMemory and llGetTime results

So here's the raw data for a new round of summary results, measured with llGetTime and llGetFreeMemory rather than with llGetTimestamp and llGetFreeMemory -- Ppaatt Lynagh 11:49, 20 October 2007 (PDT)

// Concise & Conventional

14892 free bytes of code at default.state_entry
29.525997+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
29.309505+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
29.048304+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop

// Clever & Small

15042 free bytes of code at default.state_entry
26.522137+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
27.012869+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
26.886431+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop

// Clever & Fast

15037 free bytes of code at default.state_entry
26.416100+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
27.720108+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
26.514929+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop

// Different & Concise & Small

15100 free bytes of code at default.state_entry
25.888016+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
25.656263+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
26.585047+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop

// Different & Clever & Fast

15078 free bytes of code at default.state_entry
28.594223+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
26.809479+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop
26.388189+-??% ms may have elapsed on average in each of
10000 trials of running the code in the loop

And to help make the derivation of summary milliseconds of elapsed run time clear, here below is all the arithmetic calculating { middling = ((fastest + slowest) / 2) } with a +- imprecision of { max(middling - fastest, slowest - middling)) }. -- Ppaatt Lynagh 11:58, 20 October 2007 (PDT)

dc -e '29.5 d 29.0 + 2 / p - p'
dc -e '26.5 d 27.0 + 2 / p - p'
dc -e '26.4 d 27.7 + 2 / p - p'
dc -e '25.9 d 26.6 + 2 / p - p'
dc -e '28.6 d 26.4 + 2 / p - p'

$ dc -e '29.5 d 29.0 + 2 / p - p'
29
.5
$ dc -e '26.5 d 27.0 + 2 / p - p'
26
.5
$ dc -e '26.4 d 27.7 + 2 / p - p'
27
-.6
$ dc -e '25.9 d 26.6 + 2 / p - p'
26
-.1
$ dc -e '28.6 d 26.4 + 2 / p - p'
27
1.6
$ 

29+-1
26+-1
27+-1
26+-1
27+-2

Different & Clever & Fast

The article claims:

Note: Reworking this concise & small code into the clever & fast style does make this different code larger and faster, producing run times as fast as 91+-2 milliseconds.

Perhaps by NPOV we should also quote that byte size, to show how much larger that code is. And then also blog here an actual example result of that exercise, corresponding to that quote of run time.

I think this is the code we mean, its byte size may be 161, its run time may be 91+-2 milliseconds, I hope to return soon to reconfirm.

-- Ppaatt Lynagh On or before 20 October 2007 (PDT)

// http://wiki.secondlife.com/wiki/Talk:hex

string bits2nybbles(integer bits)
{
    integer lsn; // least significant nybble
    string nybbles = "";
    do
    {
        integer lsn = bits & 0xF; // least significant nybble
        nybbles = llGetSubString("0123456789ABCDEF", lsn = (bits & 0xF), lsn) + nybbles;
    } while (bits = (0xfffFFFF & (bits >> 4)));
    return nybbles;
}

Running the Efficiency Tester for just 1000 times suggests this different & clever & fast code suggest it astonishingly runs slower than the different & concise & small code we already included in the article: like 26 29 30 ms rather than 26 26 25 ms. I'll try running 10,000 times next, I guess. -- Ppaatt Lynagh On or before 20 October 2007 (PDT)

Here below now is a preview - a run of just 1000, using llGetTime rather than llGetTimestamp, one or two runs for each implementation. Looks like the difference between different & clever & fast vs. different & concise & small is too negligible to measure reliably with a run of 1000. -- Ppaatt Lynagh 09:54, 20 October 2007 (PDT)

// Concise & Conventional

14900 free bytes of code at default.state_entry
0.030812+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.031006+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.030123+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

// Clever & Small

15050 free bytes of code at default.state_entry
0.028898+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.028747+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.027901+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

// Clever & Fast

15045 free bytes of code at default.state_entry
0.026896+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.026773+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.027210+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

// Different & Concise & Small

15108 free bytes of code at default.state_entry
0.025729+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.026136+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.024839+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

15108 free bytes of code at default.state_entry
0.026976+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.027034+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.026788+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

// Different & Clever & Fast

15086 free bytes of code at default.state_entry
0.026279+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.029061+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.029775+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

15086 free bytes of code at default.state_entry
0.026498+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.025734+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop
0.025299+-25% s may have elapsed on average in each of
1000 trials of running the code in the loop

Third Talk

... I hate [the 18 October] revision ...

Good.

I think you would vote to undo the 18 October revision, and I know I would vote to undo the 15/ 14 October revision.

I believe in this way we have established a creative tension: a line along which we can hope to find a neutral point of view (NPOV) and a consensus statement of that NPOV.

Thank you. -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

... shouldn't use llGetTimestamp for profiling ...
... should be using the script time functions (llGetTime) ...

I see this hex article contains reproducible measurements across a spread from 91+-2 to 147+-30 milliseconds, taken from 1,000 runs of the Efficiency Tester instrument that harnesses llGetTimestamp.

I see now that the llGetTime, llGetAndResetTime, llResetTime, timer, llGetRegionTimeDilation articles were all woefully confused. By your one-word "should" hint here, I think I now understand what we mean by second and fractional seconds of dilated time, so yes I have now updated all five of those confused articles accordingly, thank you.

I understand you to be saying we should change the Efficiency Tester instrument to call llGetTime rather than llGetTimestamp. Is that right? Then also we should update the Code Racer instrument, by the same reasoning. Then I see after all that we must copy the Efficiency Tester changes into the exact duplicate of that instrument that appears expanded inline deep inside the LSL Script Efficiency article. Agreed? This is exactly your intended recommendation? -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

No objection yet, so for now this guess stands. We've already now finished most of the work of the update, as Efficiency Tester shows. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... cannot replicate ... bytecode cost ...

Thank you for making time to say so. I've added the Code Sizer article to explain the procedure more fully, and naturally I linked the existing Hex#Measuring_Concise_.26_Conventional_.26_Small_.26_Fast explanation to that article. I hope you or any of us can make time to try again now to confirm or correct the byte counts. -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

No objection yet, so for now this guess stands. We've already now finished most of the work of the update, as Talk:Code Sizer shows. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... cannot replicate ... bytecode cost ... steps ...

I've copied your steps into Talk:Code_Sizer as Talk:Code_Sizer#The_Plus_Four_Instrument. In my (extremely limited) experience, those steps produce results that count exactly four more bytes than the Code Sizer instrument. I imagine you already know why, I do not yet know why.

I vote to have the hex article quote the results of the Code Sizer instrument, rather than the Plus Four instrument. I vote that way because I believe the size occupied when I add a function to a script that already has other functions matters more than the size occupied when I add the first function. -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

• snaps fingers* I know where that extra four bytes are coming from, the dword used for the length of the user function lookup table. When there are no user functions the compiler doesn't include a user function lookup table at all. You can find LSO documentation on the LibSL wiki. -- Strife Onizuka 13:37, 24 October 2007 (PDT)

I guess "*snap fingers*" is English slang. I guess that slang means ah, yes, we appear to be mutually intelligible here now. Yes I agree that's good news, thank you for saying.

I guess "the LibSL wiki" means the wiki that includes the page http://www.libsecondlife.org/wiki/LSO that has been referenced at LSO since at least the 2007-10-19 change commented as "LSL Bytecode moved to LSO".

I guess that LibSecondLife "Function Block" is exactly the same as our "user function lookup table" here. I see that LibSecondLife.org page describes a "Global Function Register" that points to the "Function Block".

I guess we now agree we always should avoid counting the 4 byte cost of creating the User Function Lookup Table as part of the byte code space cost of an LSL function. That's progress: that's growth in our consensus NPOV, which I can now next merge into the Code Sizer instrument. Thank you. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... The Loop Cost is ... the cost in bytes of each iteration of the loop ...

People hear more if we can find a way to say less. To whom does this byte size within the loop matter under which conditions? Surely quoting the total byte size of each solution suffices? If we must quote this, then we must define it. Is this byte cost within the loop purely or does this byte cost include the outside of the loop also? With what instrument and procedure do we measure this loop cost? -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

Why would it include the bytecode outside the loop? That wouldn't be the loop bytecode cost. It is the number of bytes executed per iteration (including the conditional check used to do the iteration). You should take some time to study the compiler & VM source code; it would provide the insight needed to have an informed discussion about this.

Instruments & procedures? For reading the bytecode I use a hex editor and a bytecode cheat sheet. It's not like political analysis with shades of gray, the answers are quite obvious if you take the time to look. There isn't more I can say without giving you an education in LSO.

-- Strife Onizuka 13:37, 24 October 2007 (PDT)

I see "the loop bytecode cost ... is the number of bytes executed per iteration (including the conditional check used to do the iteration)". Thank you for clearly defining that new term. For the test case of a loop that runs bigger but faster by beginning with a jump to the conditional check that ends the loop, I assume that the loop bytecode cost would include that jump also.

I see "a bytecode cheat sheet". Is a copy of this cheat sheet available online? Is it merely an extract of the http://www.libsecondlife.org/wiki/LSO page? Have you noticed that Talk:Hex#LSO doesn't yet explain how other people after you can snoop the byte code that the LL client produces?

I see no reason to believe we should grow the hex article to include this info -- no concrete specific answer to the question of to whom does this byte size within the loop matter under which conditions. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... the variable cost ...

What is this variable cost? What are its units? How do we count it? Why do we care? -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

The answer is in the bytecode structure. With some simple experiments you can get an inkling why it's important. If you read the source you can get a firmer grasp. I'm a Scripting Mentor, a mentor shows you path and will help you keep to the path; they won't walk the path for you. I've told you where you can find the information you seek and now I'm offended that you are too lazy to read it. -- Strife Onizuka 13:37, 24 October 2007 (PDT)

Sorry I understand none of that reply. With my eyes, I see only another pointless http://en.wikipedia.org/wiki/Ad_hominem attack. I don't know how to understand ad hominem attacks, i.e., I don't know how to turn them into a useful contribution. I don't mean to appear to ignore your input, I just don't know how to respond substantively in any technically helpful way. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... operations ...

What are the units of this "operations" measure? Instructions? Bytes? How do we count them? Why do we care? -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

See the computer science definition... [1] -- Strife Onizuka 13:37, 24 October 2007 (PDT)

I visited the http://www.thefreedictionary.com/operation page, I fail to see how it is relevant. Perhaps I can help by mention I've been writing code since 1973. Conventional computer science is familiar to me, it is Second Life that is new to me. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

I see no reason to believe we should grow the hex article to include this info -- no concrete specific answer to the question of to whom do these "operations" counts within the loop matter under which conditions. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... It would be remiss not to mention ...

Which procedure do you intend for us to publish together with additional benchmark results, to allow the scientific audience to most conveniently -- most quickly & inexpensively -- repeat your experiment?

Can we agree somehow to present less exemplars? The only exemplars that have value in my eye are the concise & conventional exemplar, and the different & concise & small exemplar. Is there a chance that you'd let the page settle if we presented only those two examples together with the clever & fast exemplar?

I hope we still hold a chance at such a consensus. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

Have you seen Talk:Hex#Why_bother_with_fast_or_small_or_different_code_exemplars yet? Do those few paragraphs explain correctly why you hate the concise & conventional exemplar? They do explain correctly why I avoid clever exemplars like the plague. -- Ppaatt Lynagh

I'll take a look at it.-- Strife Onizuka 13:37, 24 October 2007 (PDT)

Thank you. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

... [much snipped] ...

I believe I have now answered all the technically substantive open questions.

If I've left any question unanswered, I hope you can make time to repeat it more clearly. Thanks again for helping me think clearly and neutrally. -- Ppaatt Lynagh 22:57, 19 October 2007 (PDT)

So far as I know I have now answered all the new technically substantive open questions. -- Ppaatt Lynagh 15:31, 24 October 2007 (PDT)

197 bytes or more

Scientifically reproducible summary measures of code space now appear in the article:

347 bytes
197 bytes
202 bytes
139 bytes
More bytes

These results you can quickly & easily reproduce with the Code Sizer instrument.

We list all the instruments we use at Hex#Measuring_Concise_.26_Conventional_.26_Small_.26_Fast.

-- Ppaatt Lynagh On or before 20 October 2007 (PDT)

91+-2 milliseconds or more

Scientifically reproducible summary measures of run time now appear in the article:

147+-30 milliseconds
105+-7 milliseconds
102+-6 milliseconds
113+-7 milliseconds
91+-2 milliseconds

Those results you can slowly & easily confirm or deny or improve.

We list all the instruments we use at Hex#Measuring_Concise_.26_Conventional_.26_Small_.26_Fast.

Quoting these millisecond results took more calculation than anyone has yet programmed into the Efficiency Tester.

One of us ran that harness 3 x 1,000 times for each version of code, then took the (min, max) pair and reported { middling = ((fastest + slowest) / 2) } with a +- imprecision of { max(middling - fastest, slowest - middling)) }.

The raw data was as follows. -- Ppaatt Lynagh On or before 20 October 2007 (PDT)

[5:51]  Object: 15146 free bytes of code at default.state_entry
[5:53]  Object: 98.496002+-FIXME milliseconds passed on average in each of
[5:53]  Object: 1000 trials of running the code in the loop
[5:55]  Object: 96.188004+-FIXME milliseconds passed on average in each of
[5:55]  Object: 1000 trials of running the code in the loop
[5:56]  Object: 106.851997+-FIXME milliseconds passed on average in each of
[5:56]  Object: 1000 trials of running the code in the loop

[6:01]  Object: 15151 free bytes of code at default.state_entry
[6:03]  Object: 111.475998+-FIXME milliseconds passed on average in each of
[6:03]  Object: 1000 trials of running the code in the loop
[6:04]  Object: 112.019997+-FIXME milliseconds passed on average in each of
[6:04]  Object: 1000 trials of running the code in the loop
[6:06]  Object: 98.428001+-FIXME milliseconds passed on average in each of
[6:06]  Object: 1000 trials of running the code in the loop

[6:09]  Object: 15209 free bytes of code at default.state_entry
[6:11]  Object: 120.155998+-FIXME milliseconds passed on average in each of
[6:11]  Object: 1000 trials of running the code in the loop
[6:12]  Object: 15209 free bytes of code at default.state_entry
[6:14]  Object: 115.272003+-FIXME milliseconds passed on average in each of
[6:14]  Object: 1000 trials of running the code in the loop
[6:16]  Object: 106.751999+-FIXME milliseconds passed on average in each of
[6:16]  Object: 1000 trials of running the code in the loop
[6:18]  Object: 111.919998+-FIXME milliseconds passed on average in each of
[6:18]  Object: 1000 trials of running the code in the loop

[6:25]  Object: 15001 free bytes of code at default.state_entry
[6:28]  Object: 176.723999+-FIXME milliseconds passed on average in each of
[6:28]  Object: 1000 trials of running the code in the loop
[6:30]  Object: 131.716003+-FIXME milliseconds passed on average in each of
[6:30]  Object: 1000 trials of running the code in the loop
[6:32]  Object: 117.820000+-FIXME milliseconds passed on average in each of
[6:32]  Object: 1000 trials of running the code in the loop

[6:35]  Object: 15204 free bytes of code at default.state_entry
[6:36]  Object: 89.372002+-FIXME milliseconds passed on average in each of
[6:36]  Object: 1000 trials of running the code in the loop
[6:38]  Object: 92.748001+-FIXME milliseconds passed on average in each of
[6:38]  Object: 1000 trials of running the code in the loop
[6:40]  Object: 93.180000+-FIXME milliseconds passed on average in each of
[6:40]  Object: 1000 trials of running the code in the loop

Neutral Point Of View

I notice I continue to feel delighted by the way our community interacting together makes the point of view we publish ever more neutral.

You Deleting My Work, Me Deleting Your Work

I wonder if I can help by mentioning the two guides toward a neutral point of view that I am myself working to hold in mind as I play here:

1. I think the essence of any wikipedia is the astonishing idea that people can end up working together more when all together we agree "if you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here", as our edit page warns us.

2. I think the perspectives we represent run across the range of perspectives balanced at http://en.wikipedia.org/wiki/Optimization_(computer_science)#When_to_optimize. Some of us naturally care most about clear and conventional code, some of us care most about small code, some of us care most about fast code. That's great balance.

-- Ppaatt Lynagh ~16 October 2007 (PDT)

Why bother with fast or small or different code exemplars

Kuhn defines an exemplar as a solution paired with a problem to teach the new people how to solve problems (at least, that's my paraphrase of http://en.wikipedia.org/wiki/Exemplar).

Me, I launched this hex page on 8 October 2007, foolishly thinking I was writing out an obvious and adequate exemplar. Me, I thought I was just sharing the trivial work of me the LSL newbie getting the hex out to make some permission masks intelligible, in contrast with how confused the masks look in decimal. I thought I was just saving the next newbie some effort in working out the details.

I didn't think much about whether the masks were signed or unsigned. LSL permission masks only take on values that can be seen as positive or unsigned. LSL permission masks never set the most significant unsigned bit which is the sign bit of a signed two's-complement integer.

The creative tension that we subsequently worked thru then taught me much.

I now know that I initially saw value only in clear & conventional code examplars. In effect, I saw this wiki only teaching LSL to newbies like me.

I now guess this wiki has a wider purpose. Sure, this wiki teaches LSL to newbies, but this wiki also gives experts a place to share between themselves exemplars of making code clever or fast or small, including exemplars of respecifying code to make the code more clever or faster or smaller even at the extreme cost of making the code less clear & conventional, thus harder to call and reuse and read.

As yet I still don't yet understand the burst of changes ff. 14:59, 14 October 2007 ...

... but at least we now have found a perspective from which I can hope to understand those changes.

-- Ppaatt Lynagh 19:24, 17 October 2007 (PDT) -- created

-- Ppaatt Lynagh 06:47, 20 October 2007 (PDT) -- modified towards NPOV to claim value for clever as well as value for brief, clear, small, and fast

Eventually we spoke of "concise" (meaning "brief" and "clear"), "conventional", "clever", "small", and "fast" as qualities some or all of our people find desirable in a script. -- Ppaatt Lynagh 13:29, 22 October 2007 (PDT)

I was unfamiliar with the term "examplar" but it is good terminology. Its a window on to the deeper issue but it doesn't highlight it well in my opinion. The underlying issue is how people learn and what they learn. It hinges on how we perceive the expectations of the users: what the users are expecting to learn and how they expect to learn it. For someone new to LSL they come here with the expectation of learning to write LSL without any background knowledge. For an experienced LSL user, they aren't here to learn the fundamentals, they already know them; they are here to learn information with the expectation of forgetting it sometime in the future. It isn't important that they remember it passed the time when they aren't using it as long as they remember how to find it; for them the wiki is a reference. The needs of the newbie vs reference user are fundamentally different. I think it's time we revisit the layout design so it can better serve both extremes. When the layout was first designed, the only content on the wiki was very technical documentation (message template stuff). I don't want to take all the credit for layout design but I'll take all the blame for it, it's been a long time since I was a newbie to programing and I was a fast learner.

The second part is how they expect to learn. Learning styles differ drastically. It's not as simple as just throwing content at them and expecting them to learn it (we both know if it were we wouldn't be having this discussion ^_^). I would write more on this but it would take a dissertation to do it any semblance of justice.

At this point it would be good to move this (mini) discussion to a part of the wiki where proposals can be made and be actionable. Until the underlying issues are resolved (or reburied) we will likely be at each others throats always. -- Strife Onizuka 15:41, 24 October 2007 (PDT)

Sounds like we understand each other's taste in exemplars better now. Thanks for working to create that mutual understanding.

Yes I am a person new to LSL who comes here with an expectation of learning to write LSL without any background knowledge. Thanks for asking.

So far as I know, as yet we've only volunteered me to finish the change to llGetTime from llGetTimestamp now underway at Talk:Code Racer. I'd also now happily follow anyone's lead into discovering where the Mac OS client from LL hides the LSO it produces (Talk:Hex#LSO, Defined explains how that is not obvious). -- Ppaatt Lynagh 16:12, 24 October 2007 (PDT)

LSO, Defined

"LSO" may be slang meaning LSL byte code.

The LL client compiles scripts into files of the LSO format, then copies those LSO files thru the client's cache to the server, according to the http://www.libsecondlife.org/wiki/LSO page. Wiki.SecondLife articles that link to that LSO page include LSL_Bytecode and LSO.

The LL client might not always be so simple. For example, a sample of watching ( Mac Second Life > Preferences > Network > Disk Cache Location ) shows only (53448 bytes of index.db2.x.1146144658, and 104857600 bytes of data.db2.x.1146144658) when a script is compiled - no small separate LSO file.

Talk:Hex Archives

See 2007-10-24 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38020 to read back into the history of five topics:

5 Edit Conflicts

8 18 October Rewrite

9 Loop Costs Unscientific

11 Due Diligence

12 Correct At A Glance

See 2007-10-17 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=35999 to read back into the history of four topics:

3 Principle Of Least Astonishment

5 Second Talk

6 First Talk

7 Our Growing Consensus

Note: Our talk did link with http://en.wikipedia.org/wiki/Principle_of_least_astonishment