<< ctxmodel.net

2008-07-27 15:01:13 toffer          >
My results for a single delayed mapping are worse than expected (gain is less than .005%). Different parameters for y=0 and y=1 (the next bit) are very close and it's faster to implement. Guess i'll have to use two separate mappings :)

I'm planning to do some transformations, e.g. don't use a delayed bit as a parameter context, but something like (p>0.5) XOR y, or y(k)==y(k-1), etc...

Have you tried anything like this? I don't like to reinvent the wheele all the time.

BTW i tried to optimize the mixing distribution as well (you set it to p_m=0.5), but i was hardly able to improve the performance due to limited precision (for gradient calculations).

2008-07-28 03:30:46 Shelwien        >
> My results for a single delayed mapping are worse than
> expected (gain is less than .005%).

Well, dunno. Like I posted, the directly used 15:3 delayed
counter had 1.81% better ratio at the optimization target,
and 1.34% better in sh_samples_1 benchmark. (check o6mix6
vs o6mix7a2)

It didn't work out for delayed counter + SSE though, which
means that SSE's context quantization has more effect than
linear probability correction, and its harder to track the
correlations with delayed counter.

So now there's an idea to try skipping the update of
DC's probability part, while using the mappings emulating
the simple counter. Thus primary estimation would always
have the same distribution, and such counter still would
be more adaptive than simple one.

> Different parameters for y=0 and y=1 (the next bit) are
> very close and it's faster to implement.

Yes, but there won't be much gain from that, aside from
tuning instability similar to my DC's.
Alas, there's no such constantly skewed "symbols" in bitwise
coding, like in unary - that's where DCs and the like are
really useful.

> I'm planning to do some transformations, e.g. don't use a
> delayed bit as a parameter context, but something like
> (p>0.5) XOR y, or y(k)==y(k-1), etc...

Well, that could work in SSE context, so why not, but I'd not
expect much from that.

> Have you tried anything like this?
> I don't like to reinvent the wheele all the time.

Thing is that any history quantization basically can be
emulated with the proper set of DC's parameters... so it
might be better to make some tuning passes with different
files and analyze the tuned parameter values.

> BTW i tried to optimize the mixing distribution as well
> (you set it to p_m=0.5),

Don't really understand that... You mean your mix of
primary estimation with SSE? Wonder if I should try
something like that too...

2008-07-29 15:57:38 toffer          >
Two thing - could you *please* make your i/o functions return some file_t (defined as whatever you like...) i don't like to change the returned uints all the time. Could you please post the layout of o6mix* v7? If i want to quickly compare some stuff with older versions, i have to read a lot of source code; the short comments in the table above aren't that helpful.

> So now there's an idea to try skipping the update of
> DC's probability part, while using the mappings emulating
> the simple counter. Thus primary estimation would always
> have the same distribution, and such counter still would
> be more adaptive than simple one.

Sorry, i don't really understand what you mean here. Could you clarify this?

> Don't really understand that... You mean your mix of
> primary estimation with SSE? Wonder if I should try
> something like that too...

ATM i'm trying to create a new model with tuned parameters. It shouldn't be too slow and suited for higher order contexts. As i said the first experiment with a single delayed mapping failed. I think (just a intuitive guess) that something like this will do a good job:

1. delayed counter with two mappings (unfortunately two... :))
2. mix the counter output with a context merging table (i described it some time ago) - static SSE

But actually that's not what i meant in the previous post - i wanted to say, why not tune pm within a counter:

p(k+1) = w0*p(k) + w1*y(k) + w2*pm

Or even simpler:

p(k+1) = w0*p(k) + w1(y(k))*pm(y(k))

I'll add initial value tuning, too. But this will take some time.

2008-07-29 17:21:48 Shelwien        >
> Two thing - could you *please* make your i/o functions
> return some file_t (defined as whatever you like...)

I made this: http://ctxmodel.net/files/MIX/file_std.inc
Is it enough?

> Could you please post the layout of o6mix* v7?
> the short comments in the table above aren't that helpful.

Guess you meant o6mix7* here. But its hard to explain any
more than these short comments because only Node2i is
patched there (sh_node2i.inc) - turned into a rough
delayed counter implementation.
All I can add is that revisions 7-7b just have the counter
replaced and in 7c the scheme is simplified - there's no
static "estimation" mapping and simple update is used
instead of another mapping, but delayed history bits are
included into SSE context instead (1 to 3).

> > So now there's an idea to try skipping the update of
> > DC's probability part, while using the mappings emulating
> > the simple counter. Thus primary estimation would always
> > have the same distribution, and such counter still would
> > be more adaptive than simple one.
>
> Sorry, i don't really understand what you mean here.
> Could you clarify this?

Well, delayed counter is always better when used directly,
but there's no simple correlation between bit history
sequences and probability values, like with a simple counter.
The result is unstable performance under SSE.

So, a proposed tradeoff is using the simple update
(still delayed) and skipping updates on some bits,
deciding by delayed bits.
That would keep the correlations of probability values,
but still allows to somewhat improve the counter's performance;
also skipping updates is good for speed and can be seen
as a "smart parsing".

> But actually that's not what i meant in the previous post
> - i wanted to say, why not tune pm within a counter:
> p(k+1) = w0*p(k) + w1*y(k) + w2*pm

Ah, that. Of course I always did that - look for *mw constants.

Btw, even if it was a misunderstanding, I still tried mixing
of primary and secondary estimations (just the secondary one
was used before) and I like the results:

http://ctxmodel.net/files/MIX/mix_v7.htm
http://ctxmodel.net/files/MIX/mix_v7_SFC.htm

Guess it would be even better if we combine it with simplified
delayed counter like in 7c* revisions.

2008-08-21 11:54:56 toffer          >
Do you have any more progress? What about your audio modeling? I'm still investigating several optimization algorithms.

2008-08-21 13:25:00 Shelwien        >
My jobs keep me busy for now.
And audio compressor is the next thing I'd make when I'd get some free time,
as its seems easier than a new bytewise "universal" compressor
(while continuing with Mix is boring somehow).
Also thanks to Christian I remembered about noise in audio data,
which is a great source of redundancy in my lamix_v0 coder, as
it processes all the bits with the same counters and doesn't
limit the redundancy for low bits in any way.

2009-01-05 21:05:45 Fatlip1         >
Eugine, is "mix" legally dead now? It's really sad since it did pretty well in my tests.

2009-01-06 20:38:30 Shelwien        >
Well, it wasn't quite alive from the beginning ;)
Meaning that it was never intended for practical use.
But I still do some tests with it, even now there're 3 instances
of optimizer running with versions of mix7d2 - byte mapping
experiment.
So in theory its still possible that I'd post more versions,
if something interesting happens with it.
But in practice I'm more interested in bytewise compressors
(did you notice tree_v1 i wonder?), and maybe lossless audio
compressors.

2013-08-09 02:27:27                 >

2014-11-26 07:33:17                 >

2015-01-11 04:42:46                 >