typodupeerror
DEAL: For \$25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

## JournalJournal: Hydraulic Hybrid Notes

I've commented multiple times about hydraulic hybrids. I like them, relative to electric hybrids, because they have a very high power density. I like the acceleration that power brings. And 1,000 charge/discharge cycles is hard on batteries but pretty much a normal day for hydraulics.

The amount of energy stored in a hydraulic accumulator is based on the volume and the square of the pressure. Ergo, a 5k psi system has (5/3)^2, or approx. 2.7x, the energy content of a similar volume accumulator running at 3k psi. So, higher pressures should be embraced, as much as possible.

Power is the combination of pressure and fluid flow. If you're going to have a vehicle powered by hydraulics (as Karl and I had discussed, oh so long ago), you want maximum pressure and minimum flow (in much the same way that an electric vehicle tends to be more efficient if you use high voltage and minimal current). This means that, if you're going to have hydraulic accumulators buffering the surges in input/output, you probably want to keep the power train running at, say, 5k psi and have something resembling a Constant Speed Drive (in this case, a Constant Pressure Drive) modulating the accumulators' pressure up to/down from the system pressure. That way, the accumulators can vary in pressure up/down the scale. Since kinetic energy goes up with the square of speed and stored energy goes up with the square of pressure, a simple pressure gauge on the accumulators would give some idea of relative max speed achievable with current stored energy before the vehicle devolves into "gutless wonder" mode.

A device which would work well for the Constant Pressure Drive is known as a "hydristor," which is supposed to be a portmanteau of "hydraulic" and "transistor." It's a twin-chamber, variable geometry, vane-type hydraulic pump/motor. You can have hydraulic fluid of one pressure driving motor-style in one chamber and hydraulic fluid of a different pressure driven pump-style in the other chamber. Ergo, 5 gpm at 500 psi (from the accumulators) can produce approximately 1/2 gpm at 5k psi (not 100% efficient, but rumored to be pretty close). You can use the shaft in the middle of the whole thing as a mechanical power input/output or you can just do hydraulic power conversion and ignore the shaft. Unfortunately, the guy holding the patent on that has died and his patents are kinda up-in-the-air, at last check.

As a bare minimum, I'd like a compact vehicle with the transmission pulled and the main hydraulic pump/motor attached to the differential gearing. Use a small gasoline or diesel engine to provide "cruise power," with the engine driving the main hydraulic pump. Let the accumulators/CPD operate as a "L1 power cache" (referenced in one of my earlier Journal entries), so that the engine stays at a pretty steady throttle setting. It would throttle up/down, depending on demands and the current state of the accumulators (heavy demand and rapidly falling accumulator pressure = more throttle, etc.).

Eventually put an electric motor/generator and batteries into the mix. Obviously, electricity from the batteries can turn the electric motor, turning a hydraulic pump to drive the vehicle. Hydraulic pressure from the engine can turn the generator to charge the batteries or pressure from the electric motor can "roll start" the engine when needed. This would allow the batteries to function as a "L2 power cache." Eventually, add enough batteries that your typical daily drive uses no fuel but you still have the option if you need to travel further than usual.

The only remaining questions: how heavy (5k psi system would probably be lighter than 3k, as less fluid is needed) and how expensive?

## JournalJournal: Competition needed1

When you go to fill up your car, you have a choice of where to fill the tank. All too often, all of the gas stations in an area have the same price. Or if one is slightly cheaper than another, there's some other factor that "evens" them out.

