Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #2315 > unrolled thread

Introduction to Dynamic Unary Encoding

Back to article view | Back to comp.compression

Contents

  Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-05-13 09:24 -0700
    Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-05-16 14:16 -0700
      Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-05-28 16:56 -0700
        Re: Introduction to Dynamic Unary Encoding "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2014-05-31 05:09 +0200
          Re: Introduction to Dynamic Unary Encoding "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2014-05-31 05:27 +0200
            Re: Introduction to Dynamic Unary Encoding "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2014-05-31 05:37 +0200
              Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-03 15:47 -0700
          Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-03 15:18 -0700
            Re: Introduction to Dynamic Unary Encoding "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2014-06-05 06:14 +0200
              Re: Introduction to Dynamic Unary Encoding "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2014-06-05 06:15 +0200
                Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-08 14:20 -0700
                  Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-09 13:03 -0700
        Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-16 14:40 -0700
    Re: Introduction to Dynamic Unary Encoding jacko <jackokring@gmail.com> - 2014-05-29 17:54 -0700
      Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-03 13:52 -0700
    Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-11 00:56 -0700
      Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-11 03:38 -0700
        Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-11 13:23 -0700
        Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-11 13:37 -0700
          Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-11 18:39 -0700
            Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-13 12:10 -0700
              Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-13 16:30 -0700
          Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-11 19:12 -0700
    Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-13 12:07 -0700
      Re: Introduction to Dynamic Unary Encoding matrix29bear@gmail.com - 2014-06-13 16:14 -0700
        Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-06-16 12:38 -0700
    Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-09-04 19:30 -0700
    Re: Introduction to Dynamic Unary Encoding Ernst <ernst_berg@sbcglobal.net> - 2014-12-14 18:58 -0800
    Re: Introduction to Dynamic Unary Encoding ernst@eberg.us - 2017-03-14 12:48 -0700

Page 1 of 2  [1] 2  Next page →

#2315 — Introduction to Dynamic Unary Encoding

Introduction to Dynamic Unary Encoding.

http://arxiv.org/abs/1405.2846

 I would assume this is a welcome discovery to data compression folk.  I am very interested in what people think because I still have so much to learn.

Feel free to write to the email listed on the paper. 


 Ernst

[toc] | [next] | [standalone]

#2323

On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> Introduction to Dynamic Unary Encoding.
> 
> 
> 
> http://arxiv.org/abs/1405.2846
> 
> 
> 
>  I would assume this is a welcome discovery to data compression folk.  I am very interested in what people think because I still have so much to learn.
> 
> 
> 
> Feel free to write to the email listed on the paper. 
> 
> 
> 
> 
> 
>  Ernst

An update fixing typos and adding clarifications will be available 05/17/2014

 It is possible to look so hard one cannot see.

[toc] | [prev] | [next] | [standalone]

#2333

On Friday, May 16, 2014 2:16:50 PM UTC-7, Ernst wrote:
> On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > Introduction to Dynamic Unary Encoding.
> 
> > 
> 
> > 
> 
> > 
> 
> > http://arxiv.org/abs/1405.2846
> 
> > 
> 
> > 
> 
> > 
> 
> >  I would assume this is a welcome discovery to data compression folk.  I am very interested in what people think because I still have so much to learn.
> 
> > 
> 
> > 
> 
> > 
> 
> > Feel free to write to the email listed on the paper. 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> >  Ernst
> 
> 
> 
> An update fixing typos and adding clarifications will be available 05/17/2014
> 
> 
> 
>  It is possible to look so hard one cannot see.

A third draft is now available.

On examination of string lengths one and two it was realized that three categories of cycle spectrum existed. Also there is a website if folks are interested in chatting about Dynamic Unary Encoding eberg.us

Thank you for your time.

[toc] | [prev] | [next] | [standalone]

#2338

It would help if the document would explain the bit positions better:

For example:

Is most significant bit on the left or on the right side ?

Basically this also applies to n-th bit.

Should counting start from left or from right.

Some illustrations/graphics and arrows pointing towards which bit is ment 
for certain descriptions would be helpfull.

The document starts to get fuzy at section 3.

Previous sections remind me of Skybuck's Universal Code but being applied to 
parity bits and instead of interleaving it's transformed.

Ofcourse it's now the same the delimiters of Skybuck's meta bits are not 
present, and this dynamic unary encoding does not seperate the bit fields 
from each other.

Instead it treats the entire input stream as one big binary field, which is 
ok, just pointing out a few differences.

Also the first bit would have to be known even if a fixed terminus is 
used... otherwise two different outputs possible, but the document seems to 
be about many outputs possible but then again not for certain powers of 2 or 
whatever... bit fuzy there too.

I have seen something like this before but in a smaller form... so there 
seems to be some merit to all of this.

Hopefully the document can be improved to clearify certain things.

More worked out examples would also be nice or explain all the steps more 
thoroughly...

It's especially hard to see how it maps it itself or to those bit 
patterns...

The concept of cycles is also a bit fuzzy. I took a glance at the other 
document mentions... but that's also complex/fuzzy and seems mention some 
summing and mod 2.

Not sure if that applies to Ernst document... so maybe cycles needs some 
further explaining too.

And finally would good did come out of this ?

Were you able to achieve some kind of compression ?

Or was the opposite "achieved" just bigger outputs ?

Perhaps a transformation ?

Also transforming from binary to unary parity encoding would probably be 
worse... I'd guess this would double the number of bit switches from 0 to 1 
and 1 to 0

Example:

000111
100100

^ 4 switches instead of just ^^ 2.

Just pointing out that this unary parity encoding itself might not be 
usefull for compression purposes, however the document goes further and 
talks about more transforms being done/applied... just don't understand it 
completely.

And the table at the end is totally confusing... suddenly it's showing 
decimal values ?!?

"number of cycles 2 of 8 elements" ?

What does that mean ? 2 cycles found of a group of 8 ? 8 digits belonging 
together ?

No idea what that all means.

Perhaps use some colors or marking to indicate the cycles...

Does it mean 2 cycles were found and the rest is not cycles ?

Point out more thoroughly were the cycles are located or whatever.

Finally if this did lead to some kind of compression, I'd be interested in 
seeing some code.

Also there was talk of "keep parity reference information outside/exported" 
?

These words are also kinda confusing... would this data need to be stored as 
well for the decoder to work ?

Or would it somehow be derived from output/input data for the decoder.

Document seems to indicate perhaps some kind of deriving... but then 
again... confusing words.

Example of confusing words:

"The Drop-T algorithm exports the parity reference as data then encodes the 
source in a fixed parity
terminus unary code."

Exports ?

Data ?

Encodes the source ?

What is ment with all of this...

It's either input or output.... exports/data/source it's all fuzy.

Bye,

  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2339

Also if you do decide to make a second version with more illustrations it 
would probably help if

Parity Reference was illustrated as well with an array contain the data in 
the boxes.

Like
(draw boxes around each number and you'll get the idea for the 
illustration):


0 1 2 3 4 5 6 7 8 9  (bit position)
0 0 1 0 1 1 0 1 0 1  (parity reference)

This visualizes some of the data, so the reader has some clue to what is 
going on and doesn't have to process everything inside his head.

And may make it a little bit easier to follow the steps of the 
algorithm/idea.

Omitting this illustration would take too many steps for the reader to 
derive it every time or memorize it woulde be difficult at best.

(Also I am not a big fan of abbrevations... there are too many of them in 
this world already, instead of calling it PRef, just call it parity 
reference in full.
Those few letters of savings don't really add anything to the document and 
requires further decompression inside the reader's brain.)

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2340

The flow charts are appreciated, however I am not sure they contain enough 
information to actually make some code.

Perhaps it's missing some indexes. Though I could try and guess them.

For example

"input parity reference position"

What is to be inputted ? The position ? The value at the position of the 
parity reference array ?

I would have assumed the later... but maybe it's the first not sure... this 
casts doubts and room for miss-interpretation.

Either clearify the flow charts somehow.... perhaps by defining more 
variables like indexes, contents, values, constants and so forth.

Or perhaps add some pseudo code, preferably in pascal... how each box of the 
flow chart is turned into pseudo or pascal code ;)

C code my be fine too, though it will stand less the test of time.

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2347

On Friday, May 30, 2014 8:37:30 PM UTC-7, Skybuck Flying wrote:
> The flow charts are appreciated, however I am not sure they contain enough 
> 
> information to actually make some code.
> 
> 
> 
> Perhaps it's missing some indexes. Though I could try and guess them.
> 
> 
> 
> For example
> 
> 
> 
> "input parity reference position"
> 
> 
> 
> What is to be inputted ? The position ? The value at the position of the 
> 
> parity reference array ?
> 
> 
> 
> I would have assumed the later... but maybe it's the first not sure... this 
> 
> casts doubts and room for miss-interpretation.
> 
> 
> 
> Either clearify the flow charts somehow.... perhaps by defining more 
> 
> variables like indexes, contents, values, constants and so forth.
> 
> 
> 
> Or perhaps add some pseudo code, preferably in pascal... how each box of the 
> 
> flow chart is turned into pseudo or pascal code ;)
> 
> 
> 
> C code my be fine too, though it will stand less the test of time.
> 
> 
> 
> Bye,
> 
>   Skybuck.

-------------------------------------------------------

Skybuck Flying 	
May 30
Also if you do decide to make a second version with more illustrations it would probably help if  Parity Reference was illustrated as well with an array contain the data in the boxes. Like (draw boxes around each number and you'll get the idea for the illustration):  
0 1 2 3 4 5 6 7 8 9  (bit position)
0 0 1 0 1 1 0 1 0 1  (parity reference)
This visualizes some of the data, so the reader has some clue to what is going on and doesn't have to process everything inside his head. And may make it a little bit easier to follow the steps of the algorithm/idea.
Omitting this illustration would take too many steps for the reader to derive it every time or memorize it woulde be difficult at best.
(Also I am not a big fan of abbrevations... there are too many of them in this world already, instead of calling it PRef, just call it parity reference in full.
Those few letters of savings don't really add anything to the document and requires further decompression inside the reader's brain.)
Bye,
  Skybuck.

	Skybuck Flying 	
May 30
The flow charts are appreciated, however I am not sure they contain enough information to actually make some code. Perhaps it's missing some indexes. Though I could try and guess them.  For example  "input parity reference position" What is to be inputted ? The position ? The value at the position of the parity reference array ?
I would have assumed the later... but maybe it's the first not sure... this casts doubts and room for miss-interpretation. Either clearify the flow charts somehow.... perhaps by defining more variables like indexes, contents, values, constants and so forth.
Or perhaps add some pseudo code, preferably in pascal... how each box of the flow chart is turned into pseudo or pascal code ;) C code my be fine too, though it will stand less the test of time.  
Bye,
  Skybuck.

--------------------------------------------

 Well sure there is a posibility I can write a much nicer publication but have you looked at the other papers? They generally cram it all in whith no concern for format. It is after all a "preprint-Server" there at Cornell. If someone wants me to write something nicer they can let me know what they want and I can aim for that result.
 I will accept that the Flow Charts are sparse. Again aimed at those who can read between the lines. I agree there isn't enough to do a direct transfer but the general construct is presented. Again.. If someone wants to publish something from me on this subject we can discuss what level of detail I need to go to. 
 I do appreciate the feedback and I am keeping copies here so I can look at the suggestions again.  I may change up once more so it is possible to make a better effort. The flow charts are a possibility. 
 The most important things are that the mathematics are correct, tha the data is correct, that the algorithms are presented correctly, that the work is original and that it is useful.  I hope that I got the easy job of "The Introduction."  
With the Drop-T and the Binary Construct I was being distant because it's just not that important to detail all of the constructs I worked out when one exampe can be made to introduce the general topic.  
 You make me wonder if a proper book would sell.  Now that's an idea..  Earning money for a change. 
Okay then I really loved replying. This represents fourteen years of my computer programming life and it all fits into eleven pages.

[toc] | [prev] | [next] | [standalone]

#2346

On Friday, May 30, 2014 8:09:33 PM UTC-7, Skybuck Flying wrote:
> It would help if the document would explain the bit positions better:
> 
> 
> 
> For example:
> 
> 
> 
> Is most significant bit on the left or on the right side ?
> 
> 
> 
> Basically this also applies to n-th bit.
> 
> 
> 
> Should counting start from left or from right.
> 
> 
> 
> Some illustrations/graphics and arrows pointing towards which bit is ment 
> 
> for certain descriptions would be helpfull.
> 
> 
> 
> The document starts to get fuzy at section 3.
> 
> 
> 
> Previous sections remind me of Skybuck's Universal Code but being applied to 
> 
> parity bits and instead of interleaving it's transformed.
> 
> 
> 
> Ofcourse it's now the same the delimiters of Skybuck's meta bits are not 
> 
> present, and this dynamic unary encoding does not seperate the bit fields 
> 
> from each other.
> 
> 
> 
> Instead it treats the entire input stream as one big binary field, which is 
> 
> ok, just pointing out a few differences.
> 
> 
> 
> Also the first bit would have to be known even if a fixed terminus is 
> 
> used... otherwise two different outputs possible, but the document seems to 
> 
> be about many outputs possible but then again not for certain powers of 2 or 
> 
> whatever... bit fuzy there too.
> 
> 
> 
> I have seen something like this before but in a smaller form... so there 
> 
> seems to be some merit to all of this.
> 
> 
> 
> Hopefully the document can be improved to clearify certain things.
> 
> 
> 
> More worked out examples would also be nice or explain all the steps more 
> 
> thoroughly...
> 
> 
> 
> It's especially hard to see how it maps it itself or to those bit 
> 
> patterns...
> 
> 
> 
> The concept of cycles is also a bit fuzzy. I took a glance at the other 
> 
> document mentions... but that's also complex/fuzzy and seems mention some 
> 
> summing and mod 2.
> 
> 
> 
> Not sure if that applies to Ernst document... so maybe cycles needs some 
> 
> further explaining too.
> 
> 
> 
> And finally would good did come out of this ?
> 
> 
> 
> Were you able to achieve some kind of compression ?
> 
> 
> 
> Or was the opposite "achieved" just bigger outputs ?
> 
> 
> 
> Perhaps a transformation ?
> 
> 
> 
> Also transforming from binary to unary parity encoding would probably be 
> 
> worse... I'd guess this would double the number of bit switches from 0 to 1 
> 
> and 1 to 0
> 
> 
> 
> Example:
> 
> 
> 
> 000111
> 
> 100100
> 
> 
> 
> ^ 4 switches instead of just ^^ 2.
> 
> 
> 
> Just pointing out that this unary parity encoding itself might not be 
> 
> usefull for compression purposes, however the document goes further and 
> 
> talks about more transforms being done/applied... just don't understand it 
> 
> completely.
> 
> 
> 
> And the table at the end is totally confusing... suddenly it's showing 
> 
> decimal values ?!?
> 
> 
> 
> "number of cycles 2 of 8 elements" ?
> 
> 
> 
> What does that mean ? 2 cycles found of a group of 8 ? 8 digits belonging 
> 
> together ?
> 
> 
> 
> No idea what that all means.
> 
> 
> 
> Perhaps use some colors or marking to indicate the cycles...
> 
> 
> 
> Does it mean 2 cycles were found and the rest is not cycles ?
> 
> 
> 
> Point out more thoroughly were the cycles are located or whatever.
> 
> 
> 
> Finally if this did lead to some kind of compression, I'd be interested in 
> 
> seeing some code.
> 
> 
> 
> Also there was talk of "keep parity reference information outside/exported" 
> 
> ?
> 
> 
> 
> These words are also kinda confusing... would this data need to be stored as 
> 
> well for the decoder to work ?
> 
> 
> 
> Or would it somehow be derived from output/input data for the decoder.
> 
> 
> 
> Document seems to indicate perhaps some kind of deriving... but then 
> 
> again... confusing words.
> 
> 
> 
> Example of confusing words:
> 
> 
> 
> "The Drop-T algorithm exports the parity reference as data then encodes the 
> 
> source in a fixed parity
> 
> terminus unary code."
> 
> 
> 
> Exports ?
> 
> 
> 
> Data ?
> 
> 
> 
> Encodes the source ?
> 
> 
> 
> What is ment with all of this...
> 
> 
> 
> It's either input or output.... exports/data/source it's all fuzy.
> 
> 
> 
> Bye,
> 
> 
> 
>   Skybuck.

Well Skybuck Flying!  I appreciate the conversation. I see that you are interested so I will do my best to stick to the original me who published DUE.
 Some editing of your original post is going to happen so forgive me if I trespass on your original intent. Mostly this will be in the form of format as I am using a Word Processor.
May 30
It would help if the document would explain the bit positions better:
Ernst: Yeah what are bit positions... In writing a scientific paper one must assume the reader has an understanding of the constructs. It is suggested to speak to that more than restating already established works. In the case of Binary Numbers there is a reference to Wikipedia. Not to be rude or curt here but it is the suggested way to write a Scientific Paper. The references are there so anyone interested in reading more can look into those things.
SBF: For example:
ISBF: s most significant bit on the left or on the right side ?
The foot note explains that this is western positional notation so that is right to left. We must deal with the left & right issue i know. It's a brain thing.  I have output in some functions I wrote which are left to right. So I must be careful however I adopted , for myself labels of  1:xxxxxxxxxx:0 so that I can intermix data in text documents. I simply do not want to be guessing what I meant.
SBF : Basically this also applies to n-th bit. Should counting start from left or from right. Some illustrations/graphics and arrows pointing towards which bit is meant for certain descriptions would be helpful.
Ernst: n-bit is a tern defining a finite string. 
SBF: The document starts to get fuzzy at section 3. Previous sections remind me of Skybuck's Universal Code but being applied to parity bits and instead of interleaving it's transformed. of course it's now the same the delimiters of Skybuck's meta bits are not present, and this dynamic unary encoding does not separate the bit fields from each other. Instead it treats the entire input stream as one big binary field, which is ok, just pointing out a few differences.
Ernst : These cycles appear, to me,  to be a natural construct like any number is except this is a dynamic number in my opinion.  Also I will admit I am very interested in how DUE might apply to the I Ching. I also admit it's the first excuse I have to delve into artificial intelligence topics. A.I. is  over my head naturally but one learns to swim by getting in the water.

SBF: Also the first bit would have to be known even if a fixed terminus is used... otherwise two different outputs possible, but the document seems to be about many outputs possible but then again not for certain powers of 2 or whatever... bit fuzzy there too.
Ernst: Well, it may come to pass that while I was sincere in my efforts I may have missed a bigger picture. The goal became to present these things without being too "it's this and nothing else." I'm open to reading what everyone has to say. It does appear that this is new to us. I am not so big I can't retract and rewrite giving credit where credit is due.  As to fixed terminus and parity reference. I trust you found the line "imagination was Key" helpful. Have fun. "There may be Gold in them there hills." I never got past the Pigeonhole principle but you might.
SBF: I have seen something like this before but in a smaller form... so there seems to be some merit to all of this. Hopefully the document can be improved to clarify certain things. More worked out examples would also be nice or explain all the steps more thoroughly...
Ernst: again it is aimed at those smarter than I. It is very possible that I can write a book which does just that. It would also add my thoughts and observations.  This didn't happen in a vacuum over the Summer you know. 
SBF: It's especially hard to see how it maps it itself or to those bit patterns...
Ernst;  if you mean 000 mapsto 0000 with a fixed terminus of 1 {0000} encoded to 1000 because it is 4 bits of the same parity. The PRef is b0 for simplicity. So out goes the first bit 0 for the parity at b0. Then the Terminus is dropped and it's coded again so 000 maps to 100 since it is three bits of the same parity. Dropping the T we now have 00 and 00 mapsto 10 .. So you see each time the Parity outputed (McKay Speek) is 0 in each iteration. So {0000} maps to {0000} In this case a complete cycle is not possible so it does default to a permutation aspect in my opinion. I was trying to remember if I did construct some form of this that did a full cycle. This one is actually the first encoder so it's the oldest memory.  Heh.. I'll have to rummage through all the Source Code and see if I did do such a thing. I seem to remember I did cycle for 8 bits but that is fuzzy right now.


SBF: The concept of cycles is also a bit fuzzy. I took a glance at the other document mentions... but that's also complex/fuzzy and seems mention some summing and mod 2.
Ernst: Yes Gus is a great guy. I have spoken with him a couple of times. Although Gus is officially out of the game I still send my warmest invitation to Gus and credit him with the discovery of the cycle structure. I found DUE then found Gus's paper. Sadly Gus's paper costs $40.00 to get a copy but it is very worth it to see a master cryptographer work his magic.
SBF: Not sure if that applies to Ernst document... so maybe cycles needs some further explaining too.
Ernst: I am not at the Abstract Algebra level yet. So I tried my best to tippy toe through those tulips. There was a debate (in Internet speak) of Sets vrs cycle notation. Is it a permutation or a cycle? I could still get bruised up on that one.  But as Forest Gump would say "I think It's a little of both."
SBF; And finally would good did come out of this ? Were you able to achieve some kind of compression ? Or was the opposite "achieved" just bigger outputs ?
Ernst: What good will come indeed. Perhaps we should ask "where does this apply in our Universe." Do we know any mathematical object to be useless? As you are fond of Brain Waves in the 40hz range the same as I, I ponder the relationship of DUE to the spin of electrons or other Physics stuff.  Mind you I am not at that level of mathematics. 
SBF: Perhaps a transformation ? Also transforming from binary to unary parity encoding would probably be worse... I'd guess this would double the number of bit switches from 0 to 1 and 1 to 0
SBF: Example: 000111 100100 ^ 4 switches instead of just ^^ 2. Just pointing out that this unary parity encoding itself might not be useful for compression purposes, however the document goes further and talks about more transforms being done/applied... just don't understand it completely.
Ernst: It is what it is. I did not construct the cycles. It is not a mathematical formula. I suppose I can make a joke here so I will try. "If you are unhappy with it please direct your complaints to the complaint department in Heaven."
SBF: And the table at the end is totally confusing... suddenly it's showing decimal values ?!?
Ernst: I borrowed from Gus on this. For most of us we are at ease to comprehend decimal and binary simply looks difficult and confusing. It was a bit of a pain to limit it to only eight bits but two pages is enough data to support the claims made. Naturally it is a bit of a chore to convert decimal to binary by hand. My tools have switches to display in binary when I wish it.  If you would like a data file in binary I can do that for you easy.
SBF: "number of cycles 2 of 8 elements" ? What does that mean ? 2 cycles found of a group of 8 ? 8 digits belonging together ? No idea what that all means.
Ernst: Yeah, like I said some of it is aimed towards what I think is a level of someone in the field.  It's there you just need to read it again. 
SBF: Perhaps use some colors or marking to indicate the cycles... Does it mean 2 cycles were found and the rest is not cycles ? 
Ernst: again have a look. I feel I did a good job in the reduction of things to only six pages. I promise you that I spent day and night living with that paper.  I worked and worked to have every nook and cranny covered. So far after the third draft I have not seen any problems. But then agin if I have something really wrong I wouldn't see it now would I.
SBF; Point out more thoroughly were the cycles are located or whatever.
Ernst: The best way to get a hands on experience is to go hands on.  I see only one mistake in the flow charts and that for Encode I say set the bit count to zero to start when if you look if it exited after one bit the program would have a zero length count.  I am considering changing that and also editing the abstract to read 2^n because the TeX version of that comes out as 2n when converted to regular text.
SBF: Finally if this did lead to some kind of compression, I'd be interested in seeing some code.
 Ernst; Well SBF, now that the cat is out of the bag these things are possible. Are you interested in sharing some workload? I have an 8 core but I wish to run two new designs I am working on.  Trust me there is nothing to the functions I have written that I have not shared in the flow charts. Except that they are mine and I am a bit selfish with my toys.

SBF: Also there was talk of "keep parity reference information outside/exported"? These words are also kinda confusing... would this data need to be stored as well for the decoder to work ? Or would it somehow be derived from output/input data for the decoder. Document seems to indicate perhaps some kind of deriving... but then again... confusing words.

Example of confusing words:

SBF: "The Drop-T algorithm exports the parity reference as data then encodes the source in a fixed parity terminus unary code." Exports ? Data ? Encodes the source ? What is meant with all of this... It's either input or output.... exports/data/source it's all fuzzy.
Ernst: Perhaps.. With the cycle the parity information is a part of the new encoding. Drop-T exports the parity information as in sends it to the output. That string is made of each cycle of encode and export. 
Bye,
  Skybuck. 

 Again thanks for taking the time to read my paper and to provide a reply. I will keep your comments in mind. 
 There is a possibility I can write more or better yet something else that does a great job with colors and easy reading. As I said it is suggested to aima Scientific paper at those in the Field. I hope I did that. .

Ernst

[toc] | [prev] | [next] | [standalone]

#2350

Ok,

Thanks for your reply.

It did clear up a little bit.

I have now spent too much energy on trying to understand your paper.

I also do not want to spent to much energy on it because it could be a 
troll.

I am also not trying to hurt your feeling, but I must take into account the 
possibility of trolling which is an activity which happens on the internet 
all the time, even with scientific papers.

At first glance, at least the first part of your paper seems ok, and second 
part might be ok too.

I am just being lazy and I am very bad at math.

Seeing some source code or something proving that this works might convince 
me and others that there is something to this.

However it may also expose that this is nothing.

I have one last tip for you, instead of using PDF, perhaps using HTML might 
be easier... not sure about that.

MS-Word does have some features for graphics and such.

Should be sufficient to explain bits and bit positions.

Not sure if MS-Word to PDF conversion would work with graphics in it and 
such.

Also 2N versus 2^N is a big difference so at least that should be fixed.

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#2351

Woops.

I see I made the same damn typo again.

See * correction


Ok,

Thanks for your reply.

It did clear up a little bit.

I have now spent too much energy on trying to understand your paper.
*I have not spent too much energy on trying to understand your paper.

I also do not want to spent too much energy on it because it could be a
troll.

I am also not trying to hurt your feeling, but I must take into account the
possibility of trolling which is an activity which happens on the internet
all the time, even with scientific papers.

At first glance, at least the first part of your paper seems ok, and second
part might be ok too.

I am just being lazy and I am very bad at math.

Seeing some source code or something proving that this works might convince
me and others that there is something to this.

However it may also expose that this is nothing.

I have one last tip for you, instead of using PDF, perhaps using HTML might
be easier... not sure about that.

MS-Word does have some features for graphics and such.

Should be sufficient to explain bits and bit positions.

Not sure if MS-Word to PDF conversion would work with graphics in it and
such.

Also 2N versus 2^N is a big difference so at least that should be fixed.

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#2360

On Wednesday, June 4, 2014 9:15:17 PM UTC-7, Skybuck Flying wrote:
> Woops.
> 
> 
> 
> I see I made the same damn typo again.
> 
> 
> 
> See * correction
> 
> 
> 
> 
> 
> Ok,
> 
> 
> 
> Thanks for your reply.
> 
> 
> 
> It did clear up a little bit.
> 
> 
> 
> I have now spent too much energy on trying to understand your paper.
> 
> *I have not spent too much energy on trying to understand your paper.
> 
> 
> 
> I also do not want to spent too much energy on it because it could be a
> 
> troll.
> 
> 
> 
> I am also not trying to hurt your feeling, but I must take into account the
> 
> possibility of trolling which is an activity which happens on the internet
> 
> all the time, even with scientific papers.
> 
> 
> 
> At first glance, at least the first part of your paper seems ok, and second
> 
> part might be ok too.
> 
> 
> 
> I am just being lazy and I am very bad at math.
> 
> 
> 
> Seeing some source code or something proving that this works might convince
> 
> me and others that there is something to this.
> 
> 
> 
> However it may also expose that this is nothing.
> 
> 
> 
> I have one last tip for you, instead of using PDF, perhaps using HTML might
> 
> be easier... not sure about that.
> 
> 
> 
> MS-Word does have some features for graphics and such.
> 
> 
> 
> Should be sufficient to explain bits and bit positions.
> 
> 
> 
> Not sure if MS-Word to PDF conversion would work with graphics in it and
> 
> such.
> 
> 
> 
> Also 2N versus 2^N is a big difference so at least that should be fixed.
> 
> 
> 
> Bye,
> 
>   Skybuck.



 I have taken some of your advice and changed wording. I will continue to consider crafting a version that is easier to read. I am not in a hurry to have this paper published. I'll continue to work towards perfection. It's all a learning experience for me. I think it would be wise to wait at least a year. That way I have time enough to grow as a writer. Knowing something is one thing. Writing it down is another. Not everyone that can do a thing can write a paper. 

 I realize that the signal to noise ratio of paper is high. I also realize my original intent is to have reader do the work of reasoning along with reading what is written. If it requires several reads so be it. I have to read stuff several times; "it ain't no big thang"

 If I may suggest a simple method of seeing there is no need to doubt the foundation of Dynamic Unary Encoding?  Simply work out a few cycles by hand. perhaps lengths 2,3 and 4? Encode and Decode. I think once you go hands on the rest will become more interesting to you. 

Also you prompted me to review my paper. Because of that prompting I realize now that the last update was made with a really old draft. Some of the early maths were just place-holders so to speak. I had a serious and embarrassing boo-boo. I still feel unsure having spaced-out the obvious flaw so I should write a program to test the maths. C Language programs have become my maths and proofs ( of a kind) are a lot of the programming I do.


 Again I appreciate the conversation. You can read the updated paper probably after Tuesday. Weekend updates are slow on arXiv

I will attempt humour again with a video link https://www.youtube.com/watch?feature=player_detailpage&v=jYyBZE0kBtE

[toc] | [prev] | [next] | [standalone]

#2364

On Sunday, June 8, 2014 2:20:31 PM UTC-7, Ernst wrote:
> On Wednesday, June 4, 2014 9:15:17 PM UTC-7, Skybuck Flying wrote:
> 
> > Woops.
> 
> > 
> 
> > 
> 
> > 
> 
> > I see I made the same damn typo again.
> 
> > 
> 
> > 
> 
> > 
> 
> > See * correction
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Ok,
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks for your reply.
> 
> > 
> 
> > 
> 
> > 
> 
> > It did clear up a little bit.
> 
> > 
> 
> > 
> 
> > 
> 
> > I have now spent too much energy on trying to understand your paper.
> 
> > 
> 
> > *I have not spent too much energy on trying to understand your paper.
> 
> > 
> 
> > 
> 
> > 
> 
> > I also do not want to spent too much energy on it because it could be a
> 
> > 
> 
> > troll.
> 
> > 
> 
> > 
> 
> > 
> 
> > I am also not trying to hurt your feeling, but I must take into account the
> 
> > 
> 
> > possibility of trolling which is an activity which happens on the internet
> 
> > 
> 
> > all the time, even with scientific papers.
> 
> > 
> 
> > 
> 
> > 
> 
> > At first glance, at least the first part of your paper seems ok, and second
> 
> > 
> 
> > part might be ok too.
> 
> > 
> 
> > 
> 
> > 
> 
> > I am just being lazy and I am very bad at math.
> 
> > 
> 
> > 
> 
> > 
> 
> > Seeing some source code or something proving that this works might convince
> 
> > 
> 
> > me and others that there is something to this.
> 
> > 
> 
> > 
> 
> > 
> 
> > However it may also expose that this is nothing.
> 
> > 
> 
> > 
> 
> > 
> 
> > I have one last tip for you, instead of using PDF, perhaps using HTML might
> 
> > 
> 
> > be easier... not sure about that.
> 
> > 
> 
> > 
> 
> > 
> 
> > MS-Word does have some features for graphics and such.
> 
> > 
> 
> > 
> 
> > 
> 
> > Should be sufficient to explain bits and bit positions.
> 
> > 
> 
> > 
> 
> > 
> 
> > Not sure if MS-Word to PDF conversion would work with graphics in it and
> 
> > 
> 
> > such.
> 
> > 
> 
> > 
> 
> > 
> 
> > Also 2N versus 2^N is a big difference so at least that should be fixed.
> 
> > 
> 
> > 
> 
> > 
> 
> > Bye,
> 
> > 
> 
> >   Skybuck.
> 
> 
> 
> 
> 
> 
> 
>  I have taken some of your advice and changed wording. I will continue to consider crafting a version that is easier to read. I am not in a hurry to have this paper published. I'll continue to work towards perfection. It's all a learning experience for me. I think it would be wise to wait at least a year. That way I have time enough to grow as a writer. Knowing something is one thing. Writing it down is another. Not everyone that can do a thing can write a paper. 
> 
> 
> 
>  I realize that the signal to noise ratio of paper is high. I also realize my original intent is to have reader do the work of reasoning along with reading what is written. If it requires several reads so be it. I have to read stuff several times; "it ain't no big thang"
> 
> 
> 
>  If I may suggest a simple method of seeing there is no need to doubt the foundation of Dynamic Unary Encoding?  Simply work out a few cycles by hand. perhaps lengths 2,3 and 4? Encode and Decode. I think once you go hands on the rest will become more interesting to you. 
> 
> 
> 
> Also you prompted me to review my paper. Because of that prompting I realize now that the last update was made with a really old draft. Some of the early maths were just place-holders so to speak. I had a serious and embarrassing boo-boo. I still feel unsure having spaced-out the obvious flaw so I should write a program to test the maths. C Language programs have become my maths and proofs ( of a kind) are a lot of the programming I do.
> 
> 
> 
> 
> 
>  Again I appreciate the conversation. You can read the updated paper probably after Tuesday. Weekend updates are slow on arXiv
> 
> 
> 
> I will attempt humour again with a video link https://www.youtube.com/watch?feature=player_detailpage&v=jYyBZE0kBtE



 Yeah I had about a week of "programmers Block." Nothing seemed real and that part of my brain that works with DUE seemed to be off-line.. It feels like it's coming back.

So without further Ammonium diuranate (a·dieu) I believe this is a mathematics generating the Element and Cycle counts.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#define LIMIT1 500

void main(void)
         {
//
           double two = 2,d1,d2,n;
printf("This code is the property of Ernst. D. Berg\n" Non-commercial use is granted.\n Any modifications must be documented and the original code must be included with any subsequent distribution.\n"); 
           printf("===================================================== First set ===========================================\n");

          for(n=1;n<LIMIT1;n+=1)
            {
                d1 = pow( two, n ); d1 = pow(two,d1);
                d2 = n + 1; d2 = pow( two, d2 );
                printf("For N = %f The number of Elements are %f The number of Cycles are %f \n",n,d2,d1/d2);
            }


          /* Generate the Element count and cycle counts for all other parity reference and length combinations */
          printf("==================================================== Second set =============================================\n");

         for(n=1;n<LIMIT1;n+=1)
            {
               d1 = log2(n); d1 = floor(d1); d1 += 1; d1 = pow(two,d1); //pow( two, n );
               d2 = n+1; d2 = pow( two, d2 ); // ;
              printf("For N = %f The number of Elements are %f The number of Cycles are %f \n",n,d1,d2/d1);
           }

         } // endo main  
~                                                                                                                                                            
~                                                                                                                                                            
Sorry to have gone brain dead on uploading the prior to tomorrow revision. Like I said I know what it is and does but writing it down is tricky.

[toc] | [prev] | [next] | [standalone]

#2389

On Wednesday, May 28, 2014 4:56:06 PM UTC-7, Ernst wrote:
> On Friday, May 16, 2014 2:16:50 PM UTC-7, Ernst wrote:
> 
> > On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > 
> 
> > > Introduction to Dynamic Unary Encoding.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > http://arxiv.org/abs/1405.2846
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > >  I would assume this is a welcome discovery to data compression folk.  I am very interested in what people think because I still have so much to learn.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Feel free to write to the email listed on the paper. 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > >  Ernst
> 
> > 
> 
> > 
> 
> > 
> 
> > An update fixing typos and adding clarifications will be available 05/17/2014
> 
> > 
> 
> > 
> 
> > 
> 
> >  It is possible to look so hard one cannot see.
> 
> 
> 
> A third draft is now available.
> 
> 
> 
> On examination of string lengths one and two it was realized that three categories of cycle spectrum existed. Also there is a website if folks are interested in chatting about Dynamic Unary Encoding eberg.us
> 
> 
> 
> Thank you for your time.

I could have screamed!

I looked and had a double phrase ( typed the same two words twice together ) and I had missed changing the elements in the footnote set.

I just uploaded another draft.  So in a couple of days there will be a newer version.

Ernst

[toc] | [prev] | [next] | [standalone]

#2335

In some sense the cycle length maybe related to the solution length in the rubikon (or a deterministic rubik's cube solution) algorithm. The related lengths of connected groups of solutions can be used to traverse a sequence of solutions, and sometimes a choice between two solutions along different paths can store information.

[toc] | [prev] | [next] | [standalone]

#2345

On Thursday, May 29, 2014 5:54:39 PM UTC-7, jacko wrote:
> In some sense the cycle length maybe related to the solution length in the rubikon (or a deterministic rubik's cube solution) algorithm. The related lengths of connected groups of solutions can be used to traverse a sequence of solutions, and sometimes a choice between two solutions along different paths can store information.

Hry jacko how is it going?

I will look into that. I am happy to read about your thoughts. 
 I am still exploring what the heck they are myself.

One theory is that it is a kind of number we must accept to exist. A dynamic value in finite state-space where binary numbers are considered finite value in infinite state-space.
 I hope folks don't mind I am coining State-Space to denote a defined bit length. 

[toc] | [prev] | [next] | [standalone]

#2373

On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> Introduction to Dynamic Unary Encoding.
> 
> 
> 
> http://arxiv.org/abs/1405.2846
> 
> 
> 
>  I would assume this is a welcome discovery to data compression folk.  I am very interested in what people think because I still have so much to learn.
> 
> 
> 
> Feel free to write to the email listed on the paper. 
> 
> 
> 
> 
> 
>  Ernst

    Not a lot of info beyond what you list here is shown in the document 
abstract.

    Unary Coding is, however, very optimal for BINARY BASE register 
functions (it doesn't have to run a decision tree) or anything very complex just allocate memory blocks for each bit toggled. 

    For example, if you have a register value that exceeds a UNSIGNED DOUBLE 
WORD.

http://en.wikipedia.org/wiki/Integer_%28computer_science%29

    Then using UNARY representation for a preceding WORD EXPANSION register 
allocation is greatly optimal.


    Assembly value WEXP which doubles the number of registers allocated per 
each 1 bit preceding UNARY WEXP value.

    Of course, if you want true simple conversion sizes between OS max bit 
lengths, then you'd make the word expansion register fit the lowest bit 
length then double up from there.

    For example, in an unsigned 8-bit max system, if you had a WEXP assembly 
value (which equals the max bit-word length of the system), preceding the 
8-bit Byte value, then that would require the system to allocated a fake 
register tree for those values.  Treating the temporary register values as 
simple allocated ram until processed.

    An assembly value of WEXP (8-bytes on an 8-byte max computer system) 
before an 8-bit UNSIGNED BYTE value would tell the system how many multiples 
of UNSIGNED 8-byte memory spaces to allocate for that particular value.

   IF the compiler finds WEXP value of 00000011 preceding a BYTE allocation 
of 01101111 then it allocates 2 extra unsigned bytes of memory space, giving 
a simulated register span of 3 times 8 bytes = 24 bits.  A WEXP value of 
00000111  would give you (8 *4) virtual 32-bit processing function on an 
8-bits max computing system.  If you have more than one WEXP assembly value 
in a row, then you simply allocate max-bit-value for system times those 
number of bits.  A WEXP value of 00000111 which precedes another value WEXP 
11111111 should create an error, but won't because the primary function is, 
"Every bit found in a WEXP value allocates a Max-bit-length value".

    A WEXP value of 10001001 is equal to a WEXP value of 11100000 is equal 
to a WEXP value of 00000111.  Bit orders matter not, just the amount of bits 
turned on for the value (which makes this automatically compatible with all 
ENDIAN systems).

    Note that a WEXP value preceding a memory allocation Assembly value 
results in Max-Memory bits allocated per bits found in the WEXP value.  In 
this way you can essentially allocate all of the system's memory at any time 
if required.  Obviously, you'd want to use yet another assembly code command 
to signify storage zones for WEXP values in regards to using system ram 
versus hard drive space or any other peripheral hooked up to the hardware. 
Doing so would vastly simplify virtual memory usage and allow rapid 
expansion allocations.

    This I came up with way back in 1996 as a simple bypass to hardware 
incompatibility issues. 

[toc] | [prev] | [next] | [standalone]

#2374

On Wednesday, June 11, 2014 3:56:10 AM UTC-4, matrix...@gmail.com wrote:
> On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > Introduction to Dynamic Unary Encoding.

GOOFED on that last post.
This line reads:

   IF the compiler finds WEXP value of 00000011 preceding a BYTE allocation
of 01101111 then it allocates 2 extra unsigned bytes of memory space, giving
a simulated register span of 3 times 8 bytes = 24 bits.

This line should read:

   IF the compiler finds WEXP value of 00001111 preceding a BYTE allocation
of 01101111 then it allocates 4 extra unsigned bytes of memory space, giving
a simulated register span of 4 times 8 bytes = 32 bits.

----

Sleepy posting.  I get my thoughts out, but am lousy at groggy proofreading.

The WEXP assembly value is noexistent as this is just a simple invention to serve a purpose of allowing extra virtual register allocation & processing at the cost of current active memory.

A WEXP value on an 8-bit-max computer with 4 bits turned on anywhere in the value would allocate 1 8-bit register space (for processing) and 3 extra system memory spaces.  It would then use standardized carry procedures to process a 32-bit memory address or computational value (if the system has sufficient memory to address or hard drive space to address as the WEXP concept would have another value to indicate hardware location pipelining).

Alternatively, a WSML value would indicate how many virtual sub-values a memory register would be divided into.  On a 64-bit computer, it is most efficient & speedy to address memory spaces in terms of absolute 64-bit locations and deal with all numeric values as 64-bit terms.  Which, although fast, is wasteful for some programs and lacks easy backwards compatibility with older programs which address only 16-bit or 32-bit memory addresses.

A WSML preceding value containing 4 on-bits would treat a single 64-bit memory register as a clumped set of 4 8-bit register values. In essence a simulated older memory space address clump, but with all the speed of the 64-bit processor addressing.  All of the nonsense with max-system-bit-width has been hampering proper computing processor development for far too long and this has to firstly be properly dealt with at the hardware & assembly code levels before the programming tools can properly follow.

[toc] | [prev] | [next] | [standalone]

#2376

On Wednesday, June 11, 2014 3:38:27 AM UTC-7, matrix...@gmail.com wrote:
> On Wednesday, June 11, 2014 3:56:10 AM UTC-4, matrix...@gmail.com wrote:
> 
> > On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > 
> 
> > > Introduction to Dynamic Unary Encoding.
> 
> 
> 
> GOOFED on that last post.
> 
> This line reads:
> 
> 
> 
>    IF the compiler finds WEXP value of 00000011 preceding a BYTE allocation
> 
> of 01101111 then it allocates 2 extra unsigned bytes of memory space, giving
> 
> a simulated register span of 3 times 8 bytes = 24 bits.
> 
> 
> 
> This line should read:
> 
> 
> 
>    IF the compiler finds WEXP value of 00001111 preceding a BYTE allocation
> 
> of 01101111 then it allocates 4 extra unsigned bytes of memory space, giving
> 
> a simulated register span of 4 times 8 bytes = 32 bits.
> 
> 
> 
> ----
> 
> 
> 
> Sleepy posting.  I get my thoughts out, but am lousy at groggy proofreading.
> 
> 
> 
> The WEXP assembly value is noexistent as this is just a simple invention to serve a purpose of allowing extra virtual register allocation & processing at the cost of current active memory.
> 
> 
> 
> A WEXP value on an 8-bit-max computer with 4 bits turned on anywhere in the value would allocate 1 8-bit register space (for processing) and 3 extra system memory spaces.  It would then use standardized carry procedures to process a 32-bit memory address or computational value (if the system has sufficient memory to address or hard drive space to address as the WEXP concept would have another value to indicate hardware location pipelining).
> 
> 
> 
> Alternatively, a WSML value would indicate how many virtual sub-values a memory register would be divided into.  On a 64-bit computer, it is most efficient & speedy to address memory spaces in terms of absolute 64-bit locations and deal with all numeric values as 64-bit terms.  Which, although fast, is wasteful for some programs and lacks easy backwards compatibility with older programs which address only 16-bit or 32-bit memory addresses.
> 
> 
> 
> A WSML preceding value containing 4 on-bits would treat a single 64-bit memory register as a clumped set of 4 8-bit register values. In essence a simulated older memory space address clump, but with all the speed of the 64-bit processor addressing.  All of the nonsense with max-system-bit-width has been hampering proper computing processor development for far too long and this has to firstly be properly dealt with at the hardware & assembly code levels before the programming tools can properly follow.

Not a problem to be not-so perfect. I feel it is the conformists that should worry.

Like you were I am sleepy so I will now look into your reply with a second cup of coffee. I do figure that I will be learning a lot more of about what we use Unary and Unary code for. 
I will reply a second time once I process your input.

Ernst

[toc] | [prev] | [next] | [standalone]

#2377

On Wednesday, June 11, 2014 3:38:27 AM UTC-7, matrix...@gmail.com wrote:
> On Wednesday, June 11, 2014 3:56:10 AM UTC-4, matrix...@gmail.com wrote:
> 
> > On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > 
> 
> > > Introduction to Dynamic Unary Encoding.
> 
> 
> 
> GOOFED on that last post.
> 
> This line reads:
> 
> 
> 
>    IF the compiler finds WEXP value of 00000011 preceding a BYTE allocation
> 
> of 01101111 then it allocates 2 extra unsigned bytes of memory space, giving
> 
> a simulated register span of 3 times 8 bytes = 24 bits.
> 
> 
> 
> This line should read:
> 
> 
> 
>    IF the compiler finds WEXP value of 00001111 preceding a BYTE allocation
> 
> of 01101111 then it allocates 4 extra unsigned bytes of memory space, giving
> 
> a simulated register span of 4 times 8 bytes = 32 bits.
> 
> 
> 
> ----
> 
> 
> 
> Sleepy posting.  I get my thoughts out, but am lousy at groggy proofreading.
> 
> 
> 
> The WEXP assembly value is noexistent as this is just a simple invention to serve a purpose of allowing extra virtual register allocation & processing at the cost of current active memory.
> 
> 
> 
> A WEXP value on an 8-bit-max computer with 4 bits turned on anywhere in the value would allocate 1 8-bit register space (for processing) and 3 extra system memory spaces.  It would then use standardized carry procedures to process a 32-bit memory address or computational value (if the system has sufficient memory to address or hard drive space to address as the WEXP concept would have another value to indicate hardware location pipelining).
> 
> 
> 
> Alternatively, a WSML value would indicate how many virtual sub-values a memory register would be divided into.  On a 64-bit computer, it is most efficient & speedy to address memory spaces in terms of absolute 64-bit locations and deal with all numeric values as 64-bit terms.  Which, although fast, is wasteful for some programs and lacks easy backwards compatibility with older programs which address only 16-bit or 32-bit memory addresses.
> 
> 
> 
> A WSML preceding value containing 4 on-bits would treat a single 64-bit memory register as a clumped set of 4 8-bit register values. In essence a simulated older memory space address clump, but with all the speed of the 64-bit processor addressing.  All of the nonsense with max-system-bit-width has been hampering proper computing processor development for far too long and this has to firstly be properly dealt with at the hardware & assembly code levels before the programming tools can properly follow.

Second reply here..

-------------------------

Okay, good job including a link for me to follow.  There are a great many things I do not know enough about yet. I appreciate the conversation.

Coffee hot and strong ATM. 


I will commit this to study. Hey it might come up in conversation at a party.. We never know. 

Here is a question back.. Serving the virtual Volley Ball into your court. What do you see in dynamic unary? I'm exploring the idea that is is a number. In that it exists in finite space and has a dynamic value.  I'm imagining is as a data type for quantum computers..  Just tossing that out.. Imagination welcomed!

[toc] | [prev] | [next] | [standalone]

#2378

On Wednesday, June 11, 2014 4:37:58 PM UTC-4, Ernst wrote:
> On Wednesday, June 11, 2014 3:38:27 AM UTC-7, matrix...@gmail.com wrote:
> 
> > On Wednesday, June 11, 2014 3:56:10 AM UTC-4, matrix...@gmail.com wrote:
> 
> > 
> 
> > > On Tuesday, May 13, 2014 12:24:07 PM UTC-4, Ernst wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Introduction to Dynamic Unary Encoding.
> 
> > 
> 
> > 
> 
> > 
> 
> > GOOFED on that last post.
> 
> > 
> 
> > This line reads:
> 
> > 
> 
> > 
> 
> > 
> 
> >    IF the compiler finds WEXP value of 00000011 preceding a BYTE allocation
> 
> > 
> 
> > of 01101111 then it allocates 2 extra unsigned bytes of memory space, giving
> 
> > 
> 
> > a simulated register span of 3 times 8 bytes = 24 bits.
> 
> > 
> 
> > 
> 
> > 
> 
> > This line should read:
> 
> > 
> 
> > 
> 
> > 
> 
> >    IF the compiler finds WEXP value of 00001111 preceding a BYTE allocation
> 
> > 
> 
> > of 01101111 then it allocates 4 extra unsigned bytes of memory space, giving
> 
> > 
> 
> > a simulated register span of 4 times 8 bytes = 32 bits.
> 
> > 
> 
> > 
> 
> > 
> 
> > ----
> 
> > 
> 
> > 
> 
> > 
> 
> > Sleepy posting.  I get my thoughts out, but am lousy at groggy proofreading.
> 
> > 
> 
> > 
> 
> > 
> 
> > The WEXP assembly value is noexistent as this is just a simple invention to serve a purpose of allowing extra virtual register allocation & processing at the cost of current active memory.
> 
> > 
> 
> > 
> 
> > 
> 
> > A WEXP value on an 8-bit-max computer with 4 bits turned on anywhere in the value would allocate 1 8-bit register space (for processing) and 3 extra system memory spaces.  It would then use standardized carry procedures to process a 32-bit memory address or computational value (if the system has sufficient memory to address or hard drive space to address as the WEXP concept would have another value to indicate hardware location pipelining).
> 
> > 
> 
> > 
> 
> > 
> 
> > Alternatively, a WSML value would indicate how many virtual sub-values a memory register would be divided into.  On a 64-bit computer, it is most efficient & speedy to address memory spaces in terms of absolute 64-bit locations and deal with all numeric values as 64-bit terms.  Which, although fast, is wasteful for some programs and lacks easy backwards compatibility with older programs which address only 16-bit or 32-bit memory addresses.
> 
> > 
> 
> > 
> 
> > 
> 
> > A WSML preceding value containing 4 on-bits would treat a single 64-bit memory register as a clumped set of 4 8-bit register values. In essence a simulated older memory space address clump, but with all the speed of the 64-bit processor addressing.  All of the nonsense with max-system-bit-width has been hampering proper computing processor development for far too long and this has to firstly be properly dealt with at the hardware & assembly code levels before the programming tools can properly follow.
> 
> 
> 
> Second reply here..
> 
> 
> 
> -------------------------
> 
> 
> 
> Okay, good job including a link for me to follow.  There are a great many things I do not know enough about yet. I appreciate the conversation.
> 
> 
> 
> Coffee hot and strong ATM. 
> 
> 
> 
> 
> 
> I will commit this to study. Hey it might come up in conversation at a party.. We never know. 
> 
> 
> 
> Here is a question back.. Serving the virtual Volley Ball into your court. 

From your website

http://www.eberg.us/dynamic-unary-encoding/
What do you see in dynamic unary? I'm exploring the idea that is is a number. In that it exists in finite space and has a dynamic value.  I'm imagining is as a data type for quantum computers..  Just tossing that out.. Imagination welcomed!

It would seem it could be Cryptography's Holy Grail.

Does dynamic unary have a place in Physics?  Does it explain why or how things like Electrons spin? Does it explain why or how particles appear to pop in an out of existence?

Is Dynamic Unary actually the correct data type for Quantum Computing?

----

My reply:

Dynamic Unary Encoding does not fit the specific encoding scheme of this low-potentiality particular universe type.

Sorry.

I've been around a bit and there are quite a few things I could share on that if it really mattered in the long run to this world.

However, if you really want to comprehend how this universe is truly shaped and the 4th-directional atoms with "magnetic" fields (actually just part of the 4-D matter expressing itself as a magnetic field as it pushes against this 3-directional universe), you need to think in terms of spherical shapes, not 3-D grids.

This particular universe is shaped like a 3-D Limacon.
http://en.wikipedia.org/wiki/Lima%C3%A7on

http://mathworld.wolfram.com/Limacon.html

The Wolfram link shows much better detail in terms of the shape.
r = b + (a * cos (t))
When the value of B is at zero, the universe is a sphere.
As the value of B increases, a balloon shape grows inside, getting more circular as it increases in size.
Note in particular that the AXIS CENTER of the Limacon slowly SHIFTS LEFTWARD as the value of the variable of "B" grows larger.

This particular universe has a positive matter inner 3D balloon rotating slowly in one direction.
The outer sphere is anti-matter.
The actual shape of this universe is a 5D Quantum Sphere, but it is OFF-CENTERED on the time-axis.  As the value of "B" grows larger over "time", the inner balloon shape grows more spherical and expands to eventually contact the anti-matter outer shell.  This is not a uniform event, some regions of space will contact the antimatter shell far faster than others and there exists large gaps of anti-matter space unoccupied by anti-matter (just as there are large gaps of positive-matter space unoccupied by positive-matter).

Before this particular universe "began", the 5D Quantum Sphere was somewhat uniform. But the "wobble" in the time axis (the value of "B" in the Limacon generation formula) pushed itself into empty space and expressed one of the rotational velocities as "positive matter" (AKA "The Big Bang" which did not "Bang") and the other opposite rotational axis expressed itself as anti-matter in the outer shell.

That, quite simply, is the true cause of the so-called "Expansion of the Universe".  As the value of "B" in the Limacon  formula (off-center 5D Quantum Sphere) increases, the inner positive matter balloon expands and grows more spherical (the notation of this universe's "Expansion is Mysteriously Slowing Down").  The closer that the expression of positive matter is to a spherical shape, the closer we are to the annihilation of this universe back to neutral 5D matter.  In short, a ZERO SUM UNIVERSE.

5D (AKA "5 Directional") Matter has 5 rotational axial spin directions (all able to spin at velocities matching or different to all the other axial spin directions.  It also can move in 5 directional vectors from the centerpoint of a sphere through space.

Think of a circle. Now draw a dot at the center of that circle.  Draw a dot at any point on the circle's curve.  Now imagine this circle to be like a plate.  You can lift it up and rotate it as you please.  The dots are mere reference points to let you know which way the circle is moving through space.

The circle can spin in a leftward or rightward direction, at one velocity.
The circle can also be moved toward any direction in planar space from the center point of the circle to any vector point which is on the curve.  A TWO DIRECTIONAL OBJECT.  Two directions.  One spin direction and one direction in planar space.  Any other 2D object has to follow these rules.

A THREE DIRECTIONAL object like a sphere has a rotational axis where it can rotate left or right, but at any angle like spinning a globe on a pivot.  It has the SPIN AXIS, but also the TILT AXIS (both of which can rotate at velocities differing from each other).  Thus, two SPIN DIRECTIONS.  A sphere can also move from any point in the exact center of the sphere toward any directional point vector expressed on the surface of the sphere.  A THREE DIRECTIONAL OBJECT.

A FOUR DIRECTIONAL Hypersphere has 3 spin axial directions plus one 4D movement vector direction.  When a 4D hypersphere expresses itself upon our universe we get two different magnetic fields (with one +neutral and one -neutral magnetic fields which most engineers ignore because they've been deliberately deceived by the teaching professions).

A FIVE DIRECTIONAL Quantum Sphere expresses itself as "Gravity" and "light".
You can figure out the rest as it should all be fairly obvious by now and if you cannot figure it out.  Well, IQ is a genetic limit, not a conceptual one.  I cannot make anyone genetically smarter just by merely talking to them.

It is just something simple and obvious that you should know.
The universe is not a pile of cubes and cubic math has so very little value in Real Space.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.compression

csiph-web