Difference between revisions of "Talk:Hex"

From Second Life Wiki
Jump to navigation Jump to search
(advocate clarity and conformity and size and speed, not just any one or two of those four)
(archive the talk that preceded our dividing the article in two)
 
(92 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The compiler doesn't optimize the output, for a function that is going to be used as a core function, speed & size should be the most important thing. Personally I wouldn't use hex, I'd only use hexu, LSL treats the upper bit as the sign bit; adding the sign is unnecessary for LSL. Of course who really transfers numbers between LSL scripts uses hex strings anyway? I use Base64 encoding for floats and just leave integers raw, or sometimes convert them to base64 too. Hex is just too slow to generate. -- [[User:Strife Onizuka|Strife Onizuka]] 10:03, 10 October 2007 (PDT)
= Talk:Hex Archives =


--
See 2007-10-29 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38446 to read fourteen old threads:


I'd like you to entertain the theory that I already understood every point you're making before you stated it, but that I'm inviting you to give attention to some other significant points also.
* 1 That Red Mist, Dispelled Maybe
* 2 Solution
* 3 Efficiency Tester vs. Code Racer
* 4 llGetFreeMemory and llGetTime results
** 4.1 Round Three
** 4.2 Round Two
** 4.3 Round One
* 5 Different & Clever & Fast
* 6 Third Talk
* 7 197 bytes or more
* 8 91+-2 milliseconds or more
* 9 Neutral Point Of View
** 9.1 You Deleting My Work, Me Deleting Your Work
** 9.2 Why bother with fast or small or different code exemplars
* 10 LSO, Defined
* 11 Talk:Hex Archives


I think we're beginning to understand each other. I'm especially encouraged to see I guessed correctly that you would only ever call hexu, as you now confirm here. That is the choice that anyone who values mostly size and speed would make, yes.
See 2007-10-24 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38020 to read five old threads:


I value clarity and conformity and size and speed, not just some of those, never always letting one trump all the others in every situation. For clarity in use and conformity to a widely accepted and much debated convention, I'd like to present a complete and correct implementation of the Python hex spec unchanged. I remember I created this page.
* 5 Edit Conflicts
* 8 18 October Rewrite
* 9 Loop Costs Unscientific
* 11 Due Diligence
* 12 Correct At A Glance


The Python hex spec has a documented history of moving from hexu to hex, as people who hold mainly to speed and size values clash with a wider community of people. At this moment our page here diverges from the Python hex spec only in that we return upper case at the hex level, same as at the hexu level. Perhaps we would all accept the compromise of calling hexu with the list of nybbles to return. Call with "0123456789ABCDEF" to get upper case back, call with "0123456789abcdef" to get lower case back, and meanwhile wish LSL let us specify default values for subroutine arguments.
See 2007-10-17 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=35999 to read four old threads:


For clarity in implementation, I liked having hex and hexu return lower and upper case respectively. Anyone understanding the code at a glance could tweak the code to get what they like, especially when assisted by comments like your comment that points people reading the code towards editing HEXC.
* 3 Principle Of Least Astonishment
* 5 Second Talk
* 6 First Talk
* 7 Our Growing Consensus


For clarity in implementation, I liked never using an assignment in a test. New people don't have to learn that idiom to read and correctly understand the code at a glance. Old people can trivially make that optimisation as they receive the code - it is a purely mechanical optimisation - people could even write a pre-processor to do that kind of transformation or even teach the client compiler to do it.
See also [[Talk:Efficient Hex]].
 
If you insist on presenting code optimised to the point of unreadability here, maybe we could compromise on presenting a couple of different versions together. Up front one version to read, then another version claiming to produce exactly the same results but smaller or quicker, both versions here together, rather than on confusingly separated pages like the [[Separate Words]] and [[ParseString2List]] pages.
 
Personally my history of pain in SL has been that I first run out of human time to read code, then I run out of script space to run code, then I run out of lag time to run code. I gather your history of pain has been different, I'm sorry to hear of your pain.
 
Am I yet more clear than mud? Wholly coherent? Partly persuasive?
 
-- [[User:Ppaatt Lynagh|Ppaatt Lynagh]] 10:39, 10 October 2007 (PDT)

Latest revision as of 12:36, 29 October 2007

Talk:Hex Archives

See 2007-10-29 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38446 to read fourteen old threads:

  • 1 That Red Mist, Dispelled Maybe
  • 2 Solution
  • 3 Efficiency Tester vs. Code Racer
  • 4 llGetFreeMemory and llGetTime results
    • 4.1 Round Three
    • 4.2 Round Two
    • 4.3 Round One
  • 5 Different & Clever & Fast
  • 6 Third Talk
  • 7 197 bytes or more
  • 8 91+-2 milliseconds or more
  • 9 Neutral Point Of View
    • 9.1 You Deleting My Work, Me Deleting Your Work
    • 9.2 Why bother with fast or small or different code exemplars
  • 10 LSO, Defined
  • 11 Talk:Hex Archives

See 2007-10-24 http://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38020 to read five old threads:

  • 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 four old threads:

  • 3 Principle Of Least Astonishment
  • 5 Second Talk
  • 6 First Talk
  • 7 Our Growing Consensus

See also Talk:Efficient Hex.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:Hex&oldid=38481"