Where is the competition? Are these stations fixing the price of gasoline? That's hard to prove. They probably don't have any kind of agreement, formal or otherwise. It's entirely possible that the price they're selling for is the balance point between the best price they can offer (based on what their supplier charges) vs what the market will bear (people tend to drive less when they're broke, or when gasoline is significantly more expensive). The latter case is basic supply and demand, nothing sinister or conspiratorial about it.

If we want to get around for less money, more competition is needed. And that means some other form of energy. Diesel isn't an answer; it uses the same supply chain as gasoline. Ethanol isn't really an answer, either; the companies that supply the gasoline also supply high-ethanol fuels (E85, for example) because there are tax credits to be had for the company that "blends" the gasoline and the ethanol. So ethanol has been effectively co-opted by the same suppliers.

There is where Plug-in Hybrid Electric Vehicles (PHEVs) come into play. Like the Chevy Volt.

If I can charge up my vehicle and drive, say, 45 miles without burning any gasoline, especially if my daily commute is 45 miles or less, electricity has just become a competitor to gasoline.

In my area, electricity is 8.5 cents / kWh. And many of the electric vehicles (Nissan Leaf, Mitsubishi iMIEV, Chevy Volt) get at least 3 miles / kWh. Which means 2.8 cents / mile or less.

At \$3.20 / gallon of gasoline, I'd need 113 mpg to drive around as cheap on gasoline. I'd need about 138 mpg on diesel (\$3.80 / gallon) to match that. I'm lucky if I can find a vehicle which gets half that.

Electricity has another little advantage. If the increase in electricity consumption causes the price of electricity to go up, many of us have the option of acquiring solar panels or small-scale wind or hydroelectric equipment and making some of our own. No, I'm not joking; I live in rural territory. I've lived in rural places where I had a creek running through the property. A small water turbine, running off a creek, can produce a small-but-steady amount of electricity and make a small dent in your electric bill with the right equipment.

You can't make your own gasoline. And while some people have found a way to make their own diesel (biodiesel), it only takes a few people doing that before the supply gets eaten and you end up back where you started. There simply isn't enough waste vegetable oil around to provide fuel for a significant number of people.

In theory, you could make your own ethanol, buy gasoline, blend it to make your own E85 and run a flex-fuel vehicle on that. The only reason ethanol has its current price, though, is through economies of scale and because it is subsidized. As a small-scale producer, you don't have the same economy of scale and there are a LOT of legal headaches to making your own ethanol.

I have nothing but respect for Elon Musk and Tesla Motors. The fact that they're building Supercharger stations, where you can use high voltage and current to add significant mileage in a hurry, means that they understand that there needs to be infrastructure before people can buy their battery-only vehicles. For most people, buying a pure electric vehicle means that they have to have an additional vehicle, for those times when you want to travel beyond the range of your battery pack. Sure, if the battery is enough to do your daily commute, you can charge up at home. But without something like a network of Supercharger stations, you probably can't go "over the river and through the woods to grandmother's house." There just isn't enough of the right kind of infrastructure.

We need more PHEVs. The ability to run on gasoline when you need longer range, or when you forget to plug in and just need to get home, cannot be understated. Sure, you'll still need some gasoline or diesel fuel, occasionally. Until such time as we can ALL make use of Supercharger stations, we need a period of backward compatibility with the existing, fueling infrastructure.

And may the better economic choice win.

## JournalJournal: Truly private email

The problem with modern email systems is that the emails are stored in plaintext. Some systems may use site-wide public/private key encryption but, if a third party gets access to the site's private key, everything is, effectively, plaintext.

So how do we fix this?

Do all encryption/decryption on the client. The client holds the private keys. The server has everyone's public keys. All traffic and stored data is, by default, encrypted.

More specifically:

Messages on this system are more like posts than emails. Responses and the like are other posts. Each post has a unique message ID. If you choose to quote or reference another post, your post would contain a reference to the message ID and what offsets within the message you wish to quote/repeat. Under no circumstances would content be copied from one post to another. The reason for this will become clear in a moment.

You want to create an account on the system. You create a user ID and a public/private key pair. You give the user ID and public key to the system. The private key is kept only on your client system(s).

When you want create a post, you compose it on your client machine, then generate a session key for some shared-key cryptosystem. You encrypt the message with the session key. Then, you send that encrypted data (not the session key) to the system. The system gives you a message ID.

Note: this is how HTTPS works (the actual content is encrypted with a shared-key system, the shared key is encrypted with public keys for transport) and how PGP works (message is encrypted with shared-key system, shared key is encrypted with recipient's public key for security and sender's private key for sender verification).

You then tell the system what user IDs are allowed to view the message. You request (possibly cache) public keys for such people. For each authorized viewer, you encrypt the message's session key with that viewer's public key. You pass the viewer's user ID and the encrypted session key to the server. The system tracks a many-to-many relationship between viewers and messages, with the encrypted session key on the join table.

The data and the session keys are NEVER stored as plaintext. That information is only held on the client system(s).

If someone succeeds in breaking a session key they will gain access to the contents of one, and only one, message. If this message contains a reference to another message they will need to break the (different) session key for THAT message, as well, to see anything in it. This way, you never have ciphertext (an encoded message) and plaintext (decoded data from another message) with which to help break other session keys.

Decoding a session key is unlikely to provide enough information to determine someone's private key. They'd have better luck trying to reverse-engineer it from the public key.

You connect from your client system and tell the server you want to read your email, probably using some kind of public/private key negotiation. The server determines what message IDs you can see. Your client determines whether or not you've seen them (tracking message IDs is ok; most RSS readers do this so that you aren't seeing the same messages over and over again) and downloads the message IDs you choose to see. The server provides you with the public-key-encrypted session key for each message. Your client system has to use the private keys to decode the session keys, allowing you to further decode the messages.

You can see who else can see the message. You don't really know, from that metadata, who wrote it, though. All you can determine is who can see it.

If you have reason to believe that someone's account has been compromised, you can remove that person from the authorized viewers of one or more messages. The system deletes the link between their account and the message, deleting the session key in the process. That way, if someone attempts to use the compromised account info, they'll have access to fewer messages.

It would also be very easy to setup the system so that so-and-so can see this message for 5 days, then the access is auto-deleted. Or you could choose to delete your access to the message. Then, there would be no metadata connecting you to the message, nor any way for the message to become visible if your account was compromised.

Message IDs which have no references to any user IDs would be auto-deleted by the system. That would break any other messages which referred to it. But that's the only way to ensure that one message can't compromise another. The actual information, in one message, which referenced another would be part of the encrypted data, so there would be no way to determine metadata about which messages refer to which.

In this fashion, the system administrators cannot read your mail. Nor can any third party. Even if they have a warrant and/or other court order. They simply don't have any way to access the plaintext. A third party would have to compromise a client system, then use that information to view messages a) that person is allowed to see b) before other people become wise to their being compromised and disconnect that user from their messages

Naturally, this mechanism can also be used to store notes. Post a message which only you can see. Maybe add access for someone else later on.

Gee, I've NEVER emailed myself some information, from a desktop or laptop PC, so that I could access it on my smartphone :-)

If the system can encrypt arbitrary bit-streams of great length, you could use this as a secure data locker. Store pictures, music, videos, whatever. Only give someone else access if you wish. Revoke that access if you wish. Revoke your own access to something shared by someone else. The people managing the system have no mechanism to see what you have stored.

I've NEVER emailed myself a file as a transfer mechanism from one machine to another :-).

## JournalJournal: Graphical SQL query builder

There has been significant talk, as of late, about how to to do programming using a graphical interface, instead of the usual text-based ones. A previous entry into this journal talked about that. It's time to start nailing down some more concrete ideas about this.

First off, I tend to think of anything involving aggregates (and yes, SQL queries are operations across an aggregate of records/objects/tuples/whatever) as map-reduce operations. You create a function which will filter/transform each tuple individually (map) and you may do something across the resulting set to reduce the total number of tuples. Selecting a subset of fields from a tuple is a map operation. Selecting a subset of tuples from the total set is a reduce operation. As such, you can think of a SQL query as one or more map-reduce operations. For example:

select f1, f2, f3 from t1 where f1 = 'blah' and f2 = 1

We do map across tuples from set t1, emitting only fields f1, f2 and f3. We do a reduce across the records such that we only emit records where f1 = 'blah' and f2 = 1. In principle, the output of map -> reduce will be the same as the output of reduce -> map. In reality, we may want to do the reduce(s) first, emitting only the primary key values from t1 where the fields meet the criteria, then do the map across the fields for tuples with the appropriate primary keys. The 'where' clause can be broken into two pieces (f1 = 'blah'; f2 = 1) with the output of one feeding the input of another. As such, we would have a reduce (f2 =1; comparing numbers goes faster than comparing strings) feeding into another reduce (f1 = 'blah') feeding into a map. The reduce operations can run in parallel (functional partitioning) and the map operation can be run in parallel (data partitioning), feeding into an implicit reduce operation which puts all of the parallel-generated output results into some single stream. Many databases already do this behind the scenes when they build a query plan, using various internally-tracked statistics to determine which comparisons should be done first, using a knowledge of which fields are indexed and which aren't, to optimize the performance of the query. And if you run the same query twice, with slightly different values, the second query will usually run much faster because the database is able to leverage the already-built query plan.

