eStuff, iThings...

In the '90s, it was eStuff. eBooks, eMachines, eBay, "E" was the little letter to stick on your brand. Then, it was on to the next vowel.

In the '00s, it was iThings. iPods, iMacs, iPhones... Heck, the world's best-selling video game console is nothing more than a "W" with two little "i"s tacked on.

I've got the next one. Vowels are on the way out. I mean, who wants to be seen in public with an oFace or look up their contacts on a uWho? Obviously, the next big trend in naming is ...

π (yes, "pi".)

I've already begun work on the πPod, which obviously will be used to play MP3.14159 files. (You may have already read about that compression algorithm.)

Vacuum

Two quick ideas for vacuum cleaners.
<accent type="british">Ones that work properly.</accent>

Cordless Upright Vacuum
This one, I could build. I'm tempted to. Get me an off-the-shelf energy-star vacuum cleaner, a home office uninterruptible power supply, some warranty-voiding tools, a few yards of duct tape, and an afternoon, and I'll give you a vacuum that doesn't try to trip you dozens of times with its big stupid clumsy power cord while you use it. Actually I won't give it to you, I'll keep it. Even if it kind of sucks.
(...Did a quick Google search... no, not a little pretend vacuum, not a dustbuster, a real friggin' cordless vacuum. I don't care if it's heavy. I'm as strong as I am clumsy. Lose the wire.)

Spot RoomBot
We don't have a roomba, but the idea is appealing. We do, however, have a spotbot, and it is worth its weight in gold because it cleans up after our runt of a cat, who can't eat anything other than one kind of prescription food, but does anyway. A spotbot which could seek out the next area of barfplops and tailsmears would be worth its weight in ... something else super-valuable.
...This one's quite a bit harder. It would need to be able to refuel itself with water and detergent (and dump out the cat-barf-tainted water) as well as deal with taller solid masses in addition to spill-type floor-level stains. Sign me up for version 2.0 of this one; working out the kinks in this design would be more gross than my current techniques.

Prior Art

One of the memes buzzing around the hippie geek community lately is a way to stick it to those greedy corporations who think they can own math and such, and who bully everybody with patent infringement lawsuit threats and backroom licensing agreements. How? By brain-dumping ideas publicly. If proof exists of prior art or even that an idea has been published, a patent on it can be struck down.

I don't have any brilliant ideas, but i have some mundane ones that are much more clever than half the crap that gets awarded patents these days. So here they are, at least the ones I can remember off the top of my head, and if any greedy corporation is reading, go ahead and make these things happen, but you can't have patents on 'em. Not for long anyway. They're braindead ideas, documented here as prior art.

Video Projector With Smart Auto-Adjust
Implementation 1: Infrared beacons or reflective tape is built-in or can be attached to all 4 corners of any reflective screen, a small infrared camera in the projector (much like the one in a Wii controller) detects the positions of the screen corners, and software distorts and adjusts the projected image to be the correct shape and size.
Implementation 2: No beacons, but a small camera built into the projector feeds data to software that scans for a big, bright, 4-sided polygon, and adjusts the projected image. Probably the better implementation for most cases. A single unit could be capable of using both methods.

Product Placement in Photo/Video/Art Sharing Sites
My friend's Flickr account contains a photo of someone clearly holding a branded pop can. He deserves ad revenue-per-view as much as advertising agencies do. Better yet, pay individuals for stuff like this and stop polluting broadcast and print media with loud and obnoxious ads.

Non-Fling Fingernail Clipper
The otherwise-standard clipper has a soft, spongy clamp behind the blades, which holds a clipped nail until released, rather than ejecting it at a random, high-velocity trajectory.

Pi Compression
(see earlier post)

AI-Engineered Codecs
(see earlier post)

Does Not Compute

I grew up with an Apple IIe. Six expansion slots, color graphics, dual 5.25" floppy drives, but most importantly, BASIC in firmware. I was writing programs before I even really understood what that meant. To use the computer was to program it, and I couldn't have been happier. Sure, pre-compiled programs like Print Shop and Mario Bros were fun, but making my own stuff, that's what I liked best. That's where the magic was.

I was really, really lucky. I grew up at just the right time. To own a computer was to be a computer enthusiast. It wasn't a means to an end; the point of having the thing was to mess around with it. It could certainly be used to do useful work, but it was every bit as common (and easy) to use it as a toy.

(Begin hearing the "old man" voice in your head at this point.)

Modern computing does not compute! Computers nowadays don't come with any (programming language) interpreters built into ROM. Or pre-installed on their hard disks, as might be more appropriate. The closest you can come to writing programs out-of-the-box today is to use a featureless text editor to write some javascript and run it in a web browser.

<script type="text/javascript">
alert("Hello World, this sucks!");
</script>

Now, the way I learned to be a programmer isn't the only right way. But doing BASIC, being taught C, and picking up on everything else was a pretty fun and natural progression. There are entire college computer science tracks now that don't teach C at all anymore, instead using Java or something. It's not bad to learn Java, but I would argue that learning C is more important, if what you care about is computer science. If you care about crafting cookie-cutter corporate apps quickly, Java's where it's at. But if you care about what's going on, or if you like the idea of a computer as a toy, C is really important. The rub is that it's an awful language to write your first program in. My brain, anyway, wasn't ready for it until I'd done something simpler first.

That's where BASIC came in, and where something like Python could come in today. A person's first program shouldn't be graphical. It shouldn't be run in a web browser. It would be nice if it didn't have to import any libraries. And it would be great if there was a realtime interpreter console, something to try out commands and code chunks before saving them in a file. Apple's flavour of BASIC did all of that, and Python does too.

Python is free in all senses of the word, and runs on any platform. The only problem is, it's not just waiting there on any computer one might buy. Before you can do anything with it, you must learn of its existence, find it, download it, and install it. To me, that's tragic. That's depriving little 5-year-old me's all over the world of something really special. It would be trivial to include in any desktop operating system, and could be presented much more nicely than BASIC was back in the day. In the Start menu, or the Apple menu, or on the desktop, or at whatever handy spot user consults regularly, there ought to be a "Create Programs" menu/folder/whatever. It should contain an interpreter, a decent text editor, a language reference, and a quick start guide to explain what those other things are and how to use them. Why isn't this done?

I understand there's not much consumer demand for this kind of thing. Joe Schmoe wants to buy a computer in order to click around on web pages and print term papers, not as a toy to write his own programs for. But I think that could change, if it was widely understood that software can be made by individual people in a matter of minutes. Sure, it won't be the same as software that comes from big corporations on 18-month release cycles, but why does that matter? MySpace pages, YouTube videos, and blogs, aren't the same as designer-comissioned websites, Hollywood films, and professional journalism. It doesn't matter. Joe Schmoe cares about that stuff anyway.

Microsoft, Apple, Dell, HP, somebody... Put Python on the desktop! Add a notice that you don't provide Python support, with a link to python.org, and you can forget all about it. It wouldn't even have to be Python, that's just my opinion of a good introductory programming language. But for cripe's sake, make it happen! There should be a way to be introduced to programming on every computer out there. The fact that there isn't, just doesn't make sense. It's illogical. It doesn't add up. ... Oh, surely there's a phrase that explains the situation.

Unanger

I haven't been a faithful viewer of the Daily Show with Jon Stewart or its younger sibling The Colbert Report, but every once in a while I'll catch something on one of them that really hits home. Mixing political news with comedy is really healthy, I think, and certainly has made the news easier to stomach on those particularly groan-worthy days.

The other day, Stewart had on a guest author, Mike Huckabee, and his book "From Hope to Higher Ground: 12 Stops to Restoring America's Greatness". If I may paraphrase / butcher his own words, Huckabee is "conservative, but not angry about it". He talked about how our elected officials often get distracted with politics and power at the expense of practical matters, and in so doing are failing at their duties to help their people and their homeland. His passing comment about being conservative but not angry about it was a good light-bulb moment for me.

Politically, I would label myself progressive, if I were to pick one label, and as often as not during the last several years, I've been pretty angry about it. Looking at things practically is much more effective, though, and would let me have less heated and more fruitful arguments.

A good example might be my beef with the restrictions on stem cell research. We could argue about when life begins and the ethics of using of embryonic cells until we're blue in the face, but the reasons I think the research should be given some liberty are actually entirely practical. My wife is type-1 diabetic, and I want us to grow old together. I know and have known several cancer patients. I'm fully aware that stem cell research is no guaranteed silver bullet for magically healing these people, but I think that their lives are worth a great deal of effort in trying to save. We owe it to ourselves and to each other not to dismiss or over-restrict science with this much potential. Now, I have no doubt that practical arguments can be made against my position as well, but I'd rather discuss and weigh those than political and religious arguments; all those seem to accomplish is to stir up anger.

In any case, I have a late New Year's resolution, and that is to be less angry where I could instead be practical. Here's hoping a few politicians give the idea a try, too.

Chow Anecdote

I wouldn't even bother posting this, except that it involves cheese. All which involves cheese is worth speaking of.

It came to me in a dream: I was making some broccoli cheese soup, and added too much milk by mistake. Milk is of course a good thing, but too much of it screws up the viscosity of the soup; I like it good 'n thick. So, unconscious problem solving prompted my imagined self to add some flour. That thickens stuff up, right? Not bad for dream-logic.

So the next time I made broccoli cheese soup in waking life, sure enough I added more milk than I'd intended. Applying the well-worn scientific principle, "oh-what-the-hell", I mixed in one of those little fancy measuring spoon's worth of flour.

Worked like a dream.

Pi compression

This idea I've had for a long time, and if it were mathematically and computationally feasable, it would probably have already been done. But never mind all that. I still like the idea, and I'm still going to spout it off.

I chose pi because I just like it, but e or any of those other fun infinite-digit, non-repeating numbers would probably work, and possibly be better. An unfathomably good pseudo-random number generator might even work. But let's call it pi for now, because the important thing is that it's this infinite sequence in which, theoretically, every possible sub-sequence exists. Somewhere in that infinitely-long series of digits, there'll be a hundred sequential zeros. Somewhere, there'll be a million. And somewhere, there'll be a sequence that matches the sequence of ASCII values for this blog entry, and every other text you've ever read (and ever will read... but that's a different story).

The idea is, whatever data you have, your term paper, that movie you swear you didn't download, or that log of leaked AOL searches, that data is already encoded somewhere in Pi. It may be several centillion digits out, but it's there. Theoretically, you just need to let a grep algorithm slide along Pi until it finds a match, and then just remember the offset and the length to get it back out. Suddenly all files, all volumes, all anything, can be represented by two numbers.

Parts of this have already been implemented, though on a scale much too small to be useful. (Four billion binary digits of Pi? Pff, weak sauce.)
Finding sequences in pi:
http://pi.nersc.gov/
Getting hex digits (half-bytes) out of pi:
http://www.geocities.com/hjsmithh/Pi/PiQPCpp.html

Our CPUs' abilities to crunch numbers aren't advancing as fast as our networks' abilities to pump big bunches of data around, so this whole thing isn't terribly practical. Still, you could back up your whole hard drive on a floppy diskette. The idea is fun even if it wouldn't be worth doing.

Let's take it a little further, though. Maybe we can still do something useful with those first four billion binary digits. Play around with that Pi-search link above. It only uses a 5-bit character set rather than ASCII's 8, but let's experiment anyway. I'm going to search for "penduin".
In 5-bit-per-character binary, that's:
10000001010111000100101010100101110The sequence is found at 8748556 binary digits in. 8748556 in binary is:
100001010111111000001100
...that's a noticably smaller sequence than the binary representation of "penduin". Our data is 7 "bytes" long, which in binary is:
111
Those two numbers, the offset and length, happen to take fewer bits to represent than the string "penduin", in ascii or even in 5-bit characters. Houston, we have compression! But hang on, let's say that sequence didn't happen within 4 billion bits of pi (according to that site, an arbitrary 7-character sequence has just an 11% chance of being found that early). We could still find "pend" and "uin", though - the odds of finding three or four letters are essentially 100%. If we do that, though, we'd need more bits than the raw ascii just to keep the two offset/length pairs, let alone any padding we'd need for any sanely-packed descriptor.

That packed descriptor would be 35 bits per chunk: 32 bits (maximum value: 4,294,967,295) for offset, and 3 bits for length. Why 3? We're unlikely to find an arbitrary 8-letter pattern (8 is 4 digits, 1000 in binary) in just the first 4 billion bits of pi, so our algorithm won't even try. So every 35 bits in our "compressed" file points to the next up-to-7-letter chunk of our data. On a good day, that'll beat ASCII, which would take 56 bits to store 7 letters. But, we're still playing with 5-bit characters, a paltry subset of ASCII. We're also playing with odds where only 11% of our chunks will be able to point to the maximum 7 characters.

Looking at hex digits instead of 5-bit letters gives us a better picture of how useful this might be. Any byte (8 bits) can be expressed in 2 hex digits. Any four sequential bytes has about a 60% chance of being found in these first four billion bits of pi, and sequences of three and a half (7 hex digits) are pretty much guaranteed. 7 was the maximum length of our chunks from before anyway, so let's keep using that. So, to recap:
With our 35 bits descriptor, we can know where in pi to find up to three and a half bytes, or 28 bits, of data.
...
As far as compression algorithms go, that doesn't seem particularly good. :^) But we're chopping into 3.5-byte pieces or less because of the near statistical certainty of finding any 3.5 bytes in the first half-gigabyte of pi (four billion bits). Give us twice as many digits of pi, and we'd only need one more address bit, plus another bit or so for length, as longer patterns would have improved odds of being found. Keep bumping up the searchable pi digits and we could eventually hit a sweet spot beyond which we'd actually be able save disk space. Once that happens, we can keep on increasing the available pi digits to achieve better compression, but more interestingly, we can add another layer of logic in which we take our packed bits, chunk them up, and look for those sequences in pi. If we're going to do that, we need to pack an extra bit for each chunk to say either "I point to data" or "I point to a pointer", but if we've got so many pi digits to search that we're actually saving space every time, we can still wind up with simply a pi digit offset and size, which would lead to a lot more lookups, and eventually, chunk by chunk, the data we care about.
A tip of the hat to the first person to find this post within pi. It's there! Extra points if you also find my next post before I post it. :^)

edit from much much later:
I'm glad people keep finding this post and having fun with the idea!  I'm sorry to have gotten anybody's hopes up, but this is one of those fun ideas that is impossible in practice.  (Well it's possible, it just can't achieve any data compression.  :^)  See the comments below, including my own, for reasons this doesn't and can't work.

Lemma

lem-ma [lem-uh]
noun; a situation requiring a choice between desirable alternatives.
antonyms: dilemma.

AI-engineered codecs?

Someone else has probably had this idea, and someone else has probably explained it better than I'll be able to. Someone else yet has probably proved that the whole thing's implausible. Nuts to them; I have a fleeting thought and I'm going to publish it! :^)

I'm not very well-versed in either genetic algorithms or neural networks, but neither are those just buzzwords to me - I have written genetic and neural equivalents of "Hello world". The techniques differ, and stacking layers of these algorithms has different effects, but the thing that makes them interesting (to me, at the moment) is that we wind up with a computational system without the programmer having to actually solve the problem. A typical neural network will take a piece of input (say, a scanned image of a paper) and produce some output (say, a set of bounding box coordinates of each interpreted dark blob on the image). These outputs may then be the input of another neural net which produces some more output (say, ASCII characters interpreted given those dark blobs) and/or a non-neural algorithm that just looks for patterns (say, a spellchecker). Writing an actual algorithm to turn an image of a paper into a text stream would be massively hard, but writing and training some neural nets is much less painful. Let the computer do the computing.

In the world of Free software (free as in liberty), a world in which I happily live, there are some struggles happening around various proprietary formats. A while back, Unisys declared to the world that they owned math and thus we all had to pay royalties if we wanted to use .gif files. That particular software patent has since expired, but nowadays there are companies convinced that they own the math necessary to encode and decode MP3's and such, and even worse, there are widely-used formats like Apple's "Sorensen" QuickTime and Microsoft's Windows Media for which no Free codecs exist. There's not much motivation for someone to hack such things up, either, as they'd be sued into oblivion the moment their code became useful. God bless the US, eh?

Forget reverse-engineering, forget exploiting the closed code, and especially forget paying big corporations royalties for the privilege of doing math. I propose that it might be possible and worthwhile to write some AI to figure out these pesky formats for us. We have input, say a QuickTime .mov file, and we have the desired output. (Scrape all the raw bitmap image data and all the output audio. It'll be huge, but that's our target.) I don't know what sort of scale, how many layers, or what ghastly amounts of memory and floating-point muscle it would take to set up and train a neural net to get from point A.mov to point B.raw for any given movie, but I doubt it's impossible. Flip the input and output to train an encoder. Not too shabby!

I know even less about genetic algorithms than I do neural nets, but maybe they are better equipped to solve the problem. Plenty of other AI techniques are out there too; perhaps some combination of them would be the optimal approach. The idea is to have a program reinvent codec wheels for us, since others won't share their wheel understanding.

Shackles begone! One way or another, we need to get to the point where the format is irrelevant, only the data matters.