Programmer's block

I've been working on coming up with a nice C++ (or, actually, C++0x) interface to Skein hash function.

Skein has an interesting tree mode in which it's possible to parallelize the hash function calculation to a significant degree. I wanted to write a general interface for this so I could make a command line utility that used it to test it against sha256sum command.

Applying a tree hash to an existing file is a no-brainer. But I wanted to be able to handle much more general cases in which the leaf data may not be available on a random-access basis. In particular if the file is coming in on stdin or something similar.

I was having difficulty coming up with a general extensible interface for this. Partly the interface for the system for handling leaf data needed a way to allocate chunks of leaf data to work on, and then release them. This would allow for a sliding window type approach to fetching leaf data.

My biggest and most recent breakthrough was realizing that the leaf data objects were like ::std::auto_ptr objects. I didn't want to force heap use, so I needed the data about a leaf to be copyable. But I didn't want to have to have any kind of silly reference counts or anything like that. So that meant I needed it to be moveable, not copyable. Just like auto_ptr. But auto_ptr is a klduge in C++. In C++0x there is a very nice concept called rvalue references that let you implement move semantics very cleanly.

It took me awhile to realize I wanted move semantics. I kept on beating on the interface and coming up with usage scenarios that were just awkward and broken. Once I figured it out, things went a lot easier.

Here is a link to what I finally came up with: skeintreepp.hpp.

Syndicated 2009-06-27 07:22:29 (Updated 2009-06-27 17:42:23) from Lover of Ideas

Number puzzle

Many years ago I was presented with an interesting puzzle. I did not solve it. I had to be told the answer. It is a very simple answer, but it isn't dumb. Figuring it out requires a significant leap of lateral thinking.

I figured I'd put it here for the amusement of others. Comments will be screened. I will eventually reveal the correct answer, but it may be a few months. :-) And now for the puzzle itself:

What is the next number in this sequence?

• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 20
• 22
• 24
• 31
• 100
• 121

Syndicated 2009-06-14 09:08:24 (Updated 2009-06-14 09:09:35) from Lover of Ideas

What I've been up to for the past few days

Well, actually, a whole lot of stuff, including spending some time with klicrai and someone who tends to go by Crymerci online, but doesn't have an active LJ.

But, the topic of this LJ entry is the work I've been doing on creating a nice C++ interface for Skein, Bruce Schneier and friends entry into the NIST SHA-3 competition.

Anyway, I'm basing my work on the code in their NIST submission. And, as I said before, it's a nice C++ wrapper for Skein that attempts to give access to all of Skein's nifty features that are in excess of the NIST requirements. It's a hash function, it's a PRNG, it's a MAC algorithm! No, it's Skein!

One kind of gets the impression that Bruce and company are miffed by the fact that Rijndael was chosen over Twofish for the AES competition. And their response was to create a new algorithm that was faster, probably more secure, inordinately flexible and impossible to level the "it's too complicated to analyze effectively" criticism against. That criticism was one of the reasons Twofish wasn't selected in the AES competition.

Syndicated 2009-05-24 01:36:58 from Lover of Ideas

Statistical patterns in primes

There is an interesting new result showing that the distribution of prime numbers obeys a modified version of Benford's Law. The result also shows that another sequence who's distribution is somehow fundamentally related to the distribution of primes, the 0s of the Reimann zeta function.

It is my feeling that results like this do not strongly affect the usefulness of prime number based cryptography algorithms like RSA. But this is just a guess on my part. Does anybody have a more definitive answer?

Syndicated 2009-05-15 01:18:23 from Lover of Ideas

I sympathize with Dick here

The Daily WTF is a publication I generally really enjoy. Their recent article Java is Slow! is one I sort of take issue with.

I don't like Java or anything to do with it. I've said that before in this blog and I'll say it again. I can write a Python script to print "Hello world!" that takes less time to run than an equivalent Java program.

There are sweet spot for being simple to develop in, speed and language verbosity. Java completely fails to hit any of them. It has many of the ills of a compiled language with regards to how easy it is to develop in, and is even slower in many regards than most interpreted languages, and it's almost as verbose as COBOL.

And many of you will complain that Python is definitely slower than Java and point at benchmarks. The benchmark I care the most about though is "Hello world!", and that's a benchmark Java fails miserably at.

The reason I care so much about that particular benchmark is that Java's miserable failure at it is seen by people who want to use Java as a reason absolutely EVERYTHING should be in Java. Because the JVM is so expensive to start, you should only start it once, and then Java should become your OS.

I'm sorry, but no. Python has a perfectly acceptable VM, and it starts up in 10s of milliseconds or less. It's not compiled, so it's quick and easy to develop in, and maybe it isn't as fast in the long haul, but those other attributes more than make up for it.

If I really care about speed and want to use a compiled language, I will use C++. If I don't and I want a nice, easy to develop in language, I will use Python. Others can use Perl or Ruby if they want to. Java has no reasonable place in the development landscape, and it never will.

Syndicated 2009-05-12 22:41:22 from Lover of Ideas