So, how do we represent this, visually?

We can start with the tree-based structure mentioned in my previous journal article. But that limits you to a particular sequence of events. I'd like something a little more abstract. I'd like the system to be able to optimize the query.

Represent each table/tupleset as a circle. There are lines radiating off this circle, representing fields/attributes in each tuple in the set. You can connect one or more lines from one circle to one or more lines on another such circle, indicating a join. We would need some kind of graphical representation indicating inner/outer join. Fields which are indexed should be easily recognizable. Field(s), singular or composite, which comprise the Primary Key should also be easily recognizable.

You wrap another polygon around that, with a line reaching the edge of the polygon. This polygon represents a filter/reduce/where clause. You would have to put something on the edge of that polygon representing the limiting criterion. Need multiple criteria, such as an 'and' statement? Add another such polygon around that one, pulling a field out to this polygon and specifying criteria for this field. Each criterion polygon is an implicit 'or' statement; you can have multiple criteria for a single field. Multiple concentric filter polygons can be merged into one, thicker filter polygon, hiding the overall filtering criteria. Or a thick one could be 'exploded' back into multiple, single-field-criteria polygons with one dragged inside or outside another, if you really want to mess with the order in which they're done.

What fields come out of this query? Find the lines representing the values on the initial tupleset circles and pull them through all the polygons, such that they radiate outwards. These can, then, be connected to other tuplesets, filtered or otherwise.

You can do a filter around the result of a join. But, if the filter is only applied to one field from one tupleset within that join, the filter can be 'shrunk' down to surround that tupleset, with the join happening after the filtering. And, realistically, this what the database will probably do, internally, so as to reduce the number of tuples which need to be joined.

We would also need another polygon representing modifications to the fields. For example, if you need a case...when statement, that would be another polygon which filters the values. One or more lines from the tupleset would hit the polygon and one line would come out. An aggregate statement, such as a sum() or count() would also have a polygon. And one polygon can be pulled inside or outside another to indicate what order (inside -> outside) the various modifications can be applied. Naturally, if an aggregate depends on the output of a modification, the modification will have to remain inside the aggregate. Or they can all be squashed into one, thick polygon, to hide the actual representation of what's going on and make it easy to use the output of this within a larger query.

What about insert, update or delete statements? Many of those involve queries to extract values which will be inserted or updated, or they use queries to determine which fields get modified or deleted. So a query is still the basic building block of all of those.

And, of course, as with any touch-based application, you can zoom in/out to show/hide the details.

So, what's the deal with each filtering polygon only filtering on one field? And one modifying polygon only producing one output? That's where factoring comes into play. If you end up with multiple criteria which all do the same modification or all do the same filter, it may be possible to pull those 'components' out and create a view. Then your queries can filter from that view. It would be relatively straightforward to spot when this is possible and it would be relatively easy for the editor to allow you to select the tupleset(s), possibly joined, the modifications and the filters and refactor everything. Anyone who's done significant work with a database knows that a querying a view will, quite often, provide a performance improvement over querying raw tables. Few and far between, however, are the people who are able to spot these refactoring opportunities, looking at raw SQL code.

Finally, this format isn't limited to SQL. If you put a filter on a field which does a regular expression match, but the database you are targeting can't do a regular expression match, that would indicate that some of the work for this query will need to be done programmatically, outside of the SQL query. And, if you are targeting a NoSQL database or an XML-based object store, the querying can be turned into XPath/XQuery and the modifications can be turned into XSL. In this fashion, this could provide a powerful tool not just for visualizing, but also for code generation.

Naturally, it should be able to parse existing SQL queries and, if possible, XPath/XQuery/XSL and create the visual representation. In this fashion, it would extremely useful for maintaining existing codebases. Couple that with the ability to generate code, possibly different from the input languages, and you have a powerful tool for migrating from, say, SQL-based relational databases/tables to NoSQL or XML object stores.

## JournalJournal: Conversion slide rules

I mention, in a previous journal entry, the fact that I want a wristwatch with a slide rule bezel. We do a lot of traveling, frequently to places where they use Metric, instead of the Imperial units with which I'm familiar. I have also traveled to places which had significantly different currencies. When I was in Norway, it was approx. 6.5 NOK = 1 USD. When I was in South Korea, it was about 800 SKW = 1 USD. When we went to Chile, it was about CLP 500 = 1 USD. Slide rules are very good at multiplication, which is all you really need to do to convert between currencies and between measurement systems.

