Saturday, August 14, 2010

We All Deal Feet

We went to Ideal Feet today. As you may know, Shelly has been plagued with foot and back pain for years. I heard Ideal Feet's commercials on 740 KTRH (which, I have to say, is not the best place to find things to try) and I thought it would be worth looking into.

The first thing to say about them is we do not like the way they do business. Most notably (and you'll find this complaint if you web search) is that they have no money-back guarantee. No refunds. Their policy on this is
"Since our products are personal items we do not offer refunds. But should you have any difficulty wearing the supports we will adjust them for FREE!"
What? I should point out that an "adjustment" means you bring them back and they re-measure and give you a different size. And you can do that at any time, as often as needed. The point being, they don't mind taking them back, they just don't want to give you your money back over your dissatisfaction. So it might help to think of this as a service contract, and not merely paying $400 for a couple of pairs of insoles.

On to our experience: we were helped by Brandon, who is a nice guy, and when he's not in the process of delivering the company-mandated spiel, seemed to be inclined to be honest with us. He is a salesman, and was up-front about having no medical expertise.

The spiel, on the other hand, is unadulterated hucksterism. It consists of mentioning "aligning 26 bones and 33 joints" any number of times; a "balance test" that doesn't test balance, but purports to show that the insoles provide stability (but is really just a bit of trickery worthy of the Church of Scientology); and taking impressions of your foot without and with the insoles to show how the pressure distribution changes, which is the most honest (and relevant) bit.

Then came the fitting. He measured Shelly's feet— the significant measurement being the arch length— and took "2 seconds" (yes, part of the script) to go to the back and pick out the insoles for her. Shelly asked whether this was a one-size-fits all solution, and he said that, no, there are some 40+ sizes back there, very precisely sized by arch length (not arch height). As your feet adapt, your arch length can change, and you would then need to come in for a re-fit (i.e., exchange them for a different size).

The insoles are noticeable: there's a big lump right under the middle of your arch, which requires you to gradually work up to wearing them for extended periods. Shelly required that I go through the fitting, as well. I actually like the main insoles; the secondary ones (that you wear when you're not wearing your primary ones, to keep your feet from reverting) I did not like.

In the end, in spite of all the red flags, we got a set for Shelly. Desperation makes you try things that you would otherwise consider stupid. Maybe the company is counting on that. There is a chance that this is a worthwhile product, and that the company is just horrible about how they do their marketing.

We'll let you know. So in the meantime, feel free to go in for a fitting. Enjoy the spiel. But don't buy anything. Tell them you're waiting to hear how they work out for us.

Thursday, August 5, 2010

A little JavaScript™ Invention

One deficiency in JavaScript™ is that it has no sleep command. Instead, it has a setTimeout function, which works differently: you tell it what you want to run, and how long you want it to be before it starts, and that acts like a little time bomb in the background while your program continues on. It doesn't pause. So if you want it to actually pause, you need to pass the entire rest of your program in.

