Home > Archive > Compression > December 2007 > Eureka! Watch this space!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Eureka! Watch this space!
|
|
| Einstein 2007-11-30, 6:56 pm |
| Thanks to dont dont attttt gmail (Changed so he don't get spammed)
giving me a sort of different mind set to look at things (His black
box example and follow up questions did it for me) I have now created
a recursive compression method, lossless, dwindling returns, which can
be applied to near statistically even random data, and a fair portion
of statistically uneven data which is still for binary compression,
considered random.
Full White Paper to come on SUNDAY. I have previously given notice to
the "most work hours" employer, and have 2 other flexible employers.
This Friday is my last night (Graveyards no less), Saturday I will
spend typing up the white paper, and Sunday I will submit it to
locations across the Web and World.
In short this represents the highest level compression obtainable by
mankind, without 'violating' Entropy as some recursive methods claim
to do.
Previously I posted that I had obtained this as output on a
statistical basis
00
01
0
0
1
1
1
1
It is entirely tracked. It came to me then that since everything is
tracked, I could do a simple substitution... 0 for 1
00
01
1
1
0
0
0
0
Statistically then I have a 70% ratio of 0's versus 30% 1's. In a
large binary string it will be statistically correct, and therefore a
simple Huffman at this stage can work.
I plan a full proofs method, and will be s ing an adequate
programmer up to the task of creating software for the code as well.
Dont Dont gets first dibs if he feels he is up to the task, this for
asking the right questions in the right manner.
I will then run software against all known benchmarks. I am quite
surprised at the fewer lines of code needed once I got in the proper
frame of reference that this will need, and am optimistic that this
may show a very fast compression rate, though  ly a slow
decompression rate.
| |
| Einstein 2007-11-30, 6:56 pm |
| Michael Harrington's Recursive Binary Compression Method
This is a Whitepaper, recognized in international law, as a source of
original idea for science releases. I have 1 year from the release
date of this Whitepaper to Patent it according to International Law.
This is also US law.
Recursive Compression of a Random Binary Sequence.
I, Michael Harrington, have found that you can in fact compress random
binary data. The utility uses a series of quick and easy to understand
series of methods to achieve statistical compression.
First lets describe the "Seperation Effect". Choose a string length.
This string can be anything 2 bits or longer, though for demonstration
purposes I will choose 3 bits. A given file typically has thousands,
millions, even billions of these 3 bit strings. However for our
purposes we will demonstrate with a 24 bit spreadsheet, outlining
every possible outcome of 3 bits. We will henceforth refer to these as
"Substrings"
Now within these strings, the rule is "When you find a 1, the data
after it (So long as it is inside the same Substring) is placed in a
Seperate 'file' (Though it can be seperated inside the same binary
line, the visual aspect of seeing it in a new file is best for a walk
through). This data is placed in proper order of arrival. This can
lead to [{Substring Size}-1] number of files.
In practice the LAST file is unable to be compressed unless there is a
pre-existing flaw in the code making for a significant skew.
Therefore, for our demonstration, we will not utilize it, though if
there is a significant imbalance in the ratio of 1's to 0's it can be
compressed using a standard Huffman, or any other binary compression
system that is applicable.
However our original file, holding information not sent to other
files, and our other files, can be compressed.
Let me demonstrate first the 3 bit, all outcomes look
000
001
010
100
011
101
110
111
This would become 3 files, with ( ) showing seperation into different
files
000
001
01 (0)
1 (00)
01 (1)
1 (01)
1 (1) (0)
1 (1) (1)
Therefore file one has:
000
001
01
1
01
1
1
1
File Two has:
0
00
1
01
1
1
File Three, the last and therefore the usually uncompressible, has:
0
1
Now it does not matter what actual 'sequence' these bits have. For
instance file 2 can look like any of the following
0 - 00 - 0 - 1 - 01 - 1 - 1 or
0 - 00 - 0 - 1 - 1 - 1 - 01 or
0 - 00 - 0 - 1 - 1 - 01 - 1 or
0 - 00 - 0 - 01 - 1 - 1 - 1 or
0 - 00 - 0 - 1 - 1 - 01 - 1 or
0 - 01 - 0 - 1 - 1 - 1 - 00 or
Or any other plausible outcome using the Six different outcomes shown
statistically.
This concludes the "Seperation Effect".
Now we move to the "Alteration Stage".
In the Alteration Stage we choose a high 0 or 1 type outcome, and
switch it for a low 0 or 1 outcome. This could be 01 for 11, 1 for 0,
000 for 011, or any other length required. A command file records what
switch we made via a standardizzed dictionary result for each possible
binary replacement.
For instance of a Dictionary we could have the following 4 bit
'substitution tables':
0000 = NO CHANGE
0001 = 1 and 0 swap
0010 = 00 and 11 swap
0100 = 01 and 11 swap
1000 = 10 and 11 swap
0011 = 00 and 01 swap
0101 = 10 and 01 swap
1001 = 00 and 10 swap
0110 = 111 and 000 swap
1010 = 110 and 000 swap
1100 = 101 and 000 swap
0111 = 011 and 000 swap
1011 = 001 and 000 swap
1101 = 010 and 000 swap
1110 = 100 and 000 swap
1111 = 111 and 001 swap
A library can be hard-coded, or softcoded into the system. Softcoding
requires the dictionary to be the total sum of the bits of the
dictionary, while hardcoding requires the dictionary only have the
bits required to point it in the correct direction. For demonstration
sake we will assume a 16 bit dictionary but not develop it, assuming
that it covers all possible outcomes of our demonstration 3 bit
substrings.
For our demonstration we need to swap, logically, 0 and 1. This
provides us with the greatest "Imbalance" then, in total inside the
file, of 1's verus 0's. We will then have a 7 to 1 ratio imbalance. IE
12.5% of the outcomes are a 1, and 87.5% of the outcomes are a 0. This
leads to an immeadiate compression rate with a standard huffman. After
application of 00 = 0, 01 = 10, 10 = 110, 11 = 111 (A Huffman
replacement table), we obtain a statistical size for file two of
67.96875% compared to before.
File One after swapping 0 for 1 has eleven 0's and three 1's. This is
a ratio of 0.7857 to 0.2143 (rounded). Using a standard Huffman we
then obtain a compression rate of 79.84694 (Rounded) on it.
We used 16 bits for each file as a "Dictionary". Now normally we would
not see compression here. But if we increased the file to 24,000 bits,
assuming an equal ratio of 3 bit substring outcomes, we have 32 bits +
[((14/24*79.84694%) + (8/24*67.96875%)+ (2/24))*24,000] bits, or a
statistical total of 18,648.07 (rounded) bits.
The only issue is now "Combining the Files". This is called
"Accounting". The command section, plus 3 seperate "files" needs to be
tracked in size. Since the entire of each data section, when combined,
should be no more than 1.5 times at most, we can assume individual
tracking on them all to be Log(original file size *1.5)/Log(2) bits
(rounded up). For our case this is 16 bits each. These are added to
the command section.
So now we have three sixteen bit sections tracking our seperate
"files" for their factual sizes after compression on them. We also
have two sixteeen bit sections for the dictionaries of file one and
file two. We need some bits to identify how large our substrings are,
lets use 4 bits for now. In fact we can go hog wild and even just
assume every one of our six parts in our command section are 40 bits
long. But we only do this for quickly showing what can occur. This
means we have 240 bits in a fixed length command string. Add this to
18,648.07 and we obtain 18,888.07 (lets call it 18,889 bits now, for
rounding purposes).
18,889 / 24,000 = 78.7041667% compression. This is on a statistical
evenly balanced ratio of substring allotments, randomly sorted. It
should easily stand the test on most random binary sequences as well.
Thesis on why Entropy is still in effect, but seems also broken: By
addressing a multi line format, where each line has an individual
plausible length, we can achieve compression results which will follow
a bell curve, until such a point where the file in theory cannot be
compressed anymore. Each individual file will result in a different
size, but the best way to describe what is happening is that each file
we try to compress can have results of anything between 1 bit, and the
maximum bits. Therefore if working on a 4 bit substring that was
somehow was compressible with this method, we would see a total of
45(?) possible outcomes, of which just under two thirds would lead to
a size decrease or remain the maximum possible size. And yet this does
not suffice. Therefore the only other plausible explanation is the
Hutter theory, where data compression is related to Artificial
Intelligence when used in my manner.
It should be impossible for two files to become the same result with
my method. Yet the pigeon hole method seems to contradict this. Only a
true software, running with the method will prove out if the theory
actually works.
I reserve all rights to this copyrighted paper. All works inside here
are my sole property, with no one else holding any rights. Only
permission to display the contents of this paper in full, are given,
so that the knowledge herein may be shown to others who may be
interested in asking for any rights to any of these works. Only with
specific written permission is any rights inferred, given, or
authorized.
Michael Harrington's contact information:
Michael Harrington
8116 SE Mill St #22
Portland Oregon, 97212
(971)-285-6279
| |
| NickNitro 2007-11-30, 6:56 pm |
| Michael,
[color=darkred]
instance file 2 can look like any of the following.
You lose me here a bit, but if I understand correctly you are saying
that the possible contents of file 2:
0
00
1
01
1
1
Can occur in any order? But if you have something as you suggested:
0 - 00 - 0 - 1 - 01 - 1 - 1 or
0 - 00 - 0 - 1 - 1 - 1 - 01 or
0 - 00 - 0 - 1 - 1 - 01 - 1 or
0 - 00 - 0 - 01 - 1 - 1 - 1 or
0 - 00 - 0 - 1 - 1 - 01 - 1 or
0 - 01 - 0 - 1 - 1 - 1 - 00 or
Without the seperators, which I'm sure you're already well aware, you
can't store as that requires a 3rd symbol, but binary only provides 2:
000010111 or
000011101 or
000011011 or
000001111 or
000011011 or
001011100 or
This brings in uncertainty straight away as there is no way of knowing
if a 0 is actually a 0 or 00. So take the first one for example:
000010111
Could actually represent (using the possible symbols you list for file
2):
00 00 1 01 1 1 or
00 00 1 0 1 1 1 or
00 0 01 01 1 1 or
00 0 01 0 1 1 1
And quite a number more which I haven't listed. How do you handle this?
| |
| rossum 2007-11-30, 6:56 pm |
| On Fri, 30 Nov 2007 08:28:34 -0800 (PST), Einstein
<michaelhh@gmail.com> wrote:
>Michael Harrington's Recursive Binary Compression Method
>
Two questions:
1 Is your compression lossy? That is can you unambiguously restore
the original file - byte for byte - from the compressed version.
2 Can you compress any file at all or are there some files that are
incompressible using your method.
rossum
| |
| Einstein 2007-11-30, 6:56 pm |
| rossum <rossum48@coldmail.com> wrote:
> On Fri, 30 Nov 2007 08:28:34 -0800 (PST), Einstein
> <michaelhh@gmail.com> wrote:
>
> Two questions:
>
> 1 Is your compression lossy? That is can you unambiguously restore
> the original file - byte for byte - from the compressed version.
>
> 2 Can you compress any file at all or are there some files that are
> incompressible using your method.
>
> rossum
Sorry bout this, exceeded my posting rate (think it was actually the
spammed news releases to 845 different media emails) from Google.
Any how real quickly on the answers:
1) It is lossless.
2) There will be a statistically low number of files that cannot be
compressed from my system, however it would appear, at this time, that
any
of those should be compressible via alternative existing binary
compression
routines.
3) It seperately tracks each bit. The 1 indicates a switch, so
therefore we
know we have in the "next file" a portion of code. We refer to the
command
line to decompress the file then we use the dictionary to undo swaps,
then
if the next value is a 1, we look forward to the next file, or until
we get
a 1, or the known length of the file is found.
Therefore it is entirely possible to have this in file 2 and up:
00000 000 0 000 0000 0 00000 0000 00000
And it all is understood by the system
File 1 will remain an anomoly, as will the last file.
File one will have a pretty predictable pattern statistically, if 4
bits
for instance:
0000 x1
0001 x1
001 x 2
01 x4
1 x8
Only different files will find different valuations based upon
substring
length. Sorry for exceeding my post rate, really irks me I did so
- Einstein
| |
| Willem 2007-11-30, 6:56 pm |
| Einstein wrote:
) File one will have a pretty predictable pattern statistically, if 4
) bits
) for instance:
)
) 0000 x1
) 0001 x1
) 001 x 2
) 01 x4
) 1 x8
That's not a predictable pattern.
SaSW, Willem
--
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 or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
| |
| Einstein 2007-11-30, 6:56 pm |
| Statistically it is actually.
Remember after the first 1 the next data goes to the next file and
continues in there from the sub string
2 bits
00 x1
01 x1
1 x2
3 Bits
000 x1
001x1
01 x2
1 x4
4 bits
0000 x1
0001x1
001 x2
01 x4
1 x8
5 bits
00000 x1
00001 x1
0001 x2
001 x4
01 x8
1 x 16
If you fail to see the pattern I am sorry but it will require longer
to educate you :P
| |
| NickNitro 2007-11-30, 6:56 pm |
| Michael,
Perhaps an example could help things. Would you care to demonstrate
your method in full with the following 24-bit sequence:
010110101101100000000110
Thanks,
Nick.
| |
| Einstein 2007-11-30, 6:56 pm |
| On Nov 30, 10:44 am, NickNitro <NickHo...@googlemail.com> wrote:
> Michael,
>
> Perhaps an example could help things. Would you care to demonstrate
> your method in full with the following 24-bit sequence:
>
> 010110101101100000000110
>
> Thanks,
> Nick.
Certainly, tho I note that so far as I can tell compression will not
work with less than possibly 256 bit strings. This is due to the
demands of the command sections.
010110101101100000000110
Using 3 bit substring
010
110
101
101
100
000
000
110
Then becomes
01-0
1-1-0
1-01
1-01
1-00
000
000
1-1-0
So File #1
01 1 1 1 1 000 000 1 or 0111110000001
File #2
0 0 01 01 00 1 or 000101001
File #3
00
Now that they are seperated to folders, we identify if we need a
dictionary attack.
#1
01 1 1 1 1 000 000 1
#2
0 0 01 01 00 1
#3 (not altering per last file rule, though this is compressible with
a standard huffman 00 = 0)
00
And another error, I keep wanting to apply my method to file 1, but
file 1 is the indicator file.. sigh, error... error... So we cannot
modify it on the same basis. But file #2 is attackable. I also forgot
that if the string is to short, or to long, that we need to 'adjust'
the length appropriately by either removing the excess data and
placing a command section about this, or by adding additional 0's to
the sequence to 'even it out (Thus the [0] later.) My thanks for
helping me correct my mistakes, I am the worlds most forgetful
person :P
File number two has 1 change to 0 as per dictionary attack.... we get:
0 0 01 01 00 0
We then apply the huffman... 00 01 01 00 0[0] = 0 01 01 0 0
(Or if using 01 = 110 then 0 110 110 0 0)
Again this method works on larger files (by far than 24 bits)
| |
| Einstein 2007-11-30, 6:56 pm |
| Feel free to generate a 512 bit file, of any nature, and I will show
step by step compression, then restructuring of it.
| |
| NickNitro 2007-11-30, 6:56 pm |
| On 30 Nov, 19:04, Einstein <michae...@gmail.com> wrote:[color=darkred]
Ok, thanks for that...
| |
| Providence 2007-11-30, 6:56 pm |
| On Nov 30, 11:10 am, Einstein <michae...@gmail.com> wrote:
> Feel free to generate a 512 bit file, of any nature, and I will show
> step by step compression, then restructuring of it.
how about this, using your method:
10111110100010111010001010101110
10111110100010101010001010101111
00111110100010101010001010101110
00111110100010111010001010101111
10111110100010101010001010101101
10111110100010101010001010111011
10111110100010101010001010101101
10111110100010111010001010101111
10111110100010101010001010111010
10111110100010111010001010101110
10111110100010101010001010101010
10111110100010101010001010100110
10111110100010101010001010111110
10111110100010101010001010101110
10111110100011101010001011111110
10111110100010101010001010001110
| |
| Einstein 2007-11-30, 6:56 pm |
| On Nov 30, 12:13 pm, Providence <psioni...@gmail.com> wrote:
> On Nov 30, 11:10 am, Einstein <michae...@gmail.com> wrote:
>
>
> how about this, using your method:
>
> 10111110100010111010001010101110
> 10111110100010101010001010101111
> 00111110100010101010001010101110
> 00111110100010111010001010101111
>
> 10111110100010101010001010101101
> 10111110100010101010001010111011
> 10111110100010101010001010101101
> 10111110100010111010001010101111
>
> 10111110100010101010001010111010
> 10111110100010111010001010101110
> 10111110100010101010001010101010
> 10111110100010101010001010100110
>
> 10111110100010101010001010111110
> 10111110100010101010001010101110
> 10111110100011101010001011111110
> 10111110100010101010001010001110
Certainly, pardon time tho, I just got told to make a Deluxe Website
in about 45 minutes, so I am a lil busy
| |
| Einstein 2007-11-30, 9:56 pm |
| 10111110100010111010001010101110
10111110100010101010001010101111
00111110100010101010001010101110
00111110100010111010001010101111
10111110100010101010001010101101
10111110100010101010001010111011
10111110100010101010001010101101
10111110100010111010001010101111
10111110100010101010001010111010
10111110100010111010001010101110
10111110100010101010001010101010
10111110100010101010001010100110
10111110100010101010001010111110
10111110100010101010001010101110
10111110100011101010001011111110
10111110100010101010001010001110
Ok first step is to break it into several different options 'normally'
to see which one might have best compression (since it is a medium
chance for any compression with 512 bits, but gives good examples of
how the theory works. However I will break it into 4 bit segments and
make it run from there. This gives us a solid base of example work
1011
1110
1000
1011
1010
0010
1010
1110
1011
1110
1000
1010
1010
0010
1010
1111
0011
1110
1000
1010
1010
0010
1010
1110
0011
1110
1000
1011
1010
0010
1010
1111
1011
1110
1000
1010
1010
0010
1010
1101
1011
1110
1000
1010
1010
0010
1011
1011
1011
1110
1000
1010
1010
0010
1010
1101
1011
1110
1000
1011
1010
0010
1010
1111
1011
1110
1000
1010
1010
0010
1011
1010
1011
1110
1000
1011
1010
0010
1010
1110
1011
1110
1000
1010
1010
0010
1010
1010
1011
1110
1000
1010
1010
0010
1010
0110
1011
1110
1000
1010
1010
0010
1011
1110
1011
1110
1000
1010
1010
0010
1010
1110
1011
1110
1000
1110
1010
0010
1111
1110
1011
1110
1000
1010
1010
0010
1000
1110
This becomes:
1 01 1
1 1 1 0
1 000
1 01 1
1 01 0
001 0
1 01 0
1 1 1 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 1 1 1
001 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 1 1 0
001 1
1 1 1 0
1 000
1 01 1
1 01 0
001 0
1 01 0
1 1 1 1
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 1 01
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 1
1 01 1
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 1 01
1 01 1
1 1 1 0
1 000
1 01 1
1 01 0
001 0
1 01 0
1 1 1 1
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 1
1 01 0
1 01 1
1 1 1 0
1 000
1 01 1
1 01 0
001 0
1 01 0
1 1 1 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 01 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
01 1 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 1
1 1 1 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 01 0
1 1 1 0
1 01 1
1 1 1 0
1 000
1 1 1 0
1 01 0
001 0
1 1 1 1
1 1 1 0
1 01 1
1 1 1 0
1 000
1 01 0
1 01 0
001 0
1 000
1 1 1 0
This is with tabs designating different files
File #1 looks like:
1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 001 1 1 1 1 001 1 1 001 1 1 1 1
001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1
1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1
1 1 001 1 01 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1
1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 001 1 1 1 1 001 1 1
001 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001
1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1
001 1 1 1 1 1 1 1 001 1 01 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1
1 001 1 1 1 1 1 1 1 001 1 1
File #2 looks like:
01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 1 1 1 000 01 01 0 01 1 1 1
000 01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000
01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01
01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01 01 0 01 1 01 1 000 01 01
0 01 1 01 1 000 01 01 0 01 1 01 1 000 1 01 0 1 1 01 1 000 01 01 0 000
1
File #3 looks like:
1 1 1 0 0 1 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0 1 1 1 0 0 0 01 1 1 0 0 1 1 1
1 0 0 0 01 1 1 1 0 0 1 1 1 0 0 1 0 1 1 1 0 0 1 1 1 0 0 0 0 1 1 0 0 0 0
1 1 0 0 1 1 1 1 0 0 0 1 1 1 1 0 1 1 1 1 0 0 1
File #4 looks like:
0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
In file #2 there is
0 = 16
000 = 17
01 = 62
1 = 33
In File #3 there is:
1 = 50
01 = 2
0=41
In file #4 there is
1 = 3
0 = 24
(Dang that one is so compressible, guess I should allow for
compression in that one if feasable)
Ok ly it is time for me to get serious about my "Command Section".
Ok so lets start this way, First 4 bits tells us Substring Length.
Since Substring Length = # "files" we then know how many files we need
based on Substring length. We will then us 2 bits to say the following
four file sizes: "Under 1000 bits", "Over 0 under 10,000", Over
"10,000 under 1,000,000" and then "Over 1,000,000". I will make a
'special means (already previously made, but no need to bring it here
for now since I will not demo 1 million bits just yet). This gives us
a Size "per file". Since we fit catagory #1 at all times this means we
can simply use 14 bits per file to identify the exact length of each.
This means so far our command section consists of 4+2+(14*4).
Each file will then need "Compress with expected Huffman? Don't
compress at all? Compress with Alternate Huffman? Or Compress with
Entirely different routine?" This means each file has added 2 more
bits to their sizes. Though if the 4th choice is used we need to have
a series of bits to identify each one. Each file will need an
additional 1 bit to say "Dictionary, yes or no?". Also we need space
for the dictionaries replacements itself. We will assume that there is
substring size/2 rounded down for maximum transpositions. Additionally
we need for each transposition to know the size we are dealing with.
Therefore each transposition will require 2 bits to identify length,
and then the exact information being swapped. We will have to
temporarily make transpositions on equal sizes only, which can be
changed later but at higher command section size costs. We will say
that we can designate the same string to represent no change, ergo 1
changes to 1 = no change.
Before I continue to compress I wish to show how to reverse engineer
my current set up.
File #1 looks like:
1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 001 1 1 1 1 001 1 1 001 1 1 1 1
001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1
1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1
1 1 001 1 01 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1
1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 001 1 1 1 1 001 1 1
001 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001
1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1 1
001 1 1 1 1 1 1 1 001 1 01 1 1 1 1 1 001 1 1 1 1 1 1 1 001 1 1 1 1 1 1
1 001 1 1 1 1 1 1 1 001 1 1
File #2 looks like:
01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 1 1 1 000 01 01 0 01 1 1 1
000 01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000
01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01
01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01 01 0 01 1 01 1 000 01 01
0 01 1 01 1 000 01 01 0 01 1 01 1 000 1 01 0 1 1 01 1 000 01 01 0 000
1
File #3 looks like:
1 1 1 0 0 1 1 1 0 0 0 1 1 0 0 0 1 1 1 0 0 1 1 1 0 0 0 01 1 1 0 0 1 1 1
1 0 0 0 01 1 1 1 0 0 1 1 1 0 0 1 0 1 1 1 0 0 1 1 1 0 0 0 0 1 1 0 0 0 0
1 1 0 0 1 1 1 1 0 0 0 1 1 1 1 0 1 1 1 1 0 0 1
File #4 looks like:
0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
We find the first bit in file #1. It happens to be a 1. Therefore we
know bit #2 is located inside File #2. In file #2 we see the first bit
is a 0, therefore the next bit in file #2 is also added to the 4 bit
substring we are regenerating. This next bit is a 1, therefore we goto
file #3 to obtain the last bit. Even though file #3 IS A 1, we DO NOT
coninue since this is the last bit of the substring. We instead return
to file #1 at the next applicable bit. And we repeat the sequence.
Now to start our dictionary swaps as needed.
File #1 is UNABLE TO BE DICTIONARIED. This is due to the fact it is
not tracked by a prior file, and any efforts to dictionary it, if not
designed properly, would be a disaster. I prefer to avoid this, but it
is possible to create a dictionary if truly desired, just not the same
way we apply the term dictionary to the other sequences.
File #2 has 129 total 0's and 95 total 1's inside it. This is not
normally 'condusive to huffman compression'. Swapping 01 for 00, and 1
for 0 costs us 10 bits in the command section. However we then have
208 total 0's and 16 total 1's.
This means our file goes from:
01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 1 1 1 000 01 01 0 01 1 1 1
000 01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000
01 01 0 01 1 01 1 000 01 01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01
01 0 01 1 01 1 000 01 01 0 01 01 01 1 000 01 01 0 01 1 01 1 000 01 01
0 01 1 01 1 000 01 01 0 01 1 01 1 000 1 01 0 1 1 01 1 000 01 01 0 000
1
To:
00 0 000 00 00 1 00 0 00 0 000 00 00 1 00 0 1 0 000 00 00 1 00 0 1 0
000 00 00 1 00 0 00 0 000 00 00 1 00 0 00 0 000 00 00 1 00 00 00 0 000
00 00 1 00 0 00 0 000 00 00 1 00 0 00 0 000 00 00 1 00 00 00 0 000 00
00 1 00 0 00 0 000 00 00 1 00 00 00 0 000 00 00 1 00 0 00 0 000 00 00
1 00 0 00 0 000 00 00 1 00 0 00 0 000 0 00 1 0 1 00 0 000 00 00 1 000
0
File #3 is a "mess" and does not bode well for compression. Therefore
we choose "Do not compress at all" and save ourselves some work on
dictionaries.
File #4 actually will compress very nicely and will say no to a
dictionary result because it is the last string, it will ONLY have 1's
or 0's.
Our compression will start with each file seperately
File #1 we will say used an ALTERNATIVE compression utility. We will
say there is 4 bits standing for 16 different main methods, and this
was an additional 4 bits inside one of those methods, so command
section has grown by 8 bits.
This is 111 = 1, 110 = 01, 10 = 001, 0 = 000
We had:
1111100111111110011100111110011100111110
0111111110011111
1110011111111001111111100111111110011111
1110011111111001
1111111001101111110011111111001111111100
1111111100111111
1100111111110011100111110011100111110011
1111110011111111
0011111111001111111100111111110011111111
0011111111001111
1111001101111110011111111001111111100111
1111100111
We get:
1010001101000100000010100010000001010001
1010001101000110
1000110100011010001101000110100011010000
1110000001101000
1101000110100011010001101000100000010100
0100000010100011
0100011010001101000110100011010001101000
1101000110100001
110000001101000110100011010001
We saved 41 bits on File #1
File #2 compresses using a standard huffman from:
0000000000100000000000001000100000000100
0100000000100000
0000000010000000000000100000000000000100
0000000000010000
0000000001000000000000001000000000000010
0000000000000100
0000000000010000000000000100000000000010
1000000000010000
To:
0000011000000011001100001001000001100000
0011000000011000
0000100000001000000010000000011000000011
0000000100000001
00000001000000011011000001000
Which is 83 bits smaller
File #3 is uncompressible, and was designated as such.
File #4 is compressible and starts from:
0001000100001000000000001000
To:
01001000110000001100
This saves us 8 bits
Our command section had: 4 bits for substring length, 2(*4) bits per
file for file size ranges (after compression). 14(*4) bits per file
for the exact count of bits in each file. We had 2(*4) bits for the
Determination of Huffman, Alt Huff, No Compress, or Different routine.
File #1 spent 2 bits to determine we were using an alternative, 4 bits
to say which alternative, and 4 bits for the specific variation of the
alternative. File #2 used 2 bits to determine it will use a standard
huffman, it needed a dictionary as well this was 1 bit, the dictionary
was 1 bit to say how many changes, and then what exact changes (For 10
bits total). File #3 had 2 bits to say "DO NOT TOUCH!". File #4 had no
dictionary possible (last one) and a standard huffman for 2 points.
Thus to find out how I did.
We saved a grand total of 132 bits. Our command section cost us: 104
From 512 bits we obtained a compression change of 0.0546875 less than
starting size.
| |
| Providence 2007-12-01, 3:56 am |
| On Nov 30, 7:49 pm, Einstein <michae...@gmail.com> wrote:
> 10111110100010111010001010101110
> ......
> From 512 bits we obtained a compression change of 0.0546875 less than
> starting size.
awesome, glad to hear you've been successful in sorting out the
command section.
thanks for the example, there's nothing there that makes me doubt the
lossless nature, or doubt that it looses the ability to be folded into
another data layer.
i like your first 'file' having no way to utilize a dictionary either,
i figured there was some 'chaos' element inside the streaming
procedure.. your ability to segment logically per bit while still
maintaining cohesion overall should enable you to write a proper
mathematical description, or if not yourself someone else who pokes at
the method with mathematical tools.
decompilation into elements and a reassociation layer ended up doing
it... go figure ;P
'grats.
i'd like to offer you my experience in writing for graphics card
software to convert this algorithm to nvidia's gp-gpu format, which
uses their top-of-the-line-two-years-ago graphics cards to do really
quite alot of parallel instructions at once. we could also pump it out
to a screen saver so users could get some good visuals while looking
at their harddrives recompose their archived data into smaller and
smaller bits.
if you're interested, email me.
chris.
| |
| Einstein 2007-12-01, 3:56 am |
| There was one additional condition that was not 'seen'. This is when
we have an "odd length" that is hanging on the end of a line to be
compressed. I could either make an entry in the command line for each
file of any "leftovers" and the value of them and remove them from the
specific file, or I can add a series of 0's or 1's to the end of the
sequence to make it 'evened' and make a command area note of the
action. I prefer the latter, though the former is possible.
My gmail is "blocked" for upto 24 hours I guess, for sending to many
emails to media :(
| |
| Willem 2007-12-01, 7:56 am |
| Einstein wrote:
) Statistically it is actually.
)
) Remember after the first 1 the next data goes to the next file and
) continues in there from the sub string
)
) 2 bits
) 00 x1
) 01 x1
) 1 x2
)
) 3 Bits
) 000 x1
) 001x1
) 01 x2
) 1 x4
)
) 4 bits
) 0000 x1
) 0001x1
) 001 x2
) 01 x4
) 1 x8
)
) 5 bits
) 00000 x1
) 00001 x1
) 0001 x2
) 001 x4
) 01 x8
) 1 x 16
)
) If you fail to see the pattern I am sorry but it will require longer
) to educate you :P
If you flip a fair coin until you get heads, or N times at most, then the
above distribution is what you will get. Therefore it is not predictable.
SaSW, Willem
--
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 or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
| |
| Willem 2007-12-01, 7:56 am |
| Einstein wrote:
) So File #1
) 01 1 1 1 1 000 000 1 or 0111110000001
)
) File #2
) 0 0 01 01 00 1 or 000101001
)
) File #3
) 00
Am I understanding correctly that you're splitting a single file into
multiple files ? You do realise that you have to add log2(N) bits to
the size of a file that contains N bits, for comparison purposes, right ?
SaSW, Willem
--
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 or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
| |
| Einstein 2007-12-01, 6:56 pm |
| William:
1) this is based on statistics, not 'actual occurences'. Statistics I
can go in great length on in huge files. In fact the larger the
file... but I wont go there right now, time to answer your 'issues'
first. By basing it on statistics we learn about the possibilities of
things occuring
In a binary sequence the odds of a 1 occuring next is 50% "usually"
with a small margin of error, so long as the sequence is sufficiently
long. If the sequence is shorter we could have a significant margin of
error. My table I posted SPECIFICALLY for you was showing the odd of a
1 occuring at different bit lengths in the last location in the first
file. 50%, 25%, 12.5%, 6.25%, 3.125% and so forth, representing 1 bit,
2 bits, 3 bits, 4 bits, 5 bits, and so forth.
2) No I use the term file for those, who like me, need a more "visual"
look to something, even if this is not exactly what we are doing.
| |
| Industrial One 2007-12-01, 6:56 pm |
| On Dec 1, 8:34 am, Einstein <michae...@gmail.com> wrote:
> William:
lol "William."
| |
| Einstein 2007-12-01, 6:56 pm |
| doh, typo :o
lol
| |
| NickNitro 2007-12-01, 6:56 pm |
| On 30 Nov, 15:11, Einstein <michae...@gmail.com> wrote:
Michael,
Bad luck old pal... It seems I've found a problem in your 'Alteration
Stage', essentially meaning the data you put into your compressor is
very much on a one way trip. In some very rare cases it is possible to
compress, but generally there is either no compression possible (even
with the dictionary attack), or any attempt at a dictionary attack
leaves the data in that file very corrupted (see my first question for
a pointer to why it doesn't work)... Nevertheless do keep trying!
Nick.
| |
| Phil Carmody 2007-12-01, 6:56 pm |
| Industrial One <industrial_one@hotmail.com> writes:
> On Dec 1, 8:34 am, Einstein <michae...@gmail.com> wrote:
>
> lol "William."
Wilhelm?
Guillaume?
Bill?
but at least not
Billy Bob
Because we know our Willem doesn't drive NASCAR. ;-)
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
| |
| NickNitro 2007-12-01, 6:56 pm |
| On 30 Nov, 15:11, Einstein <michae...@gmail.com> wrote:[color=darkred]
p to the task of creating software for the code as well.
I'm fluent in C/C++, Java and ASM and charge =A380 (GBP Sterling) per
codec you design, although I require the fees up front (obviously
there'll be a written contract to protect us both before you hand over
the money and design) but I'll work until the codec is fully
programmed. This doesn't mean I'm responsible for your codec not
meeting your expectations, but if your design it, I'll code it...
Nick.
| |
| Einstein 2007-12-01, 6:56 pm |
| On Dec 1, 3:31 pm, NickNitro <NickHo...@googlemail.com> wrote:
> On 30 Nov, 15:11, Einstein <michae...@gmail.com> wrote:
>
> Michael,
>
> Bad luck old pal... It seems I've found a problem in your 'Alteration
> Stage', essentially meaning the data you put into your compressor is
> very much on a one way trip. In some very rare cases it is possible to
> compress, but generally there is either no compression possible (even
> with the dictionary attack), or any attempt at a dictionary attack
> leaves the data in that file very corrupted (see my first question for
> a pointer to why it doesn't work)... Nevertheless do keep trying!
>
> Nick.
Sir I ran a statistical attack, statistically it does compress. This
means that some will not, some will. I refute your position since you
have clearly not posted evidence, despite supposedly 'creating it'.
In fact of all the posters here, you remain the most  of the
capabilities, and how it is supposed to run.
Allow me to do a demonstration
00
01
10
11
This becomes 00011011
Use this logic routine on that table and resulting binary line.
Read 2 bits, place in buffer.
If first bit = 1, the 1 stays in the sequence, but then following bit
goes to a separately tracked region.
If first bit = 0 then both bits stay in sequence
Sequence is then moved to the "compress stage" temp file.
Read 2 bits, place in buffer.
If first bit = 1, the 1 stays in the sequence, but then following bit
goes to a separately tracked region.
If first bit = 0 then both bits stay in sequence
Sequence is then moved to the "compress stage" temp file.
repeat til all 8 bits are filtered.
The separately tracked region is 100% tracked. There is no room for
error in that portion of the sequence. There is no doubt at all, and I
would put a $25,000 bet that there is no error. If you wish to
provide a monetary reward if I can prove it works, I will take that
money tomorrow.
Any stage of this independently works, and as a whole works. I am
quite willing to provide evidence upon any section. Just provide a
reward as incentive for the additional time away from making software,
or just hire me to provide the evidence. I can, and will, stand by the
methods here with 100% certainty of the outcomes.
| |
| NickNitro 2007-12-01, 6:56 pm |
| >> I refute your position since you have clearly not posted evidence, despite supposedly 'creating it'.
Unfortunately I can't post mathematical evidence, my math skills are
that of a 10 year old... However...
[color=darkred]
Your algorithm in a C++ program says different. ;)
[color=darkred]
That's why I asked the questions I did, which cleared it up for me.
[color=darkred]
So having all the money in the world wouldn't be enough? You'd want to
win a $25,000 bet? If it worked, you wouldn't need to bet any wager,
as you'd have MS banging on your door and be given more money than
could be printed.
[color=darkred]
Very well, but I don't see why you don't just approach a few bluechip
companies with your design and tell them to start bidding - they'll
bite your hand off!
| |
| Einstein 2007-12-01, 6:56 pm |
| well I currently have someone working on software. He agrees it works
in full.
We are working on a version to get benchmarks, not a 'model' but a
'functional benchmark comparison program'.
I do have a Microsoft contact now that I think of it, perhaps I will
email him as well later when we have the software up.
| |
| NickNitro 2007-12-01, 6:56 pm |
| > well I currently have someone working on software. He agrees it works in f=
ull.
Wonderful! :)
> I do have a Microsoft contact now that I think of it, perhaps I will email=
him as well later when we have the software up.
Even better! But do yourself a favour and tell your programmer to take
his finger from places where it shouldn't be and get the software done
(or I can do it for you for a straight =A380 GPB including you holding
all rights to the source code etc...). It shouldn't take more than 6
hours tops, any longer and he's taking you and your wallet for a
ride...
| |
| Einstein 2007-12-01, 6:56 pm |
| On Dec 1, 4:36 pm, NickNitro <NickHo...@googlemail.com> wrote:
full.[color=darkred]
>
> Wonderful! :)
>
il him as well later when we have the software up.[color=darkred]
>
> Even better! But do yourself a favour and tell your programmer to take
> his finger from places where it shouldn't be and get the software done
> (or I can do it for you for a straight =A380 GPB including you holding
> all rights to the source code etc...). It shouldn't take more than 6
> hours tops, any longer and he's taking you and your wallet for a
> ride...
Lol he has not asked for compensation of any nature.
Do you think the huffman works?
The dictionary?
Do you have any issues with either of those?
Or is it just the core of the invention, the seperation process?
| |
| NickNitro 2007-12-01, 9:57 pm |
| On 2 Dec, 00:55, Einstein <michae...@gmail.com> wrote:
> On Dec 1, 4:36 pm, NickNitro <NickHo...@googlemail.com> wrote:
>
in full.[color=darkred]
>
>
mail him as well later when we have the software up.[color=darkred]
>
>
> Lol he has not asked for compensation of any nature.
I guess you can't complain too much then, just make sure that there's
no mistake that what he writes you own. ;)
> Do you think the huffman works?
Flawlessly...
> The dictionary?
The dictionary itself is fine again. It's when you apply the
dictionary to a file then take out the seperators for that file is
where the problem seems to be.
Still, I'm hoping for your sake (and mine!... I would appreciate a
faster Internet connection. ;) that I'm mistaken...
All the best,
Nick.
| |
| Einstein 2007-12-01, 9:57 pm |
|
Ok time to validate you. You are correct sir
110101111
If using 3 bit subbstrings
File One:111
File two: 1011
File three: 01
Seperate the first bit in the first file
1
This indicates we need to get the first bit in file two
1
This indicates we need for our last bit of the substring, the first
bit of file three
0
Therefore the first restructured substring is 110
Now we reduce the files by the data removed
11
011
1
Now take the first bit from file one
1
This indicates we take a bit from the next file
0
This indicates we take another bit from the same file
1
This was the third bit in our substring, so we add it to the
previously recovered substring(s) in our binary stream we are
regenerating. 110101
We adjust our remaining files to reflect the used data
1
1
1
this one is obvious
We try to dictionary swap, 0 for 1, and 01 to 00. In file #2 alone. We
then see
File One:111
File two: 0000
File three: 10
Well first bit = 1
So we goto file 2, and we cannot determine if it was 01, or 1.
I was wrong, and I admit this.
Examination of the statistics here is where I got hung up last time,
and the dictionary worked for 9 or so times. I must have lucky ways to
write it out :(
Ergo I am back to my asking, what is the statistical situation with
these type outcomes:
00
01
0
1
1
1
000
001
00
0
1
1
1
1
and so forth.
I am wracking my head now to fix this issue. Give me 4 hours.
| |
| NickNitro 2007-12-01, 9:57 pm |
| On 2 Dec, 02:41, Einstein <michae...@gmail.com> wrote:
[color=darkred]
Hehe, not to worry, must be said though... 10/10 for effort! It's
happened to me many times coming up with something only to find
there's a small problem that's caused the cards to collapse. Still, in
the worlds of Edison: "I have not failed. I've just found 10,000 ways
that won't work."...
[color=darkred]
When I said I had the math skills of a 10 year old, I was lying, I'm
probably at a 14-15 year olds level - but still not the man you should
be asking. ;)
All the best for the next test,
Nick.
| |
| Einstein 2007-12-02, 3:56 am |
| Well it is a start of a theory, need to crunch some numbers
but what if we used on 2 sets of file #2 type data... There are some
outcomes that will occur WAY MORE often (11 type results) than others,
and then some that occur somewhat more often than others (1+x or x+1
results).
This information should be attackable.
11 = 9
001 = 4
01 = 3
10 = 3
101 = 3
011 = 3
100 = 3
000 = 2
0001 = 1
0000 = 1
0100 = 1
00 = 1
010 = 1
0101 = 1
But at this moment I lack the ability to reckon this out.
| |
| Einstein 2007-12-02, 6:56 pm |
| Additional answers I cannot generate on my own...
Once the data is parsed via the sorter, what effect of "resorting" is
there, and does this create a statistical anomaly?
| |
| Einstein 2007-12-02, 6:56 pm |
| Actually I have some interesting results once again, but I will reason
this trail out before I post... I am so upset I posted with erroneous
material
| |
| geert.schrooten@gmail.com 2007-12-02, 6:56 pm |
| On 2 dec, 16:44, Einstein <michae...@gmail.com> wrote:
> Actually I have some interesting results once again, but I will reason
> this trail out before I post... I am so upset I posted with erroneous
> material
Micheal,
Did you test your compression on real data (movie/mp3/Compressed
files), or only generated bits? I haven't read your invention
description fully, sure to look into tomorrow.
PS: I know the feeling, I have discovered a dead ending on my
compression yesterday.
| |
| earlcolby.pottinger@sympatico.ca 2007-12-02, 6:56 pm |
| On Dec 2, 12:28 am, Einstein <michae...@gmail.com> wrote:
> well I currently have someone working on software. He agrees it works
> in full.
Do you know how many times we have heard that? What does your
programmer know about compression? And has he tried doing any
decompression yet? I doubt it.
> We are working on a version to get benchmarks, not a 'model' but a
> 'functional benchmark comparison program'.
Good on trying for a full version, but what are you going to do when
it does not work?
> I do have a Microsoft contact now that I think of it, perhaps I will
> email him as well later when we have the software up.
Please wait, prove your code works with real data first. Trust me on
this much at-least. :)
| |
| earlcolby.pottinger@sympatico.ca 2007-12-02, 6:56 pm |
| On Dec 2, 12:36 am, NickNitro <NickHo...@googlemail.com> wrote:
[color=darkred]
> It shouldn't take more than 6
> hours tops, any longer and he's taking you and your wallet for a
> ride...
Good point, there are some programmers out there that will pad their
bills, what you want is simple to code, don't let him take your money
without limit.
| |
| earlcolby.pottinger@sympatico.ca 2007-12-02, 6:56 pm |
| Ouch, I just read where you finally spotted the fault in your system.
Congrats, on admitting the error in public. Too often in the past
someone comes in boasting, does not want to listen to suggestions,
then vanishes without admitting any error.
Now, all you have to do in the future, is to do more testing before
making bold claims about being so smart to spot a compression method
that no-one else looked at.
Test more first.
| |
| George Johnson 2007-12-02, 9:56 pm |
| "Einstein" <michaelhh@gmail.com> wrote in message
news:d286c567-aa10-4c79-99d3-2f1c250920b5@b40g2000prf.googlegroups.com...
| Michael Harrington's Recursive Binary Compression Method
|
| This is a Whitepaper, recognized in international law, as a source of
| original idea for science releases. I have 1 year from the release
| date of this Whitepaper to Patent it according to International Law.
| This is also US law.
I'll believe it when I see it given that your own internal
file-separation rules are wonky and inconsistent.
You also are ignoring the sacred "escape character" (which requires
digits to indicate as well) indexing.
| |
| Einstein 2007-12-03, 3:56 am |
| yes yes, to all the posts.
We are working a couple different paths, a couple volunteers and
myself.
A) What sort of patterns are made by long iterations of the file #2
and up.... since size differentials on trackable information is in
existance, is it attackable?
B) Dividing a total file into x substrings, where X may be a number
from 1 up to bits/2, where calculating the odds of occurence of longer
strings of 1 versus longer strings of 0, and what can occur within
these plausible variations. (for instance if I divide a gigabyte into
10 substrings, this means a maximum length of ten 1 results, but up to
1/10th the gigabyte in 0 strings, but of course the likely hood of a
longer than x sized string of 0's needs calculating)
C) Repetitioning the first stage, where sorting to different files
occurs, on each file, creating a "new look". Basis in this is simple,
using 3 bits file #1 results:
000
001
01
01
1
1
1
1
If repetitions occur we have a the last bit in each substrings
remainder having a 7/8 chance of being a 1, where the first bit has a
1/2 chance of being a 1. Deduction says this should lead to a higher
probability of 11 results, or at least it seems so up front.
These are the three main theories to try to salvage this, if it can
be :(
| |
| tchow@lsa.umich.edu 2007-12-03, 9:56 pm |
| In article <d286c567-aa10-4c79-99d3-2f1c250920b5@b40g2000prf.googlegroups.com>,
Einstein <michaelhh@gmail.com> wrote:
>This is a Whitepaper, recognized in international law, as a source of
>original idea for science releases. I have 1 year from the release
>date of this Whitepaper to Patent it according to International Law.
>This is also US law.
If you're seriously looking at international patents, check the laws
of the individual countries carefully. The U.S. does indeed give you
a one-year grace period between the public disclosure of your invention
and the filing date of your patent application. But while a U.S. application
is recognized by all PCT countries, some countries may not allow public
disclosure of the invention prior to the application filing date.
--
Tim Chow tchow-at-alum-dot-mit-dot-edu
The range of our projectiles---even ... the artillery---however great, will
never exceed four of those miles of which as many thousand separate us from
the center of the earth. ---Galileo, Dialogues Concerning Two New Sciences
| |
| David Eather 2007-12-03, 9:56 pm |
| tchow@lsa.umich.edu wrote:
> In article <d286c567-aa10-4c79-99d3-2f1c250920b5@b40g2000prf.googlegroups.com>,
> Einstein <michaelhh@gmail.com> wrote:
>
> If you're seriously looking at international patents, check the laws
> of the individual countries carefully. The U.S. does indeed give you
> a one-year grace period between the public disclosure of your invention
> and the filing date of your patent application. But while a U.S. application
> is recognized by all PCT countries, some countries may not allow public
> disclosure of the invention prior to the application filing date.
Australia does not allow disclosure
| |
| Industrial One 2007-12-03, 9:56 pm |
| On Dec 1, 4:37 pm, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Industrial One <industrial_...@hotmail.com> writes:
>
>
> Wilhelm?
>
> Guillaume?
>
> Bill?
>
> but at least not
>
> Billy Bob
>
> Because we know our Willem doesn't drive NASCAR. ;-)
>
> Phil
> --
> Dear aunt, let's set so double the killer delete select all.
> -- Microsoft voice recognition live demonstration
GUILLAUME? Wow. Imagine "Billy Bob Guillaume." Anyone with that kinda
name should be lined up and shot.
Not that I blame Einsteen, when I first saw Willem's s/n in Feb. 2005,
I perceived it as "William." What is he some scandinavian mofo?
'wonder how that shit's pronounced.
| |
| Greg Rose 2007-12-03, 9:57 pm |
| In article <d286c567-aa10-4c79-99d3-2f1c250920b5@b40g2000prf.googlegroups.com>,
Einstein <michaelhh@gmail.com> wrote:
>Michael Harrington's Recursive Binary Compression Method
>
>This is a Whitepaper, recognized in international law, as a source of
>original idea for science releases. I have 1 year from the release
>date of this Whitepaper to Patent it according to International Law.
>This is also US law.
Yes, it is US law. I'm not sure what you mean by
international law, but this is not the case in
almost any other country. It isn't in the GATT
(General Agreement on Trade and Tariffs) treaty.
Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
Qualcomm Australia: http://www.qualcomm.com.au
| |
| Matt Mahoney 2007-12-03, 9:57 pm |
| On Dec 1, 6:46 pm, NickNitro <NickHo...@googlemail.com> wrote:
> On 30 Nov, 15:11, Einstein <michae...@gmail.com> wrote:
>
up to the task of creating software for the code as well.[color=darkred]
>
> I'm fluent in C/C++, Java and ASM and charge =A380 (GBP Sterling) per
> codec you design, although I require the fees up front (obviously
> there'll be a written contract to protect us both before you hand over
> the money and design) but I'll work until the codec is fully
> programmed. This doesn't mean I'm responsible for your codec not
> meeting your expectations, but if your design it, I'll code it...
>
> Nick.
Who gets the blame when the program doesn't work? The programmer who
can't find the bug, or the designer who doesn't understand the
counting argument?
-- Matt Mahoney
| |
| NickNitro 2007-12-03, 9:58 pm |
| On 3 Dec, 14:55, tc...@lsa.umich.edu wrote:
> In article <d286c567-aa10-4c79-99d3-2f1c25092...@b40g2000prf.googlegroups.com>,
>
> Einstein <michae...@gmail.com> wrote:
>
> If you're seriously looking at international patents, check the laws
> of the individual countries carefully. The U.S. does indeed give you
> a one-year grace period between the public disclosure of your invention
> and the filing date of your patent application. But while a U.S. application
> is recognized by all PCT countries, some countries may not allow public
> disclosure of the invention prior to the application filing date.
> --
> Tim Chow tchow-at-alum-dot-mit-dot-edu
> The range of our projectiles---even ... the artillery---however great, will
> never exceed four of those miles of which as many thousand separate us from
> the center of the earth. ---Galileo, Dialogues Concerning Two New Sciences
Neither does the UK...
| |
| NickNitro 2007-12-03, 9:58 pm |
| On 3 Dec, 20:13, Matt Mahoney <matmaho...@yahoo.com> wrote:
> On Dec 1, 6:46 pm, NickNitro <NickHo...@googlemail.com> wrote:
>
>
er up to the task of creating software for the code as well.[color=darkred]
>
>
>
> Who gets the blame when the program doesn't work? The programmer who
> can't find the bug, or the designer who doesn't understand the
> counting argument?
>
> -- Matt Mahoney
Good point, that's why I stated:
This doesn't mean I'm responsible for your codec not meeting your
expectations, but if your design it, I'll code it...
If he 'designed' a perfect compressor - I'll program his design, but
I'm not responsible for it not working as he expected... Saying that
if he designed the algorithms in full, then it would never even get to
the programming stage. ;)
| |
| Matt Mahoney 2007-12-04, 6:56 pm |
| On Dec 3, 8:00 pm, NickNitro <NickHo...@googlemail.com> wrote:
> On 3 Dec, 20:13, Matt Mahoney <matmaho...@yahoo.com> wrote:
>
>
>
>
>
mmer up to the task of creating software for the code as well.[color=darkred]
>
[color=darkred]
>
>
>
>
> Good point, that's why I stated:
> This doesn't mean I'm responsible for your codec not meeting your
> expectations, but if your design it, I'll code it...
> If he 'designed' a perfect compressor - I'll program his design, but
> I'm not responsible for it not working as he expected... Saying that
> if he designed the algorithms in full, then it would never even get to
> the programming stage. ;)
Well good luck with that. Nobody else can convince him he's wrong,
even though it's perfectly obvious.
-- Matt Mahoney
| |
| Einstein 2007-12-04, 9:56 pm |
| The basis of science, and of learning, is that you look at
everything.
But then I shall have my other theories, not as effective, but "still"
| |
| Providence 2007-12-06, 6:56 pm |
| On Dec 4, 5:02 pm, Einstein <michae...@gmail.com> wrote:
> The basis of science, and of learning, is that you look at
> everything.
>
> But then I shall have my other theories, not as effective, but "still"
i think folding lossless compression is about as difficult as time
travel into the past.. I've done extensive studies with the various
bases as a final limit of utilizing the mathematical quantization of
'quantity' into a digital format. in the end, the individual base
needs to be encoded which equalizes any gains inside the system, and
expands the computation to the nth degree.
personally, i feel justified working on a 'workable' system that
illuminates some of the more chaotic-appearing elements of the
universe.
an interesting abstract of what occurs if lossless folding of
information is *actually* really impossible to do, is that the sub-
quantum world is vastly different, and doesn't contain any memory.. at
which point the memory is located on the edges of the universe/black
hole/etc, and all things that would appear to be looped, concrete
'rules' are actually sections of interacting generators, which are
extruding formless information into single quanta, at which point it
is the quanta interacting with each other that give rise to
information.
so, basic basic basic, how did we originally encode the information
even into it's format whatsoever? this is the key, this is the place
where the log2(n) bits comes into play to s out the index of the
generator interaction.
less of a question of how dense the information is, more of a question
of exactly where does any information come from at all. at this point,
fractals, frequency, and geometry come into play rather than straight
infinitely-to-its-limit permutable single dimensions.. which may or
may not be expanding or contracting at any given measurement.
chris.
| |
| George Johnson 2007-12-06, 6:56 pm |
| "Providence" <psionic81@gmail.com> wrote in message
news:7091b1dd-8415-4b6e-90e6-3ad38fb422c5@a39g2000pre.googlegroups.com...
| On Dec 4, 5:02 pm, Einstein <michae...@gmail.com> wrote:
| > The basis of science, and of learning, is that you look at
| > everything.
| >
| > But then I shall have my other theories, not as effective, but "still"
|
| i think folding lossless compression is about as difficult as time
| travel into the past.. I've done extensive studies with the various
| bases as a final limit of utilizing the mathematical quantization of
| 'quantity' into a digital format. in the end, the individual base
| needs to be encoded which equalizes any gains inside the system, and
| expands the computation to the nth degree.
|
| personally, i feel justified working on a 'workable' system that
| illuminates some of the more chaotic-appearing elements of the
| universe.
|
| an interesting abstract of what occurs if lossless folding of
| information is *actually* really impossible to do, is that the sub-
| quantum world is vastly different, and doesn't contain any memory.. at
| which point the memory is located on the edges of the universe/black
| hole/etc, and all things that would appear to be looped, concrete
| 'rules' are actually sections of interacting generators, which are
| extruding formless information into single quanta, at which point it
| is the quanta interacting with each other that give rise to
| information.
|
| so, basic basic basic, how did we originally encode the information
| even into it's format whatsoever? this is the key, this is the place
| where the log2(n) bits comes into play to s out the index of the
| generator interaction.
|
| less of a question of how dense the information is, more of a question
| of exactly where does any information come from at all. at this point,
| fractals, frequency, and geometry come into play rather than straight
| infinitely-to-its-limit permutable single dimensions.. which may or
| may not be expanding or contracting at any given measurement.
|
|
| chris.
I'll give you a hint.
Think of a circle for a moment. You are at the center of the circle.
In 2-Directional space there are 2 directions on can go in. You can go
in any direction from the center of the circle to any location on the outer
point of the circle BUT the other direction you can travel in 2D space is by
way of SPIN. In this mental example, the circle is a symbol for the
infinite spatial plane of movement.
In 3-Directional space (not up-down, back-forward, or left-right as
those examples are poor mental fuel) you are now in the center of a sphere.
As with 2-Directional space you can spin in one direction or move in any
direction to the exterior of the sphere. You also get another direction of
spin available (a non-obvious one) in 3D space.
Also note that for any level of functionality, a 2-Directional spacial
zone has to allow the temporal direction (4D space) and the potentiality
direction (5D space). Also note that with each increase of spacial zones,
you also encounter alternate directions of spin. Temporal movement is just
another direction of atomic spin that is not easily altered in standard 3D
space.
It is very feasible that the quantum noise of "zero point energy" is
merely energy or matter moving in an anti-time-forward spin in time and
destructing against forward-time-spin matter. Also note that are more than
merely 5-directions of movement happening at all time, but most of it occurs
at the subatomic level.
This should be obvious why in a simple thought experiment. Take a cube
in 3D space. It has 6 sides. If it were a heat source in space it would
radiate thermal energy at a predictable level. Now shift your thoughts to a
hypercube in 4D space. How many sides? 24. Yep, more surface energy
equals a higher rate of radiant energy being lost. What is the most logical
way to minimize energy loss? Decrease exterior volume by decreasing
exterior size.
| |
| Einstein 2007-12-06, 6:56 pm |
| I still think that there are ways to compress data further than we
have as of yet.
I base this upon knowledge that it is possible, albeit at the moment
not very effectively, to create strings that can be separated out to
generate whole strings of 1's and 0's. Counting then can be done to
eliminate a lot of overhead. Additionally if we look at two bit, and 1
bit, we have 6 outcomes. If there is an effective way to differentiate
the two, we can then see higher yeild compression results.
| |
| Providence 2007-12-06, 6:56 pm |
| > I'll give you a hint.
>
> Think of a circle for a moment. You are at the center of the circle.
> In 2-Directional space there are 2 directions on can go in. You can go
> in any direction from the center of the circle to any location on the outer
> point of the circle BUT the other direction you can travel in 2D space is by
> way of SPIN. In this mental example, the circle is a symbol for the
> infinite spatial plane of movement.
>
> In 3-Directional space (not up-down, back-forward, or left-right as
> those examples are poor mental fuel) you are now in the center of a sphere.
> As with 2-Directional space you can spin in one direction or move in any
> direction to the exterior of the sphere. You also get another direction of
> spin available (a non-obvious one) in 3D space.
>
> Also note that for any level of functionality, a 2-Directional spacial
> zone has to allow the temporal direction (4D space) and the potentiality
> direction (5D space). Also note that with each increase of spacial zones,
> you also encounter alternate directions of spin. Temporal movement is just
> another direction of atomic spin that is not easily altered in standard 3D
> space.
>
> It is very feasible that the quantum noise of "zero point energy" is
> merely energy or matter moving in an anti-time-forward spin in time and
> destructing against forward-time-spin matter. Also note that are more than
> merely 5-directions of movement happening at all time, but most of it occurs
> at the subatomic level.
>
> This should be obvious why in a simple thought experiment. Take a cube
> in 3D space. It has 6 sides. If it were a heat source in space it would
> radiate thermal energy at a predictable level. Now shift your thoughts to a
> hypercube in 4D space. How many sides? 24. Yep, more surface energy
> equals a higher rate of radiant energy being lost. What is the most logical
> way to minimize energy loss? Decrease exterior volume by decreasing
> exterior size.
neat analogy.. but your hint loses cohesion as soon as you moved to
3d.. your mention of a non-obvious spin is the loss junction, and is
being shuttled towards the mention of radiant energy.. i would say to
this.. to have anything capable of observing just a subset of
information, such as our eyes to the limits of the sun, there must be
some information encoded into the entirety to produce this limitation,
whether chemical, energetic, physical.
this encoding information must be coming from somewhere that has some
sort of cohesion outside the 'everything is happening' domain, as the
collapsing wave functions actually are encoding, at a coherent level,
a single result.
thus, generators, being transformed through the geometry of the cube
etc. interacting with perhaps only itself, and perhaps octahedral/
icosahedral/dodecahedral/tetrahedral/+ pure shape. this, and the
frequency level of the interaction elements being relayed through
spacial domains that are held in place by the geometries.
given that the concept of 4d is resolving into probability domains of
events occuring or not, this is not encoding at all. hence, anything
higher than this will also not be discrete information, and shall be
appearing as sliding frames of influence which are the natural laws,
the forms, and the generators.
i'm figuring to relate it back to compression we'd isolate each of the
sliding frames of influence and map these backwards to the geometry of
their movements, in 3d or even 2d.
given the exact geometry that is relating to the quantization, sing
through this with just a straight indexing and looking at the result.
or, it may not be feasible to do this, as this might relate to looking
at the digits of phi for example, and sing through the generation
of phi in decimals for a base 10 representation of the data you want
to relate to.
chris.
| |
| Bryan Olson 2007-12-07, 7:56 am |
| Einstein wrote:
> I still think that there are ways to compress data further than we
> have as of yet.
I know of no one who thinks otherwise. Don't let that fool you
into thinking that old results are not worth more study. We all
like to fancy ourselves exceptional, bold new thinkers. 'Tis
easy to judge established results to be the work of that
establishment, arrogantly certifying itself. 'Tis wrong.
Matt Mahoney's post(s) could have pushed you to a clue, but you
followed trying to lecture about science. Providence followed
with gibberish, then George Johnson followed Providence's
gibberish with more gibberish.
--
--Bryan
| |
| Bryan Olson 2007-12-07, 7:56 am |
| NickNitro wrote:
> Matt Mahoney wrote:
[color=darkred]
> Good point, that's why I stated:
> This doesn't mean I'm responsible for your codec not meeting your
> expectations, but if your design it, I'll code it...
> If he 'designed' a perfect compressor - I'll program his design, but
> I'm not responsible for it not working as he expected... Saying that
> if he designed the algorithms in full, then it would never even get to
> the programming stage. ;)
Thou shalt not curse the deaf, nor place a stumbling block before
the blind.
Of course he's not deaf nor blind, other than by his own choice; and
if he's headed toward a stumbling block, he took that direction before
you responded. Still, blessed be he who puts forth clues to the
clueless. That one is not from any major sacred text, but I'm hoping.
--
--Bryan
| |
| Willem 2007-12-07, 7:56 am |
| Einstein wrote:
) Additionally if we look at two bit, and 1 bit, we have 6 outcomes. If
) there is an effective way to differentiate the two, we can then see
) higher yeild compression results.
There isn't an effective way to differentiate the two.
SaSW, Willem
--
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 or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
| |
| NickNitro 2007-12-07, 9:56 pm |
| > Still, blessed be he who puts forth clues to the clueless. That one is not from any major sacred text, but I'm hoping.
Perhaps you should read the conversation and my comments in full
before jumping to conclusions. ;)
> That one is not from any major sacred text, but I'm hoping.
Meh, hope you don't speak like that IRL! :)
| |
| Providence 2007-12-07, 9:56 pm |
|
On Dec 7, 3:34 am, Bryan Olson <fakeaddr...@nowhere.org> wrote:
> Einstein wrote:
>
> I know of no one who thinks otherwise. Don't let that fool you
> into thinking that old results are not worth more study. We all
> like to fancy ourselves exceptional, bold new thinkers. 'Tis
> easy to judge established results to be the work of that
> establishment, arrogantly certifying itself. 'Tis wrong.
>
> Matt Mahoney's post(s) could have pushed you to a clue, but you
> followed trying to lecture about science. Providence followed
> with gibberish, then George Johnson followed Providence's
> gibberish with more gibberish.
>
> --
> --Bryan
meh, that 'gibberish' you mention is simply the edge of another
thread.. we're talking about s-based compression, which ends up
being exactly the 'can you compress in PI' thread, which has to do
with digital generation of sequences.
it's not doable. even expanding the initial geometries into higher
dimension by means of symmetry sets still only has the initial
permutations as a seed.. so the higher dimension add information, but
only information accessible from that dimension.. which means that the
indexing needs to be as dense as that dimension thus not a compressor
whatsoever.
it's like saying 'look at the digits of PI in 3d' and trying to s
through different angles to increase the permutations of the data.
great, it works, but now you need to store the reference angles as
well, which equalizes any gains made in the increased permutations.
i think the future of compression is maximizing the atomic information
densities, and using those molecular structures as perfectly tuned
bases.. something that by its very nature can avoid the 'add n bits to
specify how many bits there are coming up to read as a single
element'.
just in information space, i think that there's little if no wiggle
room to increase the algorithms' efficiency, from the point of view
that there's only a number of way of adding information in a single
dimension, and all of those ways need identifiers that relate the
various transformations that need to be applied.
i mean.. the sheer fact that a single bit saved decreases the
potential size by a half, and two bits saved decreases the potential
size by three quarters, should be enough to show that for any
reasonable, 32 bit gains in a lossless system, you're looking at a 1 :
4294967296 chance of any particular match.
if there were a way to get the success probabilities to be not
decreasing exponentially for a linear bit, great. but in information
space, it doesn't look, to me, as anything workable.
chris
| |
| geert.schrooten@gmail.com 2007-12-08, 3:56 am |
| Michael,
I've looked into separation effect, I really like the id=E9e that
sequences can be placed in an #file, or random if you keep track of
each sequence size. Also the possibility for counting the sizes of
each sequence by using the other #files.
On your demonstration (24bit), I presume there is one 0 separator to
much in plausible outcome list.
I've got 120 outcomes on #file2, and 74 outcomes who can finish the
decoder.
For now I've only programmed separation effect for 3 bit sequences,
try to updated this soon for a flexible length and on a bigger data.
Hope your model keeps a good outcome, so the identify number can be
fixed with yield.
| |
| Phil Carmody 2007-12-08, 7:56 am |
| Providence <psionic81@gmail.com> writes:
> On Dec 7, 3:34 am, Bryan Olson <fakeaddr...@nowhere.org> wrote:
>
> meh, that 'gibberish' you mention is simply the edge of another
> thread.. we're talking about s-based compression, which ends up
> being exactly the 'can you compress in PI' thread, which has to do
> with digital generation of sequences.
>
> it's not doable. even expanding the initial geometries into higher
> dimension by means of symmetry sets still only has the initial
> permutations as a seed.. so the higher dimension add information, but
> only information accessible from that dimension.. which means that the
> indexing needs to be as dense as that dimension thus not a compressor
> whatsoever.
>
> it's like saying 'look at the digits of PI in 3d' and trying to s
> through different angles to increase the permutations of the data.
> great, it works, but now you need to store the reference angles as
> well, which equalizes any gains made in the increased permutations.
>
>
> i think the future of compression is maximizing the atomic information
> densities, and using those molecular structures as perfectly tuned
> bases.. something that by its very nature can avoid the 'add n bits to
> specify how many bits there are coming up to read as a single
> element'.
Yes, yes, your gibberish generation script works perfectly,
you don't need to test it any more.
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
| |
| Providence 2007-12-08, 10:00 pm |
| On Dec 8, 5:43 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Providence <psioni...@gmail.com> writes:
>
>
>
>
>
>
>
> Yes, yes, your gibberish generation script works perfectly,
> you don't need to test it any more.
>
> Phil
> --
> Dear aunt, let's set so double the killer delete select all.
> -- Microsoft voice recognition live demonstration
phil:
perhaps you're a savant phil.. but i haven't seen you do anything
actually productive on these forums yet other than get irritated at
random points. i think you mostly just don't understand language, but
that's  , since it's not like you're having any effect anyways.
i feel you troll around, ineffectively. like aliasing in an actual
conversation.
perhaps you don't see that space itself is information, that specific
geometries add new relationships in higher dimensions. perhaps you do
but are playing dumb. in either case, you're not demonstrating any
sort of skill sets yourself, so you come across as dull rather than
exploratory.
einstein:
the huffman works fine since it is stable. the remapping works only if
the remappings can actually reorient the 1's and 0's into easier to
encode patterns.
consider a chess board.
0101010101
0101010101
0101010101
0101010101
consider a horizon.
0000000000
0000000000
1111111111
1111111111
your remapping is the entropy moving the data from one state to
another.
if you remapped any arbitrary sequence with a single remapping state,
all you'd be doing is moving the information from one position to
another.
however, by having the equivalent of a data-space "maxwell's demon",
you can produce an AI that determines which remapping to perform at
any specific input state.
that is, you're range-limiting this:
0101010101
0101010101
0101010101
0101010101
0101010101
0101010101
into this:
=====
0000000000
0000000000
0000000000
0000000000
=====
1111111111
1111111111
1111111111
1111111111
where ===== is the AI's perception.
so you're still moving the information around, it's just that you're
using a larger data realm (a higher dimension, 3d back to 2d back to
1d to increase the spacial availability of ranging the data). and then
using an AI in that larger realm to contract the field into a
position, on a case by case basis, that will increase the amount of
0's in any set.
from my understanding of the bridge between 'physical' entropy and
'information' entropy, it is the exact same, except in the 'physical'
space we're told we're not able to produce the atomic tools necessary
to shuttle hot and cold between each section of the box since the
thing in the center would need to keep track and we're also told that
there is nothing that small that can hold the information.
that being said.
you can, and have, done this in information space. this is all that is
needed to produce an AI that can perform this maneuver. thus, you have
control over the direction of entropy, in as large of a plane as you
need to actualize the 0's, with the 'perfect' result being the only
one encoded to the command section, thus the rest of the possible
permutations for that section of data are not only irrelevant but also
not necessary.
so, i'd suggest moving back to the roots of the algorithm, without the
fancy footwork of the spectralized file systems, and get a better
grasp of the mechanics of the command section in regards to the
remapping.
this should reignite your ability to conceive of the properties you
want to imbue into the system.
chris.
| |
| Einstein 2007-12-10, 6:56 pm |
| On Dec 8, 10:00 am, Providence <psioni...@gmail.com> wrote:
>*kept short*
My thanks. Been busy last few, then sleeping problems resulting from
WAY TO LONG OF HOURS :S
It's hard to bum rush 6 websites with no notice, get calls when trying
to sleep, and to focus... but now I am getting better.
> geert.schroo...@gmail.com
Hey thanks for the help. Since I am merely an html programmer, and
minor javascript modifier, I am far from being able to generate
programs which can do the serious math for me.
feel free to email me if you get some interesting results... I would
be happy to run them versus any of the 30 different compression
methods I found/rediscovered (of other peoples works, hehe)
I also want to show an interesting method I originally devised with
this
There is a way to track all the separate files
But the problem is that any compression affects all at the same time
Simply put
File one starts at the left and goes in proper sequential order. File
#2 starts at the right and goes left, in reverse order, file 3 goes to
the right of file #1 in proper order, thereafter each even number goes
to the left of the previous even number, in reverse order, and any odd
number goes to the right of the previous odd number, in proper order.
When last file is done they meet... In this manner it is possible to
easily track all bits.
It seemed to me that using the method it might be possible to get what
I called "Binary drift" to occur. This is a state where 1's would
gravitate to certain regions, and 0's to other regions and it would be
detectable with a proper algorithm. This would be after multiple runs
of the system at different substring lengths.
However it was beyond my means to actually track it, and I ultimately
gave up on it.
| |
| geert.schrooten@gmail.com 2007-12-16, 9:56 pm |
| Chris
>from my understanding of the bridge between 'physical' entropy and
>'information' entropy, it is the exact same, except in the 'physical'
>space we're told we're not able to produce the atomic tools necessary
>to shuttle hot and cold between each section of the box since the
>thing in the center would need to keep track and we're also told that
>there is nothing that small that can hold the information.
I agree there must be compensation in order to bridge 2 ways. In
Michaels model he uses CPU time to retrieve possible outcomes in order
to keep the index smaller than the original (fixed position). Can't
time be a information carrier?
Michael
I can't follow how you can retrieve even & uneven numbers. For what I
can make out of it you will merge bits in order to retrieve them you
need a additional bits, or a big index number on possible outcomes
(lot of cpu time).
But I probably interpret some of you description wrong, I need a
example to follow you id=E9e.
| |
| Providence 2007-12-21, 3:56 am |
| > I agree there must be compensation in order to bridge 2 ways. In
> Michaels model he uses CPU time to retrieve possible outcomes in order
> to keep the index smaller than the original (fixed position). Can't
> time be a information carrier?
that was my first instinct, but it turns out that time is already
being utilized as an information carrier in the way that the digital
streams are represented..
100011 has time involved, as the computation of the stream reads the
digit itself, 0 or 1, as space, and then there is the next digit.
chris.
| |
|
|
|
|
|
|
|