data compression

[ismahill]

maybe, it would be possible, to create a codec that will take fragments of the file, calculate them and divide them by some number with flag control and multiple them back at the client so for example, instead of sending a 11101010 (234) it will send a 11010 (234/9=26).

by creating a matrix at the host, each number will have it own reference by a 8bit to 5bit attribution (exp.) then, it would multiple it back by this matrix at the client attaching it back to the file.

if the data is already at it's base (i.e 26), the host will attach a cancel flag to it.

all the work will be made by the processor and will create up to 30% compression.

[DreadWingKnight]

So you intend to attempt to compress data that is already compressed?

A VERY large majority of torrents contain data that is already compressed in one form or another.

[ismahill]

it just sound very possible.

[DreadWingKnight]

It sounds possible, but in the end it does become a lot more difficult to implement.

[ismahill]

why is that?

[DreadWingKnight]

Your "simple" algorithm doesn't account for numbers that don't divide evenly.

It also doesn't account for the prime numbers between 0 and 255.

[ismahill]

yes aware of that,

that was just an example.

one can easily implement it with x>128 than minus it with 128 if smaller, add flag &-64.

there are many options.

[DreadWingKnight]

Many options that don't actually gain you anything.

[ismahill]

that's bullshit!!

x>128 than -128 gives u 7 bits instead of 8 at maximum x<128 than -64 etc.

or else it is counted by bytes and then it's not usefull counting the flags.

u need it to catch 2 bytes instead of 4 & byte instead of 2.

lets take even numbers, 32b - 4294967296 divide it by 2 etc. add flag for number of devides,

until 32 times,

it can go till it's 2 and with 5bits reserved for flags that can save us 3 bytes of data!!

take odd numbers and devide them by 3, add the 5 bits & 1 bit for odd/even determination..

[DreadWingKnight]

Write the algorithm and I might actually believe that it can work.

[ismahill]

about prime numbers, when u get to such problem, one can minus one them and then divide, adding a -1 flag at the second byte.

but it won't work anyhow,

after rethinking it,

if we'll take some number - 4,152,405,300 / 2 ->

2,076,302,650/2 -> 1,038,151,325.

there is no way afterwards.

for some conclusion -

a bit algorithm, is probably inefficient, as bits are compressed anyway, it might seem obvious for some who are femiliar with the subject, but not for all..

the most compressed scheme for 256 options, is 8 bits,

65536 for 16 and so on.

the algorithm, might work, but it will be limited only for X exponented numbers,

which is good, for only 32-8=24*X posibilities eventually!

the only compression algorithms possible, is probably at the ASCI level,

such as the lz77&78 improvements and on.

it is nice testing things,

seeing where it is possible to go .