Snippet Compress Number

[Nestharus]

After much effort, I've come up with this for lossy compression in save/load ; ).


Lossy compression is commonly used on hero experience, hero x,y coordinates, and player gold. The most common equation for gold is R2I(gold/100), which cuts off the last 2 digits. The problem with this is that it fails with smaller values.


The equation I present will still get the max of 10,000 for gold like the above but with better results ; ).

library CompressInt
//performs lossy compression on integers
//compressed number = number^(2/3)

//decompressed number = roundDown(number^1.5+.5)

function CompressInt takes integer n returns integer
    return R2I(Pow(n,2/3.))
endfunction
function DecompressInt takes integer n returns integer
    return R2I(Pow(n,1.5)+.5)
endfunction

endlibrary

This does lose accuracy, but it's extremely good and works on any size numbers.


You can also compress multiple times.


The current exponents I have set up seem to be the magic numbers ; ).



Demonstration:

995995 -> 9973
9973 -> 995952


As can be seen, rather than getting 995000, 995952 was retrieved, which is quite a bit closer to the real value.


123456 -> 2479
2479 -> 123428


357832393 -> 504026
504026 -> 357832192


Side by side
357832393
357832192


Yes, the retrieved value is only 201 off from the actual number while storing a 9 digit number as a 6 digit number.

 

[Switch33]

This is neat. But instead of just getting a wacky closer digit number couldn't they just round the number saved? I mean like save the first 1-3 digits in front then count the number of zeroes afterward to store instead.

Because that would be roughly the same concept of storing a large digit number like a 9 digit number as a 3-4 digit number.

I think it at least makes more sense to save numbers as rounded down/up after the 100's(or 1000's) place anyway. I mean no one will fret too much of a loss of 49 gold at least(or 499 in some other maps). And when people load this they see this weird number that is really not looking like what they saved they might get kind of confused at first.

Although this is really so accurate that it doesn't matter too much. I just find it'd be annoying to try to tell people that the gold they got back is the correct amount it's just rounded arbitrarily to an close number.

 

[Nestharus]

That wouldn't be good because you'd have to round with a constant... if you round to 100, which is the norm, then if they have 50 gold that they worked hard to get, it drops to 0. If they have something like 3589459935 of something, then that only drops to 3589459900, whereas it would drop more and be stored smaller if it were running off of this compression.


Think of this as rounding based on how big the data is ; ).

 

[tooltiperror]

This is pretty nice. I kind of want something like this from time to time.

Would it be too much to ask for it in a library? As someone like you who loves modularity, I would think you would be horrified of somebody duplicating this function

Also, documentation. I know you have some irrational fear of it, but I just ask for a quick header like Bribe's. Mention the functions, their return and input, then add a note on how it rounds and you can lose accuracy (pros and cons) the usual stuff.

 

[Nestharus]

I can put it in a library sure.


As for the description of it, the first post already does that no?

 

[tooltiperror]

It's sort of a de facto standard to keep that information in the header in the world of Jass.

 

[Nestharus]

The most I'm putting in the header is that this does Lossy Compression ; ).

Take it or leave it : p.

 

[PurgeandFire]

Nice and useful. But:

[ljass]//decomperssed number = roundDown(number^1.5+.5)[/ljass]

Just thought I'd mention it.

 

[Bribe]

Actually the documentation would make more sense as: round(number ^ 1.5) because that implies adding the 0.5 itself, and rounding down implies not adding the 0.5.

 

[GFreak45]

thats pretty cool, to improve acuracy couldnt you do a little more to the function and maybe add a digit or convert it to a real with a .last_exact_digit00 ?
like:

library CompressInt
//performs lossy compression on integers
//compressed number = number^(2/3)

//decompressed number = roundDown(number^1.5+.5)

function CompressInt takes integer n returns real
    local real i = (n - (R2I(n/10))*10)/10
    return Pow(n,2/3.) + i
endfunction
function DecompressInt takes integer n, integer y returns integer
    return R2I(Pow(n,1.5)+.5)/10)*10 + y//where y would be the end digit of the real it returned, that way they could just convert the first return to an integer if they just want the compressed integer, or save the real end to make it exact
endfunction

endlibrary

 

[Dirac]

In depth guide to compress the returned value of a compressed number