short: collected thoughts on being a very un-neighborly motorist.

A friend and I have been talking on-and-off about using propane (or was it diesel?) injection on the hot-side of a turbocharger to spool it up faster or maintain compressor speed during off-throttle periods. My understanding is the misfire systems work very well, but are hard on the turbine. I would imagine this is the same reason compressors have blowoff valves – the shock waves of the air being stuck in the intake manifold hurts the compressor. The other reason of course is you're blowing up fuel in the turbine, which is not a very subtle effect.

The more I think about it, though, the more I think you wouldn't need to have fuel burning actually in the turbine. If you instead had fuel injected directly south of the turbine, the combustion would bring more fuel and oxygen into the hot side, where, hopefully, it would burn of its own volition. Behold, the pulsejet:


Here's a rough diagram, chopped to look more like a turbocharger:

>===oxygen(intake)==>fuel injection===>combustor====>exhaust

For our purposes, this would look like:

(engine)==>(turbine)==>(fuel injection)===>(combustion)===>exhaust

In the above picture, you see a dark tube flowing into the combustor (bright orange), with a little blue flame coming out one end. That's the intake, the "cold side". The principle is the flowing of exhaust (the expanded, heated air) out the hot end causes more air to be pulled in, and it pulls fuel with it, as you would have in a carburettor. Because of this, there are in principle no moving parts. Just a tube with a hot end and a cold end.

How does this help a turbocharger? Well, if you have a turbocharger on the hot side of your reciprocating engine, it's only able to get new air when there is positive pressure at the turbine inlet (the turbine inlet pressure increases with engine RPM and compressor pressure at the throttle body; essentially the compressor feeds the turbine, which spools the compressor, and so on).

I've been thinking that the problem with injecting fuel into the turbine side is the above-mentioned problem with turbine life. However, it seems that if you could get combustion happening at parts south of the turbine, what you'd have is a combustion reaction that sucks new air into the turbine either through the engine (and again, spooling the turbine spools the compressor, which adds pressure to the turbine inlet) or a "fresh air" pipe on the hot side (which would probably need a valve) without actually heating it any more than it would be by the reciprocating engine.

The first thing that probably comes to mind here is, wait, you want to burn the exhaust? Well, yeah. It turns out that piston engines are not especially efficient at combustion. Usually with piston engines, you're looking at 15-25% fuel burn efficiency. This is why tricks like CVCC, TGV's and even PAIR work:

The tumble generator valve is installed on the engine intake manifold and sends a strong vertical swirl of intake air into the cylinder to improve engine performance, particularly during ignition and starting. In addition, it provides a stable, lean burn even at engine start, thereby significantly reducing hydro-carbon emissions immediately after engine start.

The other thing that comes to mind is you could have a turbine spun by a pulsejet that in turn spun a compressor which was not coupled to the exhaust, giving you an on/off switch for (constant-pressure) boost, without a restriction on either the exhaust or intake.

So, questions.

Anyone actually seen or heard of anything like this?

Anyone experienced with gas turbines and care to comment on how sturdy your average centrifugal flow turbine (not axial flow) is?

