<< ctxmodel.net
2008-07-04 21:10:56 osmanturan >
Note that CCM uses such that mixing schema: p'=mixer[quantize(p1)][quantize(p2)].P; It's just kind of SSE as you see. Do you have any idea Shelwien? I think, this can be speed up enough. But, not sure it's strength. He said that quantize() function is designed for making cache-friendly mixer.
2008-07-05 04:25:08 Shelwien >
> Note that CCM uses such that mixing schema: p'=mixer[quantize(p1)][quantize(p2)].P; > It's just kind of SSE as you see. > Do you have any idea Shelwien? I tested my 2D SSE in place of a mixer and it showed worse results, as you maybe remember. > He said that quantize() function is > designed for making cache-friendly mixer. Whatever. He just uses nonlinear counters which are faster of course. Also I doubt that such speed is possible while updating even 6 counters and 5 mixers at each bit, so its probably more of a PPM than you think.
2008-07-05 05:25:23 osmanturan >
> I tested my 2D SSE in place of a mixer and it showed > worse results, as you maybe remember. Well...I can't remember :-( > Whatever. He just uses nonlinear counters which are > faster of course. > Also I doubt that such speed is possible while updating > even 6 counters and 5 mixers at each bit, so its probably > more of a PPM than you think. Is there a way such that thing: - Collect statistics based on bytes under some contexts(such as PPM) - Like bitwise context mixing, mix the predictions from all of the contexts. - Process the byte with a fast coder Is this possible?
2008-07-05 07:17:22 Shelwien >
> Well...I can't remember :-( http://encode.ru/forums/index.php?action=vthread&forum=1&topic=648 > Is there a way such that thing: > - Collect statistics based on bytes under some contexts > (such as PPM) > - Like bitwise context mixing, mix the predictions > from all of the contexts. Check http://compression.ru/sh/ppmy_3c_sse.rar /src/model.ing and http://compression.ru/sh/ash04.rar /src/model.inc Also ppmonstr basically does the same thing as ash, but without mixing. And don't mind the speed and quality of these coders - they use wrong counters and weird weighting functions (and float-point statistics), but the overall scheme is still ok, at least in ash. > - Process the byte with a fast coder > Is this possible? Well, unary coding fits your description. And btw these coders with LZP submodel, which first encode the match flag, and only process the byte with the main model on no match, are a (partial) example of that too. But its not fully efficient with a bitwise model, because there's no fast way to mask out the unmatched symbol, so redundancy occurs. Also in fact the separate modelling is good not only for rank0, but the redundancy without masking gets too big.
2013-08-09 13:12:09 >
2014-11-26 10:32:51 >
2015-01-11 07:38:40 >
|