• 0

    posted a message on LibCompress
    I put my code here for people to test.

    http://pastey.net/87899
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Well, I have written a huffman compress/uncompress algorithm and I think we should merge the different algorithm into the same library.

    My huffman algorithm encodes about twice as fast as your LZW algorithm, producing better compression on my test data. Decompression is however about same speed as compression, i.e. somewhat slower than your LZW decompression.

    Other algorithms may arise and therefore I suggest we implement a simple standard for compressed data, consisting of a 1 byte header to select compression algorithm and the data following the header byte is passed to the appropriate decompression algorithm.

    For compression, we could ask for a specific compression algorithm or have LibCompress try all compression algorithms to see if any of the compression methods can compress the data.

    My huffman algorithm will in worst cast produce compressed data 1 byte larger then the uncompressed data. That 1 byte is the header byte. Currently I use byte value 0 to indicate uncompressed data and byte value 1 to indicate huffman compressed data.

    Example of huffman-compressing 20000 random byte values ranged 0-24 (25 symbols, actual byte values are insignificant):

    encoding time: 0.032
    decoding time: 0.046
    Original size: 20000
    Compressed size: 11824
    Compression ratio: 0.5912

    My algorithms have been optimized for speed. Thereby not saying further optimizations are impossible. :-P

    The is a bug in LibCompress right now:

    if (#uncompressed > ressize) or (uncompressed:sub(1,1) == "/001") then

    should be:

    if (#uncompressed > ressize) or (uncompressed:sub(1,1) == "\001") then

    If LibCompress was to have several compression methods, your LZW would require a permanent prefix byte value for compressed data. Right now you use "\001" to indicate that data is compressed but if trying to compress data with a \001 prefixed, you get the compressed data stream, even if it is much larger than the uncompressed data:

    Compressing 20001 bytes values 0-24 with an initial byte value \001:

    encoding time: 0.063
    decoding time: 0.031
    Original size: 20001
    Compressed size: 26658
    Compression ratio: 1.3328333583321

    Always using a prefix byte will help solve this problem as you will always be able to flag compressed data properly (and be able to compress data regardless of input byte values).

    A last problem is compressing the string "" which will cause an error.

    If you prefer not to merge the algorithms, I'll have to figure out a good name (was thinking about LibCompress, but now it is taken. :-P )
    Posted in: Libraries
  • 0

    posted a message on AceTab bug?
    This is a repost from the developer forum. Seems this forum is where the action is... ;-)

    I got this error when Ace2 is installed in the Addons directory:

    Date: 2007-05-29 19:02:26
    ID: 51
    Error occured in: Global
    Count: 1
    Message: ..\AddOns\Ace2\AceTab-2.0\AceTab-2.0.lua line 248:
    attempt to perform arithmetic on a nil value
    Debug:
    [C]: ?
    Ace2\AceTab-2.0\AceTab-2.0.lua:248: OnTabPressed()
    Ace2\AceTab-2.0\AceTab-2.0.lua:31:
    Ace2\AceTab-2.0\AceTab-2.0.lua:30
    [C]: securecall()
    ..\FrameXML\ChatFrame.lua:3239: ChatEdit_OnTabPressed()
    [string "*:OnTabPressed"]:1:
    [string "*:OnTabPressed"]:1

    It happens when I try to complete an itemlink in LootLink on the chatprompt. This may be a bug in LootLink but seeing as this has never errored in any way before I figure this could be an Ace2 bug.

    Ace2-r37328
    Posted in: Libraries
  • To post a comment, please or register a new account.