Difference between revisions of "Hex"

From Second Life Wiki
Jump to navigation Jump to search
(merge the history of same & fast and different & fast implementations into the fastest posted yet, according to Code Racer)
(post +- 30 7 6 7 2 millisecond results of 147 105 102 113 91 at 1,000 runs of the Efficiency Tester harness for llGetTimestamp)
Line 26: Line 26:
Here you see code that implements the hex function specification, then you see demo code that calls the hex function, and then you see a copy of exactly the results that you running the demo should produce.  
Here you see code that implements the hex function specification, then you see demo code that calls the hex function, and then you see a copy of exactly the results that you running the demo should produce.  


You see not one but actually three kinds of code that implement the one specification. The concise & conventional code details and implements the specification. The clever & small code reduces the code size reported by llGetFreeMemory. The clever & fast code reduces the run time reported by llGetTimestamp when called to return the hex for the integer value -0x80000000.
You see not one but actually three kinds of code that implement the one specification. The concise & conventional code details and implements the specification. The clever & small code reduces the code size reported by llGetFreeMemory. The clever & fast code reduces the run time reported by llGetTimestamp when called to calculate the hex for 0x7fffFFFF inside of the [[Code Racer]] harness.
 
Consistent with those quick results, the [[Efficiency Tester]] harness reports run time as a count of milliseconds. Running thru 200ms for 10,000 times takes 2,000 seconds, '''aka''' more than 33 minutes. The results here came quicker: we cheated by running only 1,000 times.


=== Concise & Conventional ===
=== Concise & Conventional ===
Line 72: Line 74:
347 bytes of code reported by llGetFreeMemory -- more than the small code and more than the fast code
347 bytes of code reported by llGetFreeMemory -- more than the small code and more than the fast code


FIXME milliseconds of run time reported by llGetTimestamp -- more than the small code and more than the fast code
147+-30 milliseconds of run time reported by llGetTimestamp -- more than the small code and more than the fast code


=== Clever & Small ===
=== Clever & Small ===
Line 105: Line 107:
197 bytes of code reported by llGetFreeMemory -- less than the concise & conventional code and less than the fast code
197 bytes of code reported by llGetFreeMemory -- less than the concise & conventional code and less than the fast code


FIXME milliseconds of run time reported by llGetTimestamp -- less than the concise & conventional code, but more than the fast code
105+-7 milliseconds of run time reported by llGetTimestamp -- less than the concise & conventional code, but more than the fast code


=== Clever & Fast ===
=== Clever & Fast ===
Line 139: Line 141:
202 bytes of code reported by llGetFreeMemory - less than concise & conventional code, but more than the small code
202 bytes of code reported by llGetFreeMemory - less than concise & conventional code, but more than the small code


FIXME milliseconds of run time reported by llGetTimestamp - less than the concise & conventional code and less than the small code
102+-6 milliseconds of run time reported by llGetTimestamp - less than the concise & conventional code and less than the small code


===== Demo =====
== Demo ==


Run this demo code to confirm that you get exactly the expected demo results below. We chose test cases that astonish people new to hex.
Run this demo code to confirm that you get exactly the expected demo results below. We chose test cases that astonish people new to hex.
Line 175: Line 177:
</pre>
</pre>


===== Demo Results =====
== Demo Results ==


Running the demo above to call your choice of code should produce exactly these results:
Running the demo above to call your choice of code should produce exactly these results:
Line 203: Line 205:


<div id="box">
<div id="box">
== Measuring Concise & Conventional & Small & Fast ==
Measuring concise  & conventional is hard. Computer programmers often disagree, like other poets. Possibly the most useful opinions come from the http://www.jargon.net/jargonfile/l/languagelawyer.html community.
Measuring small is easy. Compile two copies of the code into one script, call llGetFreeMemory, delete one copy, and report the difference.
Measuring fast is tedious. Calling the [[Efficiency Tester]] harness just 1,000 times to give us our results in minutes rather than tens of minutes produces measures that don't make sense, like the silly claim that bits2nybbles is slower than
when called in theto calculate the hex for the integer value 0x7fffFFFF as many as 1,000 times.


== Design Rationale ==
== Design Rationale ==
Line 242: Line 254:
This code returns "0" for 0, "80000000" for -0x80000000, "FFFFFFFF" for -0x1, etc.
This code returns "0" for 0, "80000000" for -0x80000000, "FFFFFFFF" for -0x1, etc.


The code presented here does return easy-to-read upper case A B C D E F nybbles, but exactly the same small size of code can return easy-to-type lower case a b c d e f nybbles.
The code presented here does return easy-to-read upper case A B C D E F nybbles, but exactly the same small size of code can return easy-to-type lower case a b c d e f nybbles. Reworking this code into the confusing style of the Fast & Clever code above does make this code larger and faster, producing run times as fast as 91+-2 milliseconds.


<pre>
<pre>
Line 261: Line 273:
139 bytes of code reported by llGetFreeMemory
139 bytes of code reported by llGetFreeMemory