In the absence of such a wristwatch, it might be helpful to print a set of concentric, circular slide rules on a piece of paper or cardstock and take that with me. I anticipate the following, on one side of the paper/card stock:
1. miles
2. meters/km
3. feet and pounds
4. grams/kg
5. ounces

Naturally, because kilometers, meters and centimeters all vary exactly by orders of magnitude, you could convert miles to meters or kilometers, just as easily. And you could convert feet to meters or centimeters, just as easily. The 1 or 10 mile mark would be around the 16 meter mark (1609 meters / mile). The 1 or 10 meter mark would be around the 30.5 foot (and pound) mark (30.48 feet / meter). The 2.2 or 22 pound (or foot) mark would be around 1 or 10 gram/kg mark (2.2 pounds / kg). The 28 gram/kg mark would be around the 1 or 10 ounce mark (1 ounce = 28.35 grams).

That would be a total of 5 concentric, circular slide rule scales. That's about as much as you could hope to put on one side of a piece of paper without getting too confusing.

They should probably be color-coded. Let's assume that those five scales were printed in:

1. red
2. green
3. blue
4. purple
5. black

(outermost to innermost).

• red -> green = miles -> meters/km
• green -> blue = meters/km -> feet
• blue -> purple = pounds -> grams/kg
• purple -> black = grams/kg -> ounces

Five scales, four useful conversions.

For the other side, starting from the outer-most scale and working in, I'd do:

1. gallons
2. liters and local currency
3. US Dollars

As such, this would need to be reprinted anytime I was going to a different country. The reason for this progression is simple. I need to be able to convert between liters and gallons. I also need to be able to convert between currencies. The three scales, in this order, would also allow me to convert local currency / liter -> local currency / gallon -> US Dollars / gallon. So, three scales, a total of three useful conversions.

When you determine where you're going, find the exchange rate and print these sets of scales on opposite sides of a piece of paper or card stock. Trim off the excess and throw the result in your bags. Then, when you get there, you have everything you need to convert between measurements and currencies, as well as do a more complicated conversion (USD / gallon to whatever / liter, and vice versa).

If you wanted to make a more permanent "device," you could make a double-sided circular slide rule. All of the scales on one side (length and weight) would be fixed. Only the inner-most scale on the other side (currency conversion) would need the ability to move. Someone with a laser cutter/engraver could probably fabricate the pieces, pretty easily.

## JournalJournal: Ideal wristwatch

Lately, I've come to the conclusion that I'd like a wristwatch with a slide rule bezel. I've spent plenty of time playing with slide rules so I'm pretty proficient with their use. Having one on my wrist would be nice.

I've spent time, at various department stores and jewelry stores, explaining to sales clerks what they're good for. Travelling in a foreign land? With a foreign currency? Set the slide rule to the currency exchange value and quickly convert prices between currencies. Simply find the "local" price on one scale and see the other price on the other scale. Are they using metric? And you'd like quantities, distances, etc. in imperial units? Or vice versa? Set the slide rule for the appropriate conversion factor and you're good. If you know what you're doing, you can even do more complicated conversions, like Chilean Pesos / liter to US Dollars / gallon. Or Norwegian Kroner / kilogram to US Dollars / pound. I have done these, and many more, at various points in my life.

There are a few problems with most slide-rule-bezel watches:

• Most of them put 60 at the 12 o'clock position. That's useful for doing time calculations. I don't anticipate doing that very often. I'd like the 10 at the 12 o'clock position. That way, I can use the minutes on the watch face to calculate logarithms (anyone who's used the L scale on a slide rule, in conjunction with the D scale, knows how to do this). And I don't want any other values cluttering up the space between the minutes and the inner scale. For me, at least, that just gets in the way. I've managed to find one Casio watch where the inner scale moves, so I can line that scale up with 10 = 12 o'clock. For most watches, the outer scale moves and the inner scale is fixed, with 60 = 12 o'clock.
• With all too many of them, the numbers on the scales are just too small for my aging eyes. I'm looking at you Casio and Seiko.
• The slide rule bezel is more of a marketing gimmick, so they don't put much effort into being accurate. As an example, line up the 10 in the inner scale with the 10 on the outer scale. Do the numbers line up, all the way around the dial? For some of the lower-priced watches, the answer is "no, they do not." Now, line up the 10 on the inner scale with the 30 on the outer scale. Do the multiples line up? On all too many, the answer is, again, "no, they do not." Which means any calculations you attempt will be inaccurate.

