I have updated this section to prevent any further confusion: " Data bits: a,a,a,a,a,a,b,b,b,b,b,c,c,c,c (these bits can have value 0 or 1) " (Since some people though these aaaa, bbb, ccc bits behaved like unary encoding (all ones or all zeros) This is not the case. These bits can have any binary value, a zero or a one. I have also included a new part for further clearity: New part: " The position of the bit in the information stream identifies if it is a marker bit or a data bit. Positions: 0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9 Information stream: a,0,a,0,a,0,a,0,a,0,a,1,b,0,b,0,b,0,b,0,b,1,c,0,c,0,c,0,c,1 The data bits are located on "even" positions. (0,2,4,6,8,10,12,14,16,18,20, etc ) The marker bits are located on "oneven" positions. ( 1,3,5,7,9,11,13,15,17,19, etc ) By reading a data bit, marker bit, data bit, marker bit, etc they can be seperated from each other. " Bye, Skybuck.
Re: Skybuck's universal code
Started by ●August 5, 2005
Reply by ●August 5, 20052005-08-05
Skybuck Flying wrote:> I have updated this section to prevent any further confusion: > > " > Data bits: > a,a,a,a,a,a,b,b,b,b,b,c,c,c,c (these bits can have value 0 or 1) > " > > (Since some people though these aaaa, bbb, ccc bits behaved like unary > encoding (all ones or all zeros) This is not the case. > > These bits can have any binary value, a zero or a one. > > I have also included a new part for further clearity: > > New part: > > " > The position of the bit in the information stream identifies if it is a > marker bit or a data bit. > > Positions: > 0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2 > 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9 > > Information stream: > a,0,a,0,a,0,a,0,a,0,a,1,b,0,b,0,b,0,b,0,b,1,c,0,c,0,c,0,c,1 > > The data bits are located on "even" positions. (0,2,4,6,8,10,12,14,16,18,20, > etc ) > The marker bits are located on "oneven" positions. ( > 1,3,5,7,9,11,13,15,17,19, etc ) > > By reading a data bit, marker bit, data bit, marker bit, etc they can be > seperated from each other. > " > > Bye, > Skybuck.Ok, so for every bit of valid data, two bits are sent. At 50% compression, you get back to the original size. To gain much, you need to do a lot better than that. Isn't that rather more of a penalty than needed? Can you ever come out ahead of competing methods? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●August 5, 20052005-08-05
Hello Skybuck, As Jerry has mentioned, your scheme is horribily inefficient. You may want to look up "line codes" as used in telephony. They have a strong commercial interest in getting as many bits as possible through a fixed channel. Even if you wish to send data streams with different rates and lengths, some kind of header will generaly serve better (have lower overhead) than interleaving all of these marker bits. Clay p.s. As a side note it is customary for someone other than the inventor to assign a name to a process. Fourier did not name his transform, it was only after others decided than the transform had merit, that they started to refer to it by his name.
Reply by ●August 5, 20052005-08-05
You may want to read up on universal code's They are now about compression, they are about flexibility and self-delimiting. Bye, Skybuck. "Clay S. Turner" <Physics@Bellsouth.net> wrote in message news:XZNIe.13507$jq.5734@bignews3.bellsouth.net...> Hello Skybuck, > > As Jerry has mentioned, your scheme is horribily inefficient. You may want > to look up "line codes" as used in telephony. They have a strongcommercial> interest in getting as many bits as possible through a fixed channel. Even > if you wish to send data streams with different rates and lengths, somekind> of header will generaly serve better (have lower overhead) thaninterleaving> all of these marker bits. > > Clay > > p.s. As a side note it is customary for someone other than the inventor to > assign a name to a process. Fourier did not name his transform, it wasonly> after others decided than the transform had merit, that they started to > refer to it by his name.
Reply by ●August 5, 20052005-08-05
Read up on universal code's, they are not about compression, but about flexibility and self-delimiting fields. Bye, Skybuck. "Jerry Avins" <jya@ieee.org> wrote in message news:qvGdnWChPb5vNW7fRVn-sQ@rcn.net...> Skybuck Flying wrote: > > I have updated this section to prevent any further confusion: > > > > " > > Data bits: > > a,a,a,a,a,a,b,b,b,b,b,c,c,c,c (these bits can have value 0 or 1) > > " > > > > (Since some people though these aaaa, bbb, ccc bits behaved like unary > > encoding (all ones or all zeros) This is not the case. > > > > These bits can have any binary value, a zero or a one. > > > > I have also included a new part for further clearity: > > > > New part: > > > > " > > The position of the bit in the information stream identifies if it is a > > marker bit or a data bit. > > > > Positions: > > 0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2 > > 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9 > > > > Information stream: > > a,0,a,0,a,0,a,0,a,0,a,1,b,0,b,0,b,0,b,0,b,1,c,0,c,0,c,0,c,1 > > > > The data bits are located on "even" positions.(0,2,4,6,8,10,12,14,16,18,20,> > etc ) > > The marker bits are located on "oneven" positions. ( > > 1,3,5,7,9,11,13,15,17,19, etc ) > > > > By reading a data bit, marker bit, data bit, marker bit, etc they can be > > seperated from each other. > > " > > > > Bye, > > Skybuck. > > Ok, so for every bit of valid data, two bits are sent. At 50% > compression, you get back to the original size. To gain much, you need > to do a lot better than that. Isn't that rather more of a penalty than > needed? Can you ever come out ahead of competing methods? > > Jerry > -- > Engineering is the art of making what you want from things you can get. > �����������������������������������������������������������������������
Reply by ●August 5, 20052005-08-05
Skybuck Flying wrote:> Read up on universal code's, they are not about compression, but about > flexibility and self-delimiting fields.They're not about wasting bandwidth, though. A length header goes a long way to defining a field's size. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●August 5, 20052005-08-05
"Skybuck Flying" <nospam@hotmail.com> wrote in message news:dd0kak$co5$1@news1.zwoll1.ov.home.nl...> You may want to read up on universal code's > > They are now about compression, they are about flexibility and > self-delimiting. > > Bye, > Skybuck. >Actually I have. In only a few minutes, I found that Rice codes (from 1979) function much more efficiently than yours. 100% overhead is a lot just for nondelimiting and instantaneity. And the Rice codes offer these qualities as well. What new quality does your code offer that none of the earlier ones do? Clay
Reply by ●August 6, 20052005-08-06
"Clay S. Turner" <Physics@Bellsouth.net> wrote in message news:eURIe.25220$Mo.22646@bignews5.bellsouth.net...> > "Skybuck Flying" <nospam@hotmail.com> wrote in message > news:dd0kak$co5$1@news1.zwoll1.ov.home.nl... > > You may want to read up on universal code's > > > > They are now about compression, they are about flexibility and > > self-delimiting. > > > > Bye, > > Skybuck. > > > > Actually I have. In only a few minutes, I found that Rice codes (from1979)> function much more efficiently than yours. 100% overhead is a lot just for > nondelimiting and instantaneity. And the Rice codes offer these qualitiesas> well. What new quality does your code offer that none of the earlier ones > do?How difficult is it to implement Rice ? I do not understand it's algorithm. Maybe you care to share some pseudo code. While rice may save some bits which is beside the point, it will probably be much much slower than Skybuck's universal code. So skybuck's universal code would be a clear winner speed-wise. Bye, Skybuck.
Reply by ●August 6, 20052005-08-06
Skybuck Flying wrote:> ... While rice may save some bits > which is beside the point, it will probably be much much slower than > Skybuck's universal code. So skybuck's universal code would be a clear > winner speed-wise.Usually, the channel for the bits is the slowest part. Anything that saves bits is a clear winner. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●August 7, 20052005-08-07
Clay S. Turner wrote:> As Jerry has mentioned, your scheme is horribily inefficient. You may want > to look up "line codes" as used in telephony. They have a strong commercial > interest in getting as many bits as possible through a fixed channel. Even > if you wish to send data streams with different rates and lengths, some kind > of header will generaly serve better (have lower overhead) than interleaving > all of these marker bits.If the code needs to represent arbitrary length binary numbers, it needs some way to indicate the length. If the probability is inversely proportional to the length of the binary representation, that is, inverse of the log of the value, then such a representation is efficient. Shorter strings are given to higher probability values. As I understand it, though, the more common convention puts (N-1) zeros followed by the binary number with leading zeros removed. That doesn't leave a representation for zero, but then if the weighting is inverse length it can't ever be zero. -- glen