FIXME milliseconds of run time reported by llGetTimestamp
113+-7 milliseconds of run time reported by llGetTimestamp


</div>
</div>

Revision as of 06:54, 18 October 2007

Function: string hex(integer value);

Returns the hexadecimal nybbles of the signed integer value in order. Specifically returns the nybbles from most to least significant, starting with the first nonzero nybble, folding every nybble to lower case, and beginning with the nonnegative prefix "0x" or the negative prefix "-0x".

Parameters:

• integer value signed value to be expressed as negative or nonnegative hex

Note: Results with eight nybbles begin always with one of the positive signed nybbles 1 2 3 4 5 6 7, never with a zero or unsigned nybble 0 8 9 A B C D E F, except for the boundary test case of the most negative integer "-0x80000000".

Caution: This page was a work in progress as of 2007-10. The specification, the implementations, the demo, the demo results, and the alternatives may not yet be totally consistent. See the discussion tab.

Implementations

Here you see code that implements the hex function specification, then you see demo code that calls the hex function, and then you see a copy of exactly the results that you running the demo should produce.

You see not one but actually three kinds of code that implement the one specification. The concise & conventional code details and implements the specification. The clever & small code reduces the code size reported by llGetFreeMemory. The clever & fast code reduces the run time reported by llGetTimestamp when called to calculate the hex for 0x7fffFFFF inside of the Code Racer harness.

Consistent with those quick results, the Efficiency Tester harness reports run time as a count of milliseconds. Running thru 200ms for 10,000 times takes 2,000 seconds, aka more than 33 minutes. The results here came quicker: we cheated by running only 1,000 times.

Concise & Conventional

You should choose this code when you care more about concise & conventional than about small & fast.

You should feel that this concise & conventional code is easy to review and modify. For example, you should immediately understand the comment that tells you how to substitute the easy-to-read upper case A B C D E F nybbles of IBM style for the easy-to-type lower case a b c d e f nybbles of AT&T style. Also you should immediately see what results to expect this code to return for any input.

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

string XDIGITS = "0123456789abcdef"; // could be "0123456789ABCDEF"

string hexes(integer bits)
{
    string nybbles = "";
    while (bits)
    {
        integer lsn = bits & 0xF; // least significant nybble
        string nybble = llGetSubString(XDIGITS, lsn, lsn);
        nybbles = nybble + nybbles;
        bits = bits >> 4; // discard the least significant bits at right
        bits = bits & 0xfffFFFF; // discard the sign bits at left
    }
    return nybbles;
}

string hex(integer value)
{
    if (value < 0)
    {
        return "-0x" + hexes(-value);
    }
    else if (value == 0)
    {
        return "0x0"; // hexes(value) == "" when (value == 0)
    }
    else // if (0 < value)
    {
        return "0x" + hexes(value);
    }
}

347 bytes of code reported by llGetFreeMemory -- more than the small code and more than the fast code

147+-30 milliseconds of run time reported by llGetTimestamp -- more than the small code and more than the fast code

Clever & Small

You should choose this code when you care more about small & fast & clever than about concise & conventional.

We wrote this clever & small code to show how to reduce the code size reported by llGetFreeMemory. We think this code produces the same results as the concise & conventional code. After adequate education & review, you should agree.

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

string hex(integer value)
{
    string lead = "0x";
    if (value & 0x80000000) // means (integer < 0) but is smaller and faster
    {
        lead = "-0x";
        value = -value; // unnecessary when value == -0x80000000
    }

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

    return lead + nybbles;
}

197 bytes of code reported by llGetFreeMemory -- less than the concise & conventional code and less than the fast code

105+-7 milliseconds of run time reported by llGetTimestamp -- less than the concise & conventional code, but more than the fast code

Clever & Fast

You should choose this code when you care more about fast & small than about concise & conventional.

We wrote this clever & fast code to show how to reduce the run time reported by llGetTimestamp. We think this code produces the same results as the concise & conventional code. After adequate education & review, you should agree.

This code confusingly packs all the source lines into one function, not two. This code confusingly assigns a variable and passes a copy of that variable within the parameter list of a function call, which works only when you & the compiler agree over which parameters to evaluate first. This code astonishingly loops once per nonzero nybble, rather than unrolling the loop. This code astonishingly zeroes the most significant nybble once per loop, rather than zeroing that nybble once and then looping separately to process the remaining nybbles if any. This code astonishingly declares its variables outside the loop. All these many implementation choices produce real differences in run time that llGetTimestamp can quickly measure for you thru a test harness like Code Racer.