Here's my wishlist, in order of decreasing priority:

1. Accuracy. Must pass both of the aforementioned tests. Otherwise, it's just "marketing" (translation: lying, bait-and-switch, etc.).
2. Numbers on the scales are large enough and high-enough contrast that I can see them without needing a magnifying glass.
3. Either the inner scale has 10 = 12 o'clock OR the inner scale moves so I can set it that way. If you absolutely must put time-conversion numbers on one of the scales, put it on the outer one, preferably outside of the slide rule scale. I want the slide rule scales as close together as possible to limit errors caused by parallax.
4. No excessive ornamentation getting in the way of the minutes tic marks. I want to be able to see them very clearly so I can calculate logarithms.
5. A complication (secondary, inner dial) showing time in an alternate time zone (UTC), preferably on a 24-hour scale.
6. Solar powered, so I never need to change the battery.
7. Ability to read the time in the dark

Anyone know of a watch which fits the bill? Citizen makes some which fit most of these, but not #3. Casio makes one which fits #3, but fails on #2 (possibly #1 as well).

## JournalJournal: Programming != Type: Redux

Coding by voice

Do you really need to use a keyboard to do programming?

If you're using a smartphone or a tablet, which has an accelerometer, you could tilt the device to navigate around in your program.

## JournalJournal: Time to update the Metropolis keyboard

Many years ago, some researchers at IBM came up with a design for an on-screen keyboard. They analyzed the QWERTY keyboard, the FITALY keyboard and a couple others, determining how fast someone could type on them. QWERTY scored lower than any other, around 30 wpm. Their keyboard scored > 40 wpm.

Details can be found here

They get into a long analysis of Fitts Law, which explains how long it will take to move from one character to another. It's logarithmically related the ratio of how far it is from one key to another to how big the destination key is. Based on this, they come up with a hexagonal pattern to make their keyboard more "dense" and arrange the characters such that the most commonly used transitions (digraphs/trigraphs) are as close together as possible.

They're assuming every key on their keyboard will have a unique symbol on it. That might work for something like a tablet, but it stinks on a modern smartphone. I can't use a traditional keyboard on mine. My fingers are too fat. I find myself getting a pretty good input speed with a compact- or T9-formatted keyboard. Larger buttons are easier to hit/more forgiving; more forgiving = faster, assuming that the text prediction software is any good.

Let's take another look at Fitts Law, again. The shorter the distance from one key to another, the faster you get there. No surprise, there. But it's inversely proportional to the size of the key. Bigger keys mean faster response.

What happens if you put two characters/symbols on each key? Can you just take their keyboard and squash 2 adjacent symbols onto the same key and depend on text prediction to make up the difference?

Their original design for the keyboard was nearly circular. After all, the shape with the shortest distances from random-point-a to random-point-b is going to be a circle. Joining multiple symbols into a single key is going to be problematic. Maybe joining 3 at a time would get the job done.

They also designed it with a single "space" button in the middle. This is because, within most text corpi, the space is the single-most-used symbol in the bunch. After all, it's used as the separator between each word, and some of those words (such as "I" and "a") are single letters. I'm thinking that rates either an oversized "space" area (as with the oversized space bar on hardware keyboards and the oversized "space" on most on-screen keyboards) or multiple "space" areas (as with the OPTI and FITALY keyboards).

I think it's time to re-do the analysis done in that paper, with an eye toward putting 2-3 symbols on each key. If you have a cluster of letters which are on the low-end of the frequency distribution, it might make sense to put them on the same key. Letters on the high-end of the frequency distribution might rate their own key. The whole idea is to get the number of keys down, so the individual sizes can be larger.

My biggest worry is that you'd end up with multiple of the vowels on a single key and the text prediction software would have a very difficult time figuring out which word you're attempting to input. I have no idea how to design the layout to make the text prediction more efficient. I know that it tends to be more efficient with a compact keyboard than with a T9 keyboard, because compact has fewer symbols / key.

Anybody have any ideas how to approach this?

## JournalJournal: Programming != typing

A while back, I was looking at a forum where someone asked if you'd use a tablet to do computer programming. Most of the responses were centered around "typing is slow/awkward on a tablet."

I agree. Typing is awkward. But, who says programming has to equal lots of typing? Yes, it does, currently. But does it have to?

I took a compilers course a few years ago. One of the things which I learned in that course was that a compiler does multiple steps, largely in series, where each one feeds into the next, with the object code being the final result.

The first step: going through the code, recognizing various kinds of constants, keywords and potential identifiers (variable names, class names, function/method names). Once it has a sequence of these, the next thing is to create something known as an Abstract Syntax Tree. For example:

a = b + c * d

Would be turned into a tree of nodes, containing operations, variable or constants. At the top, is an equals sign (assignment). "a" is on the left and "+" is on the right. The "+" also has nodes extending below it, "b" on the left and "*" on the right. The "*" also has nodes extending below it, "c" on the left and "d" on the right.

The next thing which usually happens is to "decorate" the tree. If "a" is a double and "b", "c" and "d" are all integers, we need to mark the "*" and the "+" as integer math, but we need to do some kind of implicit casting before the assignment. Usually, you "decorate" the various variables according to what type they are, then deal with the operations, then figure out where one type needs to be cast to another.

An interpreter or a compiler will start at the lowest point on the tree and work its way up. So, the aformentioned code becomes integer:c * integer:d, with the result being added to integer:b, with the result being cast to a double the assigned to double:a.

Most programs have more than one expression. Quite frequently, if you calculate "a" in one expression, then use "a" in the next expression, you could rewrite the two expressions as one. Shorter expressions, though, tend to be easier for a human to read, which is why only sadists and functional programmers (like me) tend to bother with creating really long expressions.

It doesn't really matter what source language you're starting with; whether you're using Java, C++, RPG, Cobol, Perl, PHP, Ruby or Javascript, the starting point is ALWAYS to turn it into a tree.

So, if the code you're writing is going to be turned into a tree, why can't you just create a tree? Such things tend to be awkward when you're using an interface dependent on a mouse and a keyboard, but they're much more natural in a touch-screen environment (tablet).

Something else I learned from that compilers course. Do you know what you get if you create a serialized version of the Abstract Syntax Tree, using prefix notation (such as "+ a b") instead of infix notation (such as "a + b") and put each simple expression inside a set of parentheses?

Lisp.

Indeed, the reason Lisp has such power over certain groups of programmers is that you're almost explicitly creating an Abstract Syntax Tree, in text. And it provides the means, not only for the programmer to create an AST, but also to programmatically create and manipulate ASTs. In other words, you can write code whch writes/modifies code. And you aren't doing anything as clumsy as putting together a string and running

eval(stringVariableContainingProgramCode);

You're starting one or two levels down the chain from there, with the initial parsing steps already done.

As such, the first step toward creating a touch-screen code development environment would be to create something which lets you drag various Lisp commands from a palette of commands, drop them onto the tree, and then execute the whole thing. From there, the next question becomes: do you want output in Lisp, or can we run some kind of code generator on this tree to create output in some other, more commonly used language?

Note: anything which can be done from XML or XSL can be done from Lisp. If we can drag-and-drop components into a Lisp program, we can also drag-and-drop components into XML and any of its derived forms (such as HTML, XHTML, HTML5, etc.).

So, would you use a tablet for writing code?

## JournalJournal: Dice employee Dawn Kawamoto's accepted Slashdot stories4

Dawn Kawamoto is a "Dice news" employee who "submits" articles that are accepted by Slashdot editors because she works for their parent company.

I'll be keeping track of how long Dice keeps posting stories by its own employees.

## JournalJournal: As seen on Waterworld1

Another idea.

I was watching "Waterworld" the other night. I'm rather enamored with the Mariner's trimaran (boat). I like the vertical axis wind turbine (VAWT) on the mast. But, just how would you do that?

Here's my thought.

You make something like a cross between a Darrieus turbine and a Gorlov Helical Turbine. In short, one of those twisted, multi-blade, egg-beater-looking turbines. Mount it with the central axis on the mast.

O.k. That leaves you with no way to put sails up. The blades will sweep into the area occupied by the main sail and any jib you may have.

Unless, of course, you build the blades of flexible material. Make the upper hub able to lower down the mast, bowing the blades outward into the wind, or rise up the mast, pulling the blades in flat, against the mast. This would give you a way to completely stow the blades, for those times when you want to use sails. It would also give you a way take the turbine out of the wind in gusty conditions, when the sudden gusts could overstress the mast or capsize the boat.

O.k. So, why would you WANT one of these on your boat? Well, if the bottom hub has a generator in it, it would provide a significant amount electricity when your sails are stowed and you are sitting at anchor/in port, etc. That would be a considerable amount MORE electricity than you'd get with a traditional wind turbine, mounted elsewhere on the hull.

I can imagine a boat with a couple "auxiliary/maneouvering screws" powered by electricity, with some batteries. Charge up the batteries while you're sitting at anchor, and use stored electricity to move in/out of port.

Depending on the efficiency of the whole system, and the swept area of the turbine, you might even be able to run the turbine and have it feed power to the screws for regular propulsion, if you are going to be changing course frequently and don't want to fight with the sails.

I'd be interested in hearing the thoughts of others, on this idea.

## JournalJournal: Electric busses with minimal infrastructure1

I had an idea, this last week.

We went on vacation, recently. While in Seattle, WA and Vancouver, BC, we saw plenty of electric busses. They have long poles on the back which hold up electric contacts, which connect with overhead catenaries (conductive, electrical wires) to provide current. Plenty of people complain about what an eyesore those cables are. Additionally, since the busses can only go where the wires go, the routes are kinda limited. It's a bit like a cross between electrically-driven light rail and traditional bus service. The electric busses can only go where the catenaries go, but they don't have the added expense of building rails.

So, what if you could make a bus which only occasionally needed connectivity to recharge?

The bus drives around on normal city streets. Occasionally, it pulls into a bus stop and, while passengers are loading and unloading, it puts a contact up or down, connects with electrical power and rapidly recharges. I could see two ways to do this:

1. the bus has a pantograph on the roof, which extends up to an overhead catenary, which is only found at select bus stops
2. the bus puts a "foot" down onto the ground, which sits on top of a inductive charging device (like the "paddles" used on the EV-1, only much larger); this transfers a significant amount of current, even when wet, without the possibility of electrocution, so it can be built into the road

There would be a limited number of charging points, so there would still be some limitations on routes, but not nearly as much as a bus which needed a constant electrical supply. Minimal eyesores, as well. The latter could be built into the road, keeping the overheard area completely clear.

Various companies are working with ways to make high-charge-rate (and high-discharge-rate) batteries, and there are always supercapacitors, but I'm thinking of running a pump to build up hydraulic pressure, then run the bus as a hydraulic hybrid. If you could get enough hydraulic capacity to cover 5 miles of level ground, you could hit quite a few stops without needing much more infrastructure than a traditional, diesel-powered bus. And yet, you wouldn't have the pollution of the diesel-powered bus. Instead of waiting on new technologies which are still under development or under limited production (the aforementioned batteries and supercaps), hydraulic hybrid systems tend to use off-the-shelf parts.

This idea could be extended further to light-rail systems. Since steel wheels on steel rails have less rolling resistance than rubber tires on pavement, a given amount of hydraulic storage would go further in a light-rail system. Also, since the vehicles tend to be larger, they would (presumably) have more room for hydraulic storage.

For either bus or light-rail, the pantograph would seem to be the better idea. If you want either vehicle to be able to recharge without stopping, you could put in a short distance of electric catenary (say 1/4 mile) and the vehicle could contact it while in motion. You don't have to be stopped to use that system, unlike the inductive charger.

Imagine a hydraulic hybrid bus, without an actual engine on board. It would have an electrically-powered pump, but the electricity would come from outside sources.

I'd like to see that happen.

## JournalJournal: This is a post.9

There are many like it, but this one is mine.

## JournalJournal: People of the DC Beltway, MBTP ALERT!

Montag Weatherwire
04 December in the year of our Lord, 2007

Snow is falling in Arlington, VA NOW! Hurry, get on the METRO, get to your cars, drive on the sidewalks, run over trash cans, BUY ALL OF THE MILK, BREAD AND TOILET PAPER THAT YOU CAN!

Then abandon your vehicles in the most disruptive locations possible, like major intersections!

This has been a public service of Guy Montag, humanitarian.