228 karma · joined December 6, 2012
Ended up scaling the amounts to integers, then converting those known and stable amounts to _character strings_ then doing the multiplication and division by character manipulation!
Don't laugh too hard; performance wasn't a consideration but _decimal_ accuracy was. It did the job.
However you feel about such surveillance, it legal scope and extent is being democratically debated now.
You can contact your Representative using this site: http://www.house.gov/representatives/find/
Speak your mind to your Rep. It's how Representative Democracy works.
* No leaks
* No rust
* Flow directions identified
* Flow content/category/origin/destination identified by color
* Room to move replacement parts in and inoperative ones out
* Equipment pads for... I don't know, but it looks good
* Engineering, not haphazard patching
* No people
Without the bias voltage, there would be no electric bias field between either electrode relative to the diaphragm, against which bias fields the signal adds or subtracts in order to move the diaphragm bidirectionally.
The required bias voltage of an electric field headphone element (or speaker) is very much akin to the permanent magnet of a conventional electromagnetic loudspeaker -- both provide a fixed field against which the signal works to produce proportionate mechanical motion.
Whether this bias voltage requirement will eventually result in "phantom power"[1] on analog "headphone outputs" as it has [optionally] for professional analog microphone inputs[1] -- or small power cells and inverting electronics in the headphones or on the headphone wires (perhaps supporting other analog or DSP functions such as active noise cancellation, equalization for flatter response, or decryption of an encrypted digital headphone signal) -- may be up for the market's consideration in a few years.
I do find that a brave integration -- using fuel as a coolant.
Not an engineer in this field, but I'd imagine using fuel flow as coolant makes for a lighter-weight engine overall, even as it might complicate control system software, and might place narrower limits on, or complicate stability control of the engine's net available (throttable) range of power.
Just speculating here, but perhaps a single engine's power range limitation becomes another reason (along with graceful system degradation, without mission loss, under single engine loss) for SpaceX's multiple engine designs for their larger rockets? Switch off additional engines as rocket weight decreases (due to fuel and oxidizer usage) during descent? Doubtless there is a great difference in total mass between take-off weight and landing weight, so it would seem to require a lot less fuel & oxidizer to land it than to lift it to orbit.
Also wondering about ablative heat-shield placement and arrangement for re-entry, first and second stage.
The cryogenic fuel is piped about the "outer surface" of the rocket's nozzle and combustion chamber such that these essential structures doesn't melt away under the pressure and heat.
That's the time one must apply heuristics such as (A) expand one's domain knowledge through research or talking to others, or (B) expand one's observations on the subject, or (C) expand one's hypotheses into the realm of "Oh it's just not possible that...", or "Let's try something that looks really 'stupid'...".
Of course, heuristic (C), being presumption-checking in face-saving disguise, has been the most fruitful heuristic in all my years. Those successes often become the best "teaching moments".
But here's a success story that followed heuristic (B). It goes back to the early days of the MITS Altair 8800[1] and its "S-100 bus"[2], a physically large passive backplane bus for the 8080 CPU. My employer sold complete systems comprised of that hardware with general purpose business software we wrote (using 1979-and-later versions of Bill Gates' first commercial product [3]).
We had systems that would intermittently "cold-crash" with no observed relationship to anything "rational".
So, observe: Pull the boards out and inspect them for bent pins on chips, cold solder joints... nothing. OK look at the backplane connectors, topside: No dust or bent pins. Finally turn the emptied chassis upside-down and look at the 100 solder connections for each of the 18 or so card slots. Get out a magnifying glass because this will take some time...
...and there they were: Three "cakey" looking broken solder joints on the bus. Evidently, the backplane board flexed enough (or the S-100 connector pins themselves ccommunicated enough flexure to their solder joints) upon board insertion and removal to break a weak solder joint on the bottom of the big PC board that was the backplane bus. Resolder all 1,800 pins and promlem solved for the lifetime of the machine. Found the same failure mode in a couple other boxes in the time 7 years I worked there, otherwise maintaining software.
[1] https://en.wikipedia.org/wiki/Altair_8800 [2] https://en.wikipedia.org/wiki/IEEE-696 [3] https://en.wikipedia.org/wiki/Altair_BASIC
In writing VCS commit comments, I'm finding it most useful to compose these major-event commit events beginning with a <what> word written in all caps:
o COPY out to SHELF <name>
o MERGE in fixes for Ticket <id> from <what node>
o RELEASE to TAG <id> as copy from <TRUNK | BRANCH <name>, MERGE back to TRUNK >
o REVERSE MERGE my bad in Commit #<Rev>, detail in Ticket <id>
Daily commits for work in progress don't get the all-caps treatment. My VCS (or perhaps my understanding of it) doesn't allow me line-level or block-level commit comments; those would reduce my inline comment density.
That said, it's worth noting that the code base has been maintained through three VCSs, and independently annotated by two disjoint Ticketing systems, one of which went through an involuntary Ticket renumbering that was self-overlapping and irreversible. That taught me to prefix my Ticket references with a few "character constants" identifying the Ticketing system "du jour". A bare Ticket ID number has an implicit context; a "fixed prefixed" number communicates context whose value takes quantum jumps in value and user gratitude when the Ticketing system gets changed out.
A cumulative top-of-the-file change log, in reverse chrono order. increases in value with age. Some of the judgement errors I made in years past become clear now, many times tripped across while looking for something else. Candor in commenting pays.
o A discovery and progress narrative, useful to regain working context after long interruption, fit neither for inline comments nor VCS commit comments.
o A research and reference document list
o A related Ticket reference list
o A summary recovery plan and record
o A summary integration plan and record
I'm constantly trying to find a balance. Definitely the "Why" of a code change is most difficult to self-document.
A style I've used for decades, a bit wordy, but useful in merging change sets, keeps a change log at the top of every module / source file naming the person making a change (who), dating the change (when), tagging it with a pseudo-html tag [wrapping an area of code changes in the body of the source file] (what and where), and at the top, a reference to the failure case or test case (why) explaining why it was necessary to make this change.
When one change spans multiple files, I dedicate one source file to contain the detail, and all the others make reference comments to the one source file containing the detail.
One way involves accumulating an array of nodes already visited as the tree gets walked, checking each node as-visited for membership in the array-to-date.
The other method, a bit more of a hack, is just adding a LIMIT clause.
I think the 'WITH' clause is a great addition to the SQL standard, very much worth the learning the weirdness of its syntax and its optional 'RECURSIVE' term (which, as the Postgres documentation points out, isn't really recursion, it's iteration).
Then I do my checksums of the page's presentation in the sheet. Find a bug, go to the SQL in the back end, fix the cause, write a little (manually run) SQL validation test test for that case, then cycle through it all again until the bugs are out and a nice little suite of validation tests in SQL. Really nice to have Excel, where I can point-and-click to write sums.
Amen to that!! Yes, "Clippy" (Excel) gets a little too enthusiastic at times, but the missing piece here is metadata. So Clippy does what Clippy can without metadata, and the results can be laughable at times.
My fix for that, _if I'm sourcing the data_, is to source it as tab-delimited (not CSV-delimited) from the clipboard into an empty sheet area twice:
With the first paste, I 'visually' correct the columns' incorrectly guessed data types, but Clippy oddly doesn't attempt to reformat the data. No worries, I just select all, hit DELETE, then do my second paste using the same starting cell as my first paste. Clippy doesn't interfere this time, and my data comes up all beautifully typed as I want it. I don't know why, but the DELETE key doesn't kill the data types for cells, and I'm glad it doesn't! Not visible, not obvious, but very useful.
Excel for that? No. Code for that? Yes.
Agility? Quick checksums? Looking for errors? Ad-hoc analysis?
Excel for that? Yes! Code for that? Depends on whether I have to do it again, or if it gets big.
Ad-hoc correlations for equality checking? I'll take a FULL OUTER JOIN over criss-crossing cranky VLOOKUP(...)s any day.
(1) pgAdminIII's query tool (not the tedious query builder, yes the bare SQL ("pencil" button) query tool, a plain text editor and SQL runtime
(2) An editor able to both allow open files to be changed externally, and notify me that that's happened (no file close/reopen; can leave one file open for many round trips here). Also, have it make whitespace characters visible so one can see TAB characters. EditPlus does these job for me.
(3) A spreadsheet program open to a blank, unnamed, unsaved sheet. You guessed it, I'm talking Excel.
Here's the workflow:
(A) Run the next try of the query-build-in-progress in the query tool, sending its output to the file "simultaneously open" on EditPlus. Include headers, and use a column separator that's unlikely to occur in data, e.g. the pipe symbol, '|'. Almost all keystrokes.
(B) Switch to EditPlus. It then politely notices the file's been changed, assent to its doing a file reload (no close/re-open in the UI, but of course that's what it does). Two keystrokes.
(C) Globally change | to \t, but don't bother to save the file. Just select all and copy to clipboard. A few keystrokes.
(D) Switch to spreadsheet, paste. Two keystrokes. Here is where using the TAB character as a column separator works its good magic; all the headings and all the query result drop into properly aligned cells in the spreadsheet.
Analyze the results in the spreadsheet, maybe highlight some color on problematic rows, columns or cells. Go back to the SQL editor and re-run the whole chain.
No file naming (except once on startup), no import wizard (ugh!), no open/close, no CSV misinterpretation. All stock software.
Various ways of icing this particular workflow-cake:
* After pasting into the sheet, highlight the columns that Excel typed as numeric when you know they're character values that happen to be all digits. Use 'Format Cells' to change the 'Number' (data type!) from 'General' to 'Text'. Nothing will appear to change, but here's the magic: Highlight all the cells and delete their content (delete key). Now paste from clipboard again. This type the character data hasn't lost its leading zeroes, and it's properly left-justified.
* Start with a SELECT ... then once the result is in Excel, delete the colums it turns out you don't want... then hightlight those headings, copy to clipboard, paste to editor, reformat as comma-separated, copy and paste that in place of the in the original select.
* Use underscores in column names instead of camel-case, e.g. row_id instead of rowId (camel-case doesn't work in PG unless column identifiers are quoted, not worth the pain). Once in Excel, highlight all the column names, repalce underscore with blank, set the Format to Wrap. Now the column names form a distinctive taller-than-the-data-rows, easy-to-read.
I've come to think of (and use) the clipboard as a manual, stepwise imitation of the character stream native to shell scripting of *nix CLI tools. Not a true 'toolchain' in that one has to manually pump everything through the clipboard, but but still effective and quick enough for fast, "filenameless" turnaround on query development, and very little mousework.
Most of all, it gives me the very significant power of a spreadsheet for query error analysis.
I find it interesting to read that:
o To get the kind of highly variable "transient response" (change in power output) required for automotive applications, the author proposes using a chemical battery as part of the power management system, as the fuel cell system can't itself respond quickly enough.
o The control system is as much or more challenging than that of an internal combustion engine, requiring control of these sub-systems:
__ * Reactant (hydrogen) flow subsystem
__ * Heat and Temperature subsystem
__ * (pure distilled) Water Management subsystem
__ * Power management subsystem
__ * If not fueled by hydrogen, an on-board fuel processor subsystem to break the chosen carbon-based fuel down to hydrogen
With just hydrogen fuel, it still takes an air compressor, three heat exchangers (fuel temp, fuel cell stack heat extraction, compressed air heat extraction), an air humidifier, a water separator, a power converter, a chemical battery (and software of course, to implement the control system) to make it all work in vehicle applications.
In more detail: http://ethernethistory.typepad.com/papers/EthernetPaper.pdf
I don't see a lot of paint discoloration, and a label of some kind is not charred or much discolored.
[1] http://phys.org/news/2013-01-overcharging-batteries-eyed-boe...
Recommend Postgres' own concise tutorial: http://www.postgresql.org/docs/9.2/static/tutorial-sql.html for starters.
Also, after you've cracked joins, learn the 'WITH' clause ( http://www.postgresql.org/docs/9.0/static/queries-with.html ), it's good: 'WITH' restructures the more difficult 'middle-outward' subquery syntax to a top-down 'detail-to-summary' structure. Far easier to build, debug, and re-grok 6 months later.
* This test quickly 'clued me in' that a logo should give a "commanding", "authoritative", "brooks no argument" look. Helvetica, yes; Ariel, no: Ariel made some logos look downright self-satirical.
* An email client I use has Ariel as its default font. In that (two-way communication) context, where accidental antagonisms can arise, Ariel seems to "look less antagonistic"
* So this test speaks to me about appropriate fonts for two different contexts, and personal point-of-view.
* Got 20/20, but might not on a 2nd run. I'm only human.
Here's a highly technical blow-by-blow analysis of the August 2003 North American blackout: https://reports.energy.gov/BlackoutFinal-Web.pdf
Here are some of my favorite quotes: ..."At 13:30 EDT, the MISO EMS engineer went to lunch. However, he forgot to re-engage the automatic periodic trigger."
..."Also at 15:42 EDT, the Perry plant operator called back with more evidence of problems. “I’m still getting a lot of voltage spikes and swings on the generator . . . . I don’t know how much longer we’re going to survive.”
..."At 15:46 EDT the Perry plant operator called the FE control room a third time to say that the unit was close to tripping off: “It’s not looking good . . . .We ain’t going to be here much longer and you’re going to have a bigger problem.”
A great read both for its tutorial and historical value.
Voltage-regulated "inverter technology" electronics can, ironically, behave less "linearly" under adverse supply voltage conditions than resistive loads such as incandescent lighting and electric kettles.
Electronically-ballasted fluorescent lighting, CFLs, computer power supplies, VFD motor drives, "inverter technology" microwave ovens all electronically regulate their current draw inversely against voltage supply changes. Voltage goes down, current draw goes up, power demand remains ~relatively~ constant.
So when a brownout (voltage sag, not an outage) comes along, to some extent, these "well regulated" devices hide it from the user. You might not see a "brownout": The electronically ballasted fluorescent lights don't dim so much -- or at all --, your laptop computer keeps running fine if the sag doesn't drop too much, and any DC-powered fans won't necessarily slow down so much or at all. But maybe you heard a universal motor somewhere slowed down. Or maybe the lit-up display area on your old CRT monitor (is anyone still using those anymore?) shrinks 10% then comes back. You hear your computer's desk-side UPS click in (if it has a relay, cheap ones do) then back out but don't see the lights dim. I've seen and heard this and found it rather jarring.
The term "brownout" may become an anachronism (perhaps it has already), not because brownouts don't happen anymore, but because they don't dim the room lights anymore.
To see how much variation a small "non-dimmable" CFL will tolerate, I just put one on a variable transformer and lowered the line voltage gradually from normal (120 Volts) downward. Here's what happened: o It lost very little brightness until about 60-some Volts o Below that threshold, it just turned itself off
As a device user, this is what I'd expect of a "well-regulated" device that runs on mains (grid) power.
But I don't imagine such "well regulated" loads make grid dynamics marginally easier to control under the severe conditions which lead to voltage sags. Probably not much worse though, considering all the heavier loads a grid must support.
On many days, the wind power goes up at night and down during the day, very much in complement, though in larger scale than, solar generation. More solar will more nearly equalize the two -- on good days.
California is nowhere near having an overcapacity of renewable sources to worry about; just look at the first graph where the lowest demand (2 AM to 4 AM) is 22 GW on 12/14/2012. The highest the solar gets is not quite 1 GW. The wind is more variable, anecdotally as high as 3+ GW and as low as a flatline near zero for the whole state all day and night.