string hex(integer value)
{
    string lead = "0x";
    if (value & 0x80000000) // means (integer < 0) but is smaller and faster
    {
        lead = "-0x";
        value = -value; // unnecessary when value == -0x80000000
    }

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

202 bytes of code reported by llGetFreeMemory - less than concise & conventional code, but more than the small code

102+-6 milliseconds of run time reported by llGetTimestamp - less than the concise & conventional code and less than the small code

Demo

Run this demo code to confirm that you get exactly the expected demo results below. We chose test cases that astonish people new to hex.

We also chose test cases that astonish people new to LSL permission masks. You'll get the permission mask results we show if you create a New Script to run this demo in. If instead you tried modifying some old script to run this demo, then you might have to edit its permission masks to get the demo results that we show here.

default
{
    state_entry()
    {
        llOwnerSay("Hello");
        llOwnerSay(hex(0) + " == 0");
        llOwnerSay(hex(0x00FEDC00 & -0x00FEDC00) + " == (0x00FEDC00 & -0x00FEDC00)");
        llOwnerSay(hex(1 << 30) + " == (1 << 30)");
        llOwnerSay(hex(0x80000000) + " == 0x80000000");
        llOwnerSay(hex(0xFEDC9876) + " == 0xFEDC9876");
        llOwnerSay(hex(-1) + " == -1");
        llOwnerSay(hex(0x123456789) + " == 0x123456789");
        llOwnerSay("OK");
        
        llOwnerSay("Hello again");
        string item = llGetScriptName();
        llOwnerSay(hex(llGetInventoryPermMask(item, MASK_BASE)) + " as base");
        llOwnerSay(hex(llGetInventoryPermMask(item, MASK_OWNER)) + " by owner");
        llOwnerSay(hex(llGetInventoryPermMask(item, MASK_GROUP)) + " by group");
        llOwnerSay(hex(llGetInventoryPermMask(item, MASK_EVERYONE)) + " by anyone");
        llOwnerSay(hex(llGetInventoryPermMask(item, MASK_NEXT)) + " by next owner");
        llOwnerSay("aka " + (string) llGetInventoryPermMask(item, MASK_NEXT));
        llOwnerSay("OK");
    }
}

Demo Results

Running the demo above to call your choice of code should produce exactly these results:

Hello
0x0 == 0
0x400 == (0x00FEDC00 & -0x00FEDC00)
0x40000000 == (1 << 30)
-0x80000000 == 0x80000000
-0x123678a == 0xFEDC9876
-0x1 == -1
-0x1 == 0x123456789
OK
Hello again
0x7fffffff as base
0x7fffffff by owner
0x0 by group
0x0 by anyone
0x82000 by next owner
aka 532480
OK

Measuring Concise & Conventional & Small & Fast

Measuring concise & conventional is hard. Computer programmers often disagree, like other poets. Possibly the most useful opinions come from the http://www.jargon.net/jargonfile/l/languagelawyer.html community.

Measuring small is easy. Compile two copies of the code into one script, call llGetFreeMemory, delete one copy, and report the difference.

Measuring fast is tedious. Calling the Efficiency Tester harness just 1,000 times to give us our results in minutes rather than tens of minutes produces measures that don't make sense, like the silly claim that bits2nybbles is slower than

when called in theto calculate the hex for the integer value 0x7fffFFFF as many as 1,000 times.

Design Rationale

The specification requires exactly the same results as the hex function of the Python scripting language.

The specification reproduces how hex integer literals often appear in LSL script, conforming to such arbitrary and traditional AT&T C conventions as:

  1. return lower case a b c d e f rather than upper case A B C D E F,
  2. return a signed 31-bit result if negative, rather than an unsigned 32-bit result,
  3. omit the leading quads of zeroed bits, except returns "0x0" rather than "0x" when the result is zero,
  4. return a meaningless "0" before the "x", as LSL and C compilers require,
  5. return the "x" on the left as in LSL and C, not the "h" on the right as in Assembly code, and
  6. return the nybbles listed from most to least significant as in English, not listed from least to most significant as in Arabic.

Brief doc for the Python hex function appears buried deep within http://docs.python.org/lib/built-in-funcs.html

Disputes over the detailed specification of the Python hex function appear buried deep within http://www.python.org/dev/peps/pep-0237/

As you read this page, you have to wade thru more than one implementation because our LSL wiki serves more than one community of LSL authors. New authors need to see concise & conventional exemplars first, experts find appropriate uses for the small & fast exemplars.

We don't know how to write LSL that implements a hex function that is concise and conventional and small and fast, all at once. We think that design goal is an impossibility in LSL, as in many other programming languages.

Alternatives

When you can accept the cost of abandoning the conventional specification, you can make the code still more concise and smaller and faster.

Different & Concise & Small

This code sees the most significant bit of the integer as just another data bit, rather than as the sign bit, so results with eight nybbles can begin with any of the nonzero unsigned nybbles 1 2 3 4 5 6 7 8 9 A B C D E F. This code also doesn't bother to calculate the "-0x" or "0x" part of the conventional answer.

This code returns "0" for 0, "80000000" for -0x80000000, "FFFFFFFF" for -0x1, etc.

The code presented here does return easy-to-read upper case A B C D E F nybbles, but exactly the same small size of code can return easy-to-type lower case a b c d e f nybbles. Reworking this code into the confusing style of the Fast & Clever code above does make this code larger and faster, producing run times as fast as 91+-2 milliseconds.

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

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

139 bytes of code reported by llGetFreeMemory

113+-7 milliseconds of run time reported by llGetTimestamp