<< 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                 >

Write a comment:

Name: