Comments for Mark Nelson http://marknelson.us Programming, mostly. Wed, 16 May 2012 08:30:05 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Comment on The Million Random Digit Challenge Revisited by Ashish http://marknelson.us/2006/06/20/million-digit-challenge/comment-page-7/#comment-542212 Ashish Wed, 16 May 2012 08:30:05 +0000 /2006/06/20/million-digit-challenge/#comment-542212 The prize amount ecouurages to try this. In a way, challange creator also doubtful about the impossibility of this work. Hence he seems has not taken much risk ;) The prize amount ecouurages to try this. In a way, challange creator also doubtful about the impossibility of this work. Hence he seems has not taken much risk ;)

]]> Comment on Intellectual Property: A Modest Proposal by Quora http://marknelson.us/2005/10/03/ip-proposal/comment-page-1/#comment-540385 Quora Sat, 12 May 2012 22:14:33 +0000 http://marknelson.us/2005/10/03/ip-proposal/#comment-540385 <strong>What is Brazil's stance on music piracy?...</strong> Brazil's music industry is being hurt by changes in distribution as much or more than the business in the US. For example: > In Brazil, full priced major label local album releases from the five largest music companies in 2008 were down 80% from their... What is Brazil’s stance on music piracy?…

Brazil’s music industry is being hurt by changes in distribution as much or more than the business in the US. For example: > In Brazil, full priced major label local album releases from the five largest music companies in 2008 were down 80% from their…

]]> Comment on LZW Data Compression by Mark Nelson http://marknelson.us/1989/10/01/lzw-data-compression/comment-page-6/#comment-531138 Mark Nelson Tue, 01 May 2012 17:59:15 +0000 /1989/10/01/lzw-data-compression/#comment-531138 Hi Robert, Sorry, I didn't get a chance to address this properly until today - I was traveling. First, I think using pseudocode was a bad idea on my part, but it was a long time ago, and that was a different me. I've got an updated version of the article that I think is a lot more trustworthy, and it only uses C++ code - no pseudocode. The decompress routine looks like this: [C] unsigned int code; unsigned int next_code = 257; while ( in >> code ) { out << strings[code]; if ( previous_string.size() ) strings[next_code++] = previous_string + strings[code][0]; previous_string = strings[code]; } [/C] In this case, previous_string is a standin for OLD_CODE, and it does exactly what you are saying it should do. In the pseudo code, I am very casually going back and forth between strings and codes, which is a confusing mistake. So when I say OLD_CODE = NEW_CODE, I am doing so on the idea that NEW_CODE == STRING. Which it is, more or less, if you look up NEW_CODE in the library, you get STRING. In any case, your correction is well taken, and as I say, I think the whole thing is a lot more clear and less prone to misinterpretation in the new article at: http://marknelson.us/2011/11/08/lzw-revisited/ Thanks for your input, and thanks for reading. - Mark Hi Robert,

Sorry, I didn't get a chance to address this properly until today - I was traveling.

First, I think using pseudocode was a bad idea on my part, but it was a long time ago, and that was a different me.
I've got an updated version of the article that I think is a lot more trustworthy, and it only uses C++ code - no pseudocode. The decompress routine looks like this:

PLAIN TEXT
C:
  1. unsigned int code;
  2.   unsigned int next_code = 257;
  3.   while ( in>> code ) {
  4.     out <<strings[code];
  5.     if ( previous_string.size() )
  6.       strings[next_code++] = previous_string + strings[code][0];
  7.     previous_string = strings[code];
  8.   }

In this case, previous_string is a standin for OLD_CODE, and it does exactly what you are saying it should do.

In the pseudo code, I am very casually going back and forth between strings and codes, which is a confusing mistake. So when I say OLD_CODE = NEW_CODE, I am doing so on the idea that NEW_CODE == STRING. Which it is, more or less, if you look up NEW_CODE in the library, you get STRING.

In any case, your correction is well taken, and as I say, I think the whole thing is a lot more clear and less prone to misinterpretation in the new article at:

http://marknelson.us/2011/11/08/lzw-revisited/

Thanks for your input, and thanks for reading.

- Mark

]]> Comment on LZW Data Compression by Robert K http://marknelson.us/1989/10/01/lzw-data-compression/comment-page-6/#comment-529782 Robert K Mon, 30 Apr 2012 02:19:25 +0000 /1989/10/01/lzw-data-compression/#comment-529782 How does that work with line 8 then? "add OLD_CODE + CHARACTER to the translation table" OLD_CODE needs to be a string in this context, no? Sure seems like what you want is the old string value in this case, not the old (unresolved) lookup code. How does that work with line 8 then? "add OLD_CODE + CHARACTER to the translation table"

OLD_CODE needs to be a string in this context, no? Sure seems like what you want is the old string value in this case, not the old (unresolved) lookup code.

]]> Comment on LZW Data Compression by Mark Nelson http://marknelson.us/1989/10/01/lzw-data-compression/comment-page-6/#comment-529679 Mark Nelson Sun, 29 Apr 2012 23:57:10 +0000 /1989/10/01/lzw-data-compression/#comment-529679 No. Codes are integer values, which mostly start at 256 or 257 and increase montonically. Strings are sequences of bytes. So the assignment you propose doesn't work - it is assuming some kind of implicit conversion from one type to another, and that doesn't happen. - Mark No.

Codes are integer values, which mostly start at 256 or 257 and increase montonically.

Strings are sequences of bytes.

So the assignment you propose doesn't work - it is assuming some kind of implicit conversion from one type to another, and that doesn't happen.

- Mark

]]> Comment on LZW Data Compression by Robert K http://marknelson.us/1989/10/01/lzw-data-compression/comment-page-6/#comment-529617 Robert K Sun, 29 Apr 2012 22:43:03 +0000 /1989/10/01/lzw-data-compression/#comment-529617 I believe Line 9 of Figure 3 (decompression pseudocode): [c] OLD_CODE = NEW_CODE [/c] ... should actually be: [c] OLD_CODE = STRING [/c] No? I believe Line 9 of Figure 3 (decompression pseudocode):

PLAIN TEXT
C:
  1. OLD_CODE = NEW_CODE

... should actually be:

PLAIN TEXT
C:
  1. OLD_CODE = STRING

No?

]]> Comment on The Million Random Digit Challenge Revisited by Ernst http://marknelson.us/2006/06/20/million-digit-challenge/comment-page-7/#comment-523607 Ernst Sat, 21 Apr 2012 04:22:41 +0000 /2006/06/20/million-digit-challenge/#comment-523607 on April 11th, 2012 at 8:39 am, Tobbi said: Ernst, here are some useful comments for your work on challenge >> 617 and 673 is 415241 617 and 673 is 1290, not 415241 >> ... but since we are all interested in prime pairs ... log(a * b) = log(a) + log(b) Let million-digit-file = x * y, then log(x) + log(y) = log(x * y) = log(mdf) =~ 3320000 >> Hint: Well try recursive modulus. My hint would be: Well try math! Pardon Tobbi those are the factors of 415241 as in 617 times 673 = 415241. I can understand your confusion and I promise to not try and trick you again. Be Well! on April 11th, 2012 at 8:39 am, Tobbi said:

Ernst, here are some useful comments for your work on challenge

>> 617 and 673 is 415241

617 and 673 is 1290, not 415241

>> ... but since we are all interested in prime pairs ...

log(a * b) = log(a) + log(b)

Let million-digit-file = x * y, then
log(x) + log(y) = log(x * y) = log(mdf) =~ 3320000

>> Hint: Well try recursive modulus.

My hint would be: Well try math!

Pardon Tobbi those are the factors of 415241 as in 617 times 673 = 415241.

I can understand your confusion and I promise to not try and trick you again.

Be Well!

]]> Comment on The Million Random Digit Challenge Revisited by Ernst http://marknelson.us/2006/06/20/million-digit-challenge/comment-page-7/#comment-523606 Ernst Sat, 21 Apr 2012 04:17:43 +0000 /2006/06/20/million-digit-challenge/#comment-523606 Hey Milcho! I see you found the challenge interesting! cool! But hiding data is not in the spirit of the challenge for sure! Give it some time and maybe you will find a unique solution! Update : I'm working on bit-pattern matching using a constructed data-set. Also I am learning about OpenMP and parallel processing along with this effort. So win or lose there are benefits for trying. Ernst Hey Milcho!

I see you found the challenge interesting!

cool!

But hiding data is not in the spirit of the challenge for sure!

Give it some time and maybe you will find a unique solution!

Update :

I'm working on bit-pattern matching using a constructed data-set. Also I am learning about OpenMP and parallel processing along with this effort.
So win or lose there are benefits for trying.

Ernst

]]> Comment on Fast String Searching With Suffix Trees by to do or learn | Pearltrees http://marknelson.us/1996/08/01/suffix-trees/comment-page-3/#comment-523215 to do or learn | Pearltrees Fri, 20 Apr 2012 08:39:00 +0000 /1996/08/01/suffix-trees/#comment-523215 [...] Even you can make a tree McCreight's original algorithm for constructing a suffix tree had a few disadvantages. Principle among them was the requirement that the tree be built in reverse order, meaning characters were added from the end of the input. This ruled the algorithm out for on line processing, making it much more difficult to use for applications such as data compression. In fact, the reduction in the number of nodes is such that the time and space requirements for constructing a suffix tree are reduced from O(N 2 ) to O(N). In the worst case, a suffix tree can be built with a maximum of 2N nodes, where N is the length of the input text. Fast String Searching With Suffix Trees [...] [...] Even you can make a tree McCreight's original algorithm for constructing a suffix tree had a few disadvantages. Principle among them was the requirement that the tree be built in reverse order, meaning characters were added from the end of the input. This ruled the algorithm out for on line processing, making it much more difficult to use for applications such as data compression. In fact, the reduction in the number of nodes is such that the time and space requirements for constructing a suffix tree are reduced from O(N 2 ) to O(N). In the worst case, a suffix tree can be built with a maximum of 2N nodes, where N is the length of the input text. Fast String Searching With Suffix Trees [...]

]]> Comment on The Million Random Digit Challenge Revisited by Milcho http://marknelson.us/2006/06/20/million-digit-challenge/comment-page-7/#comment-518803 Milcho Fri, 13 Apr 2012 20:08:42 +0000 /2006/06/20/million-digit-challenge/#comment-518803 @Mark It makes sense, the rules of the game are to actually compress the data, not shuffle it around to unseen places. It took me all of one hour to write the code of what I posted above, and that's just the simplest way to use the filesystem to hide data. It's amazing how recent some of these claims for incredible compression are, and that there's still people who buy into it. Oh well, they may be wasting their time, but it's at least slightly amusing to read about it. @Mark

It makes sense, the rules of the game are to actually compress the data, not shuffle it around to unseen places. It took me all of one hour to write the code of what I posted above, and that's just the simplest way to use the filesystem to hide data.

It's amazing how recent some of these claims for incredible compression are, and that there's still people who buy into it. Oh well, they may be wasting their time, but it's at least slightly amusing to read about it.

]]>