Suggestions on fuel? Seems just about any liquid fuel would work okay (diesel and kerosene readily and have more energy but are dirty; alcohol is cheap and cleaner, but doesn't have nearly the energy of dino fuels) whereas propane is much cleaner but more flammable and, oh yeah, is a gas at room temperature. (frown) Hydrogen would of course work, but I think I'd rather have a bucket of propane than one of hydrogen. Perhaps a mixture of a fuel and nitrous oxide would work better in the exhaust (it seems to be working well enough for Rutan – boy that Branson is one flaming dude).

Anyone want to sound like a V-1 driving to work? (german)

And, uh, no, this probably doesn't fall under the "reliable" or even "practical" category. However, it would be a lot of fun to take e.g., your average $1500 FR junker and, uh, adapt it.

harmful workplaces

What responsibilities do companies have in regards to their employees' health? I think it's clear that, in the US at least, companies are not required to provide health care for their employees. I think it's also clear, however, that they are required to provide a workplace that is not harmful to their employees. Yet, what is the standard for "harmful"? We are not allowed to force our employees to work in areas where there is asbestos or radiation, nor where there is cigarette smoke, and we even have to be very careful when sending security forces into combat zones.

What about more esoteric or loosely-defined harm? Is a work environment which is so toxic to its employees that it generates acid reflux, migraine, panic attacks, or heart attacks "unsafe" for its users? What about in cases where employees are covered under the disabilities act? Is an employee who is psychotic or clinically depressed being reasonable in asking for an environment that does not engender psychosis or depressive episodes? Is it something they would have legal protection from? These may seem like edge cases, but what about an environment in which a conflict between fluorescent lights and LCD displays caused epileptic seizures? Surely a line has to be drawn somewhere, and it would be a damn shame if employers got to decide where that line was drawn.

Epilepsy, psychosis, and unipolar depression are all covered under ADA, and of course asbestos and radiation are covered by OSHA (and others). We even have coverage for repetitive stress injury. Epilepsy is of course covered by ADA.

It would seem to me that most employers would respond that they simply don't hire psychotic, bipolar, depressed, schizophrenic &c employees, but the fact of the matter is they're actually required to, because discriminating against candidates for a position on the basis of their mental health or abilities is prevented under EEOC. The most relevant text from ADA seems to be:

Neither the statute nor EEOC regulations list all diseases or conditions that make up "physical or mental impairments," because it would be impossible to provide a comprehensive list, given the variety of possible impairments.

So, your employer might spend a couple thousand dollars on getting you appropriate equipment for your IT job (a proper chair, display, keyboard, mouse, and desk). They would put in a wheelchair-accessible ramp, bathroom facilities, and so on. They'd provide "handicap parking." They'd ensure that the boiler is not exhaling carbon monoxide into staff areas. But would they respond to a request to educate their management on providing an environment for their employees that does not create psychiatric issues (and really, where else could such problems be mitigated if not management)? What if you told them that a year of psychiatric care would cost ten thousand dollars or more, per employee? Mental impairments are not defined (and in fact are explicitly undefined) under ADA as "physical," and are defined instead by the physician/clinician covering the condition.

It's never going to be a pleasant conversation when an employee has to say to an employer, I have a mental impairment and I need you to provide reasonable accommodation, but they are entirely reasonable, and legally covered for, asking.

Three recent books, interesting contrast

(short: thoughts on recently published fiction)

I recently finished Black Man by Richard Morgan, Matter by Iain Banks (and The Business), and The Dreaming Void by Peter Hamilton. To be honest, I'm rather perplexed. Black Man is not really RKM's best, but it's fairly good. He manages to avoid rewriting Sheep Look Up, although it's pretty clear that's what he intends to write. It's just not quite as good as Woken Furies was. Matter was Banks' latest Culture book, and I think it's telling that I have mostly decided that Banks should take a break from the Culture and sort of point in a different direction. Banks, in particular, is a fiercely intelligent author who writes a meticulous book. There are perhaps a few typos or syntax/grammar issues in each of his books, compared to Hamilton's dozens. He also has an incredible intuition for sentence structure and paragraph punctuation. There are indeed entire paragraphs which are a single sentence, properly conjoined and formatted with various clauses and parentheticals. This probably sounds awkward, and I'd say that they're not something you'd use in spoken English, but in a book it works very well.

The transition from Banks to Hamilton was a jarring one. Where Banks aims to describe settings thoroughly and to carefully craft related thoughts into a single cohesive sentence (or paragraph, or even chapter), Hamilton seems to form text from sequences of un-connected, but related sentences. I don't have the book in front of me, but consider the text "Smith was wearing a dark blue suit. His shoes were polished. His tie was loosely knotted about his neck. Paula looked at him cautiously. 'I don't trust a man who can't tie his tie,' she said." Banks, to his credit, joins these individual sentences into, usually, a single sentence, and yet does so without seeming heavy-handed or long-winded. It was very hard to move from Matter to Void, and many times I damn near just put down Void, being unable to read text that was so choppy.

I've mentioned before that Banks writes incredibly direct and almost terse fiction. I wouldn't normally consider Stross to be long winded, but it's hard to think anything else when reading Banks. As such, I'm actually kind of confused about how I managed to finish Hamilton's Night's Dawn books. I read them perhaps ten years ago, and enjoyed them. Even back then, Hamilton was writing these monstrous thousand-page novels, and in pairs or trilogies. His recent set of books, the Pandora's Star sequence, were refreshingly short – he managed to finish that sequence in perhaps 1400 pages. I was pleased that his writing seemed to have taken a turn for more concise (not because of any lack of commitment on my part, I do love a long book), and was disappointed to see that he seems to be comitting trilogy again. The problem with this is the first few hundred (I was complaining last night that basically six hundred (of 660) pages of Void is world-building and his typical character development (every single main character in his books are these sorts of swashbuckling, handsome, charismatic dudes, with women thrown in for window dressing, and everyone else essentially being a weak contrast to the primary characters). For even the first three hundred pages of Void, he seems to be simply setting up the remaining 2,000 pages. This is a little hard to explain, but basically he starts the book breathlessly, describing a hopelessly large setting, including literally dozens of primary actors in this, and the next two books. Between the sprawling setting and huge array of characters, it was pretty easy to become disinterested in the book.

I'm left wondering whether I was simply a less sophisticated reader ten years ago (almost certainly), or if Hamilton's writing has gotten worse (this I find less plausbile, as he hasn't changed styles much). Of note is the fact that his A Second Chance at Eden short stories were well-written and concise.

As for Banks, I am continually impressed with the man. Having read Black Man after Matter, I was aware of the difference between RKM and Banks, but this was not a bad thing. Morgan seems to want to write a noir-ish kind of story with a blogger-style wit and vocabulary (and punctuation even). His phrasing and syntax is conjoined where necessary, and sparse where necessary.

I'm clearly going to have to read a few books and see if my impressions are right (that I've changed as a reader), as, while I read a lot, it's been quite a long time since I went back to Hamilton (for contrast to this impression, I re-read the last quarter or so of Revelation Space, by Reynolds, and was pleased to see that it was just an amazing book, and my impression after a few years was the same).

(currently reading: Steven Millhauser)

ruby, dashcode, and development in general

(short: perl vs rubycocoa, XCode and Apple's developer interface)

I've been writing code in Ruby the last couple weeks, per suggestion from mm w. I had actually said that I was jealous of the fact that he was writing code and that these days, I really don't. He said to just wade in to Apple's developer documentation and various APIs. This seemed to be oversimplifying to me, as the last time I peeked under the covers, Obj C was just a big ugly API that was poorly documented.

So I downloaded the gig or so of /Developer, and did just that. I was pretty shocked to see how simple the Dashcode interface, and in short order, I'd written a few trivial widgets. As I began to get deeper into the documentation I noticed the RubyCocoa bindings and was back off into Ruby land.

The API is intuitive enough that there's not much of a learning curve. The interface is facile and yet powerful enough that I didn't feel constrained by the new (-ish, to me) language. Really, the biggest concern I had was the lack of a typical last or break, as I'd find in some other high-level languages (well, mostly perl; and of course, I'm probably wrong here). Very quickly, I wrote a small application that scrapes url's in a very hash-esque fashion ( [ url => page ] => image). I created a tiny perl script to test my regular expressions, but after that was done, I had created enough classes and logic that all I had to do was throw in the Obj C bindings and a Cocoa app was generated. I'd done this in TextMate, but after I'd finished, I began to port things in to XCode which, wonderfully, has syntax highlighting, build options, debug options, and even native support for Subversion. Now, TextMate has these things, but I think their claim that it's the "Missing editor for MacOS X" is just wrong, as XCode has most of the stuff I'd need to write MacOS-API-based code, but I suppose it's useful for the other languages out there (wow, a YAML editor?).

As before, the one thing painfully missing is documentation. Rdoc is okay, but coming from perl, I can't help but be disappointed by the very small, generally close to useless documentation. There's what looks like generated documentation. An example of it being totally inadequate is thus:

----------------------------------------------------------- Object#class
obj.class => class
------------------------------------------------------------------------
Returns the class of _obj_, now preferred over +Object#type+, as an
object's type in Ruby is only loosely tied to that object's class.
This method must always be called with an explicit receiver, as
class is also a reserved word in Ruby.

1.class #=> Fixnum
self.class #=> Object

For comparison, perlmod is not just thorough, it's easy to read and written by, you know, a human:

DESCRIPTION

Packages

Perl provides a mechanism for alternative namespaces to protect
packages from stomping on each other’s variables. In fact, there’s
really no such thing as a global variable in Perl. The package
statement declares the compilation unit as being in the given
namespace. The scope of the package declaration is from the
declaration itself through the end of the enclosing block, "eval", or
file, whichever comes first (the same scope as the my() and local()
operators). Unqualified dynamic identifiers will be in this namespace,
except for those few identifiers that if unqualified, default to the
main package instead of the current one as described below. A package
statement affects only dynamic variables‐‐including those you’ve used
local() on‐‐but not lexical variables created with my(). Typically it
would be the first declaration in a file included by the "do",
"require", or "use" operators. You can switch into a package in more
than one place; it merely influences which symbol table is used by the
compiler for the rest of that block. You can refer to variables and
filehandles in other packages by prefixing the identifier with the
package name and a double colon: $Package::Variable. If the package
name is null, the "main" package is assumed. That is, $::sail is
equivalent to $main::sail.

And of course, it's 4,000 words. It's possible I could be wrong, and there's some huge piece of RDoc I'm missing, but I doubt it has something analogous to perldoc's -q, or even the very useful perlop, perlre, and perlretut. The documentation, however, is much better than it was even a few years ago, and I know there are plenty of refugees from perl. Probably somebody out there is timtowtdi'ing Ruby as I write this (which is a good thing).

At any rate, I'm probably over-pleased with what I'd written, but I'm still very happy I was able to go from not really writing any code to having written a Cocoa app in just a couple days.