That sounds crazy, and it kind of is. But JavaScript™ (I'm writing it that way because it really is a trademarked name) is for web apps, where you don't really run a whole program. What you're usually writing is callbacks for widgets. It's a callback-oriented language.

So today, I had the need to put a pause in a series of requests I was making, so that they wouldn't all happen at once. How to do that as I'm looping through the array? Tail-recursion, of course— that's how you loop in a functional language. I came up with a function that works like the forEach method, only it has a specified pause before invoking the callback:

          // Like forEach, but with a delay
function delayForEach (queue, callback, delay) {
var qIdx = 0;
// recursive block
(function () {
if (qIdx < queue.length) {
callback(queue[qIdx], qIdx);
++qIdx;
setTimeout(arguments.callee, delay);
}
})();
}

It's just a little thing, but I thought it was nicely elegant. It should be noted that this call will all run "in the background": if you call delayForEach on some array, your program will continue on, and the looping will be done as if it were running independently. Still, could be useful for somebody.

Upon reflecting a bit, it seems to me that it might be more appealing to use setInterval instead.

         function delayForEach (queue, callback, delay) {
var qIdx = 0,
interval = setInterval(function () {
if (qIdx < queue.length) {
callback(queue[qIdx], qIdx);
++qIdx;
}
else {
clearInterval(interval);
}
})();
}

Wednesday, August 4, 2010

Deriving the Y Combinator

The Y-Combinator Derived

The Y-Combinator was something that came up in my Programming Languages class at Rice. It was bizarre and inscrutable to me, and I never really acquired a deep understanding of it. Frankly, it doesn't have a lot of practical application, but it is interesting. And Douglas Crockford said something like, "If you understand this, you can call yourself a computer scientist." Well, I certainly want to be able to do that. And maybe this post will create a few more computer scientists. I hope so.

First, I want to note that I depended heavily on this page for my derivation steps. I changed them as I saw fit, but it was nice to have them to refer to when I screwed up.

My intent is to derive the Y-Combinator in a way that makes it obvious what's going on. This subject has been done quite a few times (and in quite a few languages), but they always use meaningless function and variable names, and I find that makes it hard to follow. So I'm taking my stab at it. I've been writing in JavaScript lately, so that's what I'm using here.

The first step on that road is to understand what we're deriving. The Y-Combinator is a function that provides "anonymous recursion". That is, if your language doesn't provide a way for a function to call itself while it is being defined, the Y-Combinator can give you that.

Specifically, let's say you have a function that you can tell how to call itself, and then it can be recursive:

function factorial (myself, n) {
return n <= 2 ? n : n * myself(myself, n - 1);
}

What you want, though, is a function that doesn't have to tell itself how to call itself every time.

// This doesn't work. We need "myself" to be defined somehow
function factorial_wish (n) {
return n <= 2 ? n : n * myself(n - 1);
};

The first step is to "curry" myself out of the original function:

function curried_function (curried_self) {
return function factorial (n) {
return n <= 2 ? n : n * curried_self(curried_self)(n - 1);
}
}

With this, curried_function(curried_function) returns the factorial function you want, which you can then call with a single argument, and it will work:

var working_factorial = curried_function(curried_function);
working_factorial(5) // returns 120

But what we really want is for the factorial function to reference itself, and not the curried outer function, so that it would be written more like factorial_wish above.

We do that by wrapping a function around it that will define myself for it, and will take care of calling curried_self with itself.

function curried_v2 (curried_self) {
return function factorial (userArgument) {
var inner = function(myself) {
return function(n) {
return n <= 2 ? n : n * myself(n - 1);;
};
};
var myfact = inner(curried_self(curried_self));
return myfact(userArgument);
};
};

Now the innermost function is in the form we want; the function that wraps it, inner, defines its myself for us. The function that wraps that is our new factorial function, which will be what we pass an argument to, and which takes care of the curried mess.

The use of the variables is not strictly necessary here, but it helps make clear what's going on. In programming, it is often a bad practice to combine multiple operations into one monolithic, incomprehensible statement. But in math, it is called "reducing", and it's good. And the Y-Combinator comes from math called Lambda Calculus. We're just trying to understand it in terms of programming.

The calling of this hasn't improved. You still have to call it with itself to get your factorial function out:

var working_factorial = curried_v2(curried_v2);
working_factorial(5)

What has improved is that the inner function is independent of the stuff it's wrapped in, so it can be pulled out, and you'll note that it looks exactly like the factorial_wish function from earlier, wrapped in a function that takes a myself. So what remains is (almost) the goop we're looking for.

var inner = function(myself) {
return function(n) {
return n <= 2 ? n : n * myself(n - 1);
};
};

function curried_v2a (curried_self) {
return function factorial (userArgument) {
// inner was here, and is still needed
var myfact = inner(curried_self(curried_self));
return myfact(userArgument);
};
};

So the next thing to do is to pass inner to our function, so it's not hard-wired to look at some global(ish) variable. We'll do this by (of course!) wrapping it in yet another function layer, where we can do the double call, as well:

function basically_Y (inner) {
function curried_v2a (curried_self) {
return function (userArgument) { // not necessarily factorial, any more
var myfact = inner(curried_self(curried_self));
return myfact(userArgument);
};
};
return curried_v2a(curried_v2a);
}

To use this, we pass in the inner function we previously extracted (or any function that is built like it), and we will get back a well-behaved recursive function that knows how to call itself.

var myfact = basically_Y(inner); // using the inner defined earlier
myfact(5)

All that's really left is generalizing it to handle more than one userArgument.

function Y (inner) {
function curried_v2a (curried_self) {
return function (/* any number of user arguments */) {
// .apply(null, arguments) is how you pass along all arguments
return inner(curried_self(curried_self)).apply(null, arguments);
};
};
return curried_v2a(curried_v2a);
}

I went ahead and substituted in for myfact, since it's not all that complex, (not to mention that this is no longer just about factorials) but I have retained the variable that is curried_v2a.

To get to the no-variables form, we do a little re-writing: Instead of defining curried_v2a, we create a function that takes it as a parameter, and then pass its definition to that function. The function does the calling-it-on-itself part, and we're done!

function Y (inner) {
return function(curried_v2a) {
return curried_v2a(curried_v2a);
}(function(curried_self) {
return function() {
return inner(curried_self(curried_self)).apply(null, arguments);
};
});
}

It's still incomprehensible, but if you've been through the derivation, the parameter names might jog your memory about what's what.