mult.ifario.us

The following code produces a compiler error (“Type mismatch: cannot convert from int to byte”):

byte a = 1;
byte b = 2;
byte c = a + b;

What motivated the designers of the Java language to make this an error?

I tried the Bloglines thing with NetNewsWire for a while, but then I went to dump my blogroll as an OPML (which gets processed by an XSLT stylesheet and posted in the right column on my blog), but all of the xmlUrl attributes were Bloglines-specific URLs. That is, my blogroll was locked into Bloglines. That annoyed me, especially since I wasn't informed of the lock-in in advance, so I reconstructed my subscriptions and dumped Bloglines. (That was almost as bad as when a misbehaved hotel gateway b0rked my subscriptions by 301'ing the feeds to their signup page when I connected to the hotel network.)

With the new version of NetNewsWire, NewsGator sync is now an option, and it appears to work correctly. The web interface is automatically updated, as are remote aggregators when they poll the feeds, and the OMPL export is pristine. Much better.

This week's cute interview problem came from Hanson Char:

What is the best (time, space) way to convert a Java int to a four-byte array where the zero^th entry of the array contains the LSB?

The best solution that I'm aware of is to use shift right (>>>) and a cast to grab the bytes:

public byte[] toBytes(int i) {
  return new byte[] {
    (byte)i,
    (byte)(i>>>8),
    (byte)(i>>>16),
    (byte)(i>>>24)};
}

My initial solution included some &255 that a look at the Java Language Specification convinced me were superfluous. (Narrowing conversions just truncate the leading bits in twos complement notation.)

Checking the bytecode with either javap -c or the very convenient ASM plugin for Eclipse reminds me that shift-right is a single opcode, IUSHR, parameterized by the number of bits to shift.

One alternative suggestion was to use java.nio.ByteBuffer. That solution yields comparably compact code (putInt(i)) but on inspection, the implementation uses the package-private class java.nio.Bits which just incorporates the same shifting technique as above, and the result is not surprisingly significantly slower that just using the shifting technique directly.

I have a few hundred DRM-hobbled MP3s from the iTunes Music Store, but I've decided that it no longer deserves my business. Most of the music that I like is available DRM-free and in higher-bitrate encoding from Bleep, and when what I'm looking for is not available someplace like eMusic, paying a little more for a CD will get me both a version that I can play on a Squeezebox and the good feeling that I'm not supporting a world view that includes DRM.

I'm not opposed to rights, per se, but I like to be able to exercise them. The iTunes model seemed reasonable enough, but the Squeezebox changed my mind. I can't listen to iTunes-encrypted music on the Squeezebox because Apple hasn't licensed the necessary software to SlimDevices. Why should I have to pay whatever incremental cost the licensing would add to the cost of the Squeezebox in order to exercise the rights that I purchased through iTunes? (Yes, I realize that I can strip the DRM, use icecast to redirect audio streams, etc. — all of which is more trouble than paying the incremental cost of a CD.)

It wouldn't take much for someone to win my business — $1.50/song, $11/album, no DRM, high bitrate, critical mass of artists/labels, and something reasonable for community (“also bought”, etc.) or similarity (e.g., taxonomy). Any takers for iTunes “2.0”? (No, the subscription models from Real and Yahoo! are just 1.1 efforts in my view.)

Update: It looks like the French have similar sensibilities:

[...] “It will force some proprietary systems to be opened up ... You have to be able to download content and play it on any device,” Vanneste told Reuters in a telephone interview on Monday [...]

Good wine, good food, device independence... Vive la France!

I like to answer the basic engineering skills questions given to candidates that interview for a position in my org, just to make sure that I'm not getting too rusty. This problem was particularly cute and only takes about 5 minutes if you just plow through it; on the other hand, it can be done in thirty minutes or so even if a progression of hints is needed.

Here's the statement of the problem:

Given a batch of n jobs with positive durations {t₀,...,t_n} and positive difficulties {c₀,...,c_n}, what is the optimal order of execution for the batch under the assumption that the cost of performing a job is the product of the difficulty and the start time for that job?

One way to approach this kind of problem is to assume that we know the optimal order for n jobs, and the we just need to find a best location for the a new job with duration d and cost k in the sequence. WLOG, we can assume that the optimal order for the n jobs happens to be zero through n. If the original cost is OC, the total cost of scheduling the job at slot j is:

TC(j) = c₁t₀+...+k(t_j-1+...+t₀)+c_j(d+t_j-1+...+t₀)+...
TC(j) = OC+k(t_j-1+...+t₀)+d(c_j+...+c_n)

Scheduling at j is better than scheduling at j+1 if TC(j+1)>TC(j):

0 < TC(j+1)-TC(j)
0 < (OC+k(t_j+...+t₀)+d(c_j+1+...+c_n)) - (OC+k(t_j-1+...+t₀)+d(c_j+...+c_n))
0 < kt_j - dc_j

And that's equivalent to k/d > c_j/t_j.

Thus, a lowest cost solution is to perform the jobs in descending order of difficulty per unit time. This problem also has the nice property that a greedy algorithm (“Do the hardest job per unit time first; repeat.”) produces an optimal solution.

Back in the late 1980's and very early 1990's, I experimented with bedroom music production using a couple of keyboards (an Ensoniq ESQ-1 and later an Ensoniq EPS) and a Tascam four-tracker. (I'm surprised to find that Tascam still makes cassette-based recorders.) To set the technology scene for the very early 1990's, Windows was at 3.1, MacOS was at System 7, and NeXT started shipping the NeXTstation. (A NeXTstation was my computer of choice from 1990-1995.)

I recently started experimenting with music again, and so far, I'm impressed with the improvements from the last fifteen years of advances. (Certainly, the increase in the utility of a computer for making music is orders of magnitude larger than the increase in the utility of a computer for writing documents.)

The first thing that I did was rip a few of my old recordings to MP3s using Audacity via a tape deck connected to a Firewire interface. Next, I downloaded some software synthesis packages to experiment with: Reason, Reaktor, and Max/MSP.

Reaktor was the one that I bought. It offers the standard GUI that imitates the front panel of a rack-mountable synthesizer, and at least from the perspective of someone who shops at Bleep, it comes with a great set of instruments — synthesizers, sequencers, "grooveboxes", effects, and other widgets that defy categorization.

Under the covers, Reaktor provides a visual, flow-oriented programming environment called Core where GUI components (knobs, lamps, level meters, ADSR graphs, etc.), DSP components, MIDI components, various operations, envelopes, LFOs, oscillators, and filters can be wired together and composed into virtual instruments. Better yet, all of the instruments supplied with Reaktor have the "source" included, so tweaking is easy.

Max/MSP was the first runner up, with an instrument construction environment similar to Reaktor's but a much thinner collection of example instruments. It turns out that there's a similar system under development as open source called Pure Data or "Pd" that runs on multiple systems. There's a book-in-progress on electronic music that uses Pd, a collection of "externals" for Pd hosted at SourceForge, and even a tool ("Paradiddle") to bind Cocoa user interfaces onto Pd patches. (Miller Puckette is the guy behind Pd and originally part of the team behind Max/MSP, so the similarity is not accidental.)

As for the second runner-up, Reason has a neat user interface that imitates the front and back of a rack full of equipment, complete with a spaghetti of cables connecting components together, and it's very easy to pile-up enough equipment to convince yourself that $500 in software (not counting the computer hardware to run the software) buys you $100,000+ worth of technology at early 1990's capabilities. Nonetheless, it left me feeling like it was very workstation-ish and subtly constrained.

Now I just need some free time to spend on some compositions...

Ismael pinged me today with an email that he sent to the Apache Incubator list:

[...] Our company [Intalio] would be interested in participating to the Ode project through a donation of the PXE BPEL 2.0 engine and the dedication of development resources to the project. [...]

There is already the Agila BPM project under incubation, and there was recently the contribution of a BPEL4WS 1.1 implementation by Sybase. It's my opinion that adding PXE to the mix should actually help clear things up and shorten the time to market for the combined effort — PXE is a complete implementation of the WS-BPEL 2.0 standard with a great team behind it, and it will round out the set of ideas and concepts that the Twister/Agila and Sybase codebases embody. Bill Flood, who represents Sybase on the OASIS BPEL committee, put it in perspective succinctly:

It's all good news for the community at large!