11 = 111
10 = 110
01 = 10
00 = 0
This is a standard huffman, statistically it also creates a 66.7% to
33.3% (rounded both) ratio of 1's to 0's.
Additionally if the ratio of 1's to 0's is fairly wide this could lead
to compression, assuming more 10 results prior to running it than 01
results. If not a single command can switch them. This can be
expressed by the following math formula: [A = percentage of 0s. B =
percentage of 1's. C = new file size in percentage form.]
( ( A * A ) + ( B * A * 2 ) + ( A * B * 3) + ( B * B * 3 ) ) / 2 = C
Does anyone argue with this? I hope not... moving on...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Next is pascals triangle in relation to binary coding.
At 1 megabyte of data there is 8,000,000 bits, and the odds of
'nearly' equality of all 1 bit, 2 bit, 3 bit, 4 bit, 5 bit, up to 10
bit operations is greater than 99%, correct? Or if you disagree feel
free to post your evidence suggesting a weaker percentage or of severe
deviation of the statistics.
Professionals will concede this point, I wonder who will not concede
this point..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This represents my two arguments I wish to move out of any spotlights
by newbs and critics so that when I release the full system, and
statistics of how it works, I can move away from this area and work
with people on the core principle.
I shall probably not wait for the patent papers to arrive prior to
posting the system. I am to impatient for my dreams I having now to
come true. I shall therefore at this time set up a nominal posting
date of this Wednesday.
This is not criticism
But can I ask a few questions? I can't really wrap my head around this
> assuming more 10 results prior to running it than 01 results.
Why can we assume this?
Would it really matter if you couldn't? You would have less 1's - but you
also would have less bits (it wouldn't add additional zero's), correct?
I have no idea whether it would make a difference in any direction, so
please tell me
Ummm, thats simple. Both results can occur from a statistical balance,
but be heavily in favor of one result. Since one result becomes 3
bits, and the other is 2 bits, choosing the smaller number for the
size increasing one is wiser.
It can only create this if the input file has the pairs in certain
ratios.
For example if the input files was only a random group of 10 and
01 then . you have exaclty the same number of ones and zeros
as starting file except you add an extra one for each 10 that was
input
so you are stuck with a file harder to compress. Agree?
>
> Additionally if the ratio of 1's to 0's is fairly wide this could lead
> to compression, assuming more 10 results prior to running it than 01
> results. If not a single command can switch them. This can be
> expressed by the following math formula: [A = percentage of 0s. B =
> percentage of 1's. C = new file size in percentage form.]
>
> ( ( A * A ) + ( B * A * 2 ) + ( A * B * 3) + ( B * B * 3 ) ) / 2 = C
>
> Does anyone argue with this? I hope not... moving on...
>
What are your talking about dimensionally you have A and B being
in percentages and you square the dimension and all the sudden you
C in percent what are you talking about. No I don't see it!!
David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
As for the rest, are you trying to Troll me sir? Lol.
I am Joking....