I think you want to search for "computational complexity". The classic text is by "Aho, Sethi, and Ullman", IIRC. There may be newer texts by now. Happy reading.
potassium and phosphate, actually. Both are required for fruiting, but not needed so much for general plant growth.
A main component of healthy soil is the availability of organic matter in addition to the clays and sands. Growing a healthy root mass (as legumes do) improves the soil in just that way. Fixing nitrogen is a tremendous aid to that. Fixing nitrogen with bacteria is still better because it leaves behind a more complex matrix than ammonia and roots alone.
The WWVB time code does have a DST flag that indicates whether DST is in effect. That is true of every radio time-code broadcast I know about (e.g. the Rugby clock in England, MSF).
The DST setting on the clocks I have allows me to decide whether I want to display the time in DST or not.
The folks who designed WWVB are not idiots -- they actually thought ahead when the protocol was designed. Don't forget that DST has been used, canceled, used, doubled, and used again. They knew the rules were likely to change, and the original target devices were electromechanical -- no chance for any fancy stuff.
Relax -- your investment in atomic clocks (really radio-controlled) is safe:) They get DST from the master clock already.
All of the radio-controlled or "atomic" clocks work on the same idea -- they receive a time signal from a low-frequency transmitter (60kHz in the US). The device will typically set an internal quartz clock from the received time code. The time reference signal is strongest at night, so it's typical for these clocks to set themselves at 2 or 3 am (local time). Some newer designs will set whenever the signal strength is high enough for a good read. This redundancy makes for a very reliable device.
The time code contains, among other things, a flag indicating whether DST is in effect. So -- when (if?) this change to the DST rules goes into effect, the folks who run the transmitter will change the flag at the proper moment, and the next time your clock reads the signal, et viola! it reads DST.
The radio station broadcasting the time code in the US is WWVB, and it is managed by NIST. The WWBV system is really an elegant design, involving a wonderful mixture of old and new technology. Check it out:
By the way, there are 4 other time zones east of US Eastern. The Atlantic time zone, for example applies in Nova Scotia. There are also similar time reference broadcasts in the EU, Russia, and Australia. There might also be one in China - but I've never needed to look that one up. I'm sure that will change one day soon.
Don't feed the trolls, Don't feed the trolls... Uh, OK.
Apparently you have no experience with the UNIX way.
What you don't seem to know is that MS Windows is utterly missing the wonderful collection of little tools available on every UNIX platform (Well, without installing cygwin -- but that's UNIX, right?). Each little tool does one little job, and does it well, and all of the tools can be connected in standard ways. So, I *can* use C++ or C or PERL or Python, but I don't *have* to -- many times all I need is sh and that wonderful collection of utilities...
And yea, I do write huge programs sometimes -- but only when that's really required to get the job done.
I don't think I ever heard of a MF being used for the types of things I get involved with, though. (back to the topic:)
You might have a look at LyX, which is a LaTeX front end, which looks promising to me.
There is also TeXShop, which is a Mac OS front end for LaTeX.
I personally use LaTeX all the time for fairly large documents (hundreds of really dull pages of specifications, but I digress...) The documents are properly typset, indexed, cross linked, hyperlinked, and available in PDF. I'd go insane trying to keep documents that size workable in Word (and probably OOo, for that matter).
I don't use it for smaller writing, but then I tend to write smaller things in email, or store them in a wiki.
I understand there is also a FOSS DTP package that isn't based on LaTeX, but I don't recall it's name ATM.
Rereading your post, I see that you apparently want to allow others to edit the work. My solution doesn't work so well for that. I tend to accept comments and refine based on that. One way I get comments is via Acrobat writers comment facility. I've often wished for (and wondered how to build) such a tool. I just need about 6 months of free time, I'd guess;)
Consider this: We've been installing software controls for transit trains for the last 20 years or so. Extensions (adding track), and upgrades (improving performance or train density) have to mesh cleanly with the existing system. That means examining work that might be 10-20 years old. I'd work with it electronically than scan, clean up, *then* edit.
I'm sure other industries have similar issues. It's only the PC that is so ephemeral that they can afford to turn away from relatively recent (in historical terms) formats. Seriously -- 10 year old formats still have *great* value.
So -- choose your formats wisely. You'll probably need to work with them for a long time to come, or redo your work repeatedly.
Actually, most Deisel Electric Locomotives run on DC instead of AC because the system is more reliable. The DC designs require more maintenance (e.g. commutator replacement and adjustment), but the AC regulator components are much more expensive. The failure rate is high enough that the DC design is still superior.
One other factor that is a problem for the AC design is the volume of RF noise they generate. If you happen to have the radio on when one is close by, you can hear the motor turning over in the noise (complete with little variations in the speed that correlate nicely with what you hear from the loco itself), and you cant hear the station you were lisening to.
not and eq existed in the very *first* implementation of LISP on an IBM705. That's, what, 1965? EQ always tested object identity ((eq a b) iff a and b both reference the same address), which in every LISP I'm familiar with ammounts to address equality.
I think I'll be just a little historically pedantic;-).
IMHO dates from long before ichat. It doesn't quite predate me, but does predate my first session at a keyboard (circa 1980). In the days of dial-up bulletin boards and USENET News via uucp, modems were slow, and those acronyms were just the thing to get the point across quickly. If you were reading usenet, you knew what they meant. Some of us old timers still use them reflexively. I find myself explaining them occasionally -- but then I point to the Jargon File, and say RTFM. (apologies, ESR, if this slashdots you...)
I'm using pdflatex for a collection of technical documents that run to in excess of 2000 pages each. I'm using epstopdf to make pdf images for inclusion. It works well except for a group of engineers that can't be bothered to actually set their save options.
The documents are heavily cross-referenced and indexed. One group insists on using MS Word and Acrobat Distiller. At this time, the documents cannot be produced with hyperlinks enabled -- Distiller often runs for upwards of a day without completing. When it does finish, the hyperlink boxes are shifted slightly.
Using pdflatex, I can manufacture the same document in just under 10 minutes, and it has all the hyperlinks, and they're properly placed.
When I'm writing parts of this document, I give no thought to formatting, but I do mark up for semantic content.
PDFLaTeX is the only way I can stay sane with documents that big.
My WORD! The useless *BONDAGE*! There is a serious disconnect between UML models and C++ code that makes reverse engineering an impossible task for all but the simplest data models. The problem boils down to the fact that a UML relationship type can be implemented in a number of different ways. Similarly, a particular construct in C++ can represent several different UML relationship types. This leads to a many-to-many mapping of C++ coding constructs onto UML relationships.
I also had a tough time getting Rose to generate a reasonable skeleton when using STL containers. It never seemed to construct the proper container declaration, or place it in the right scope.
Most of the code it produced would have been hopelessly ineffecient, and I could never convince the tool to change its ways. Tech support didn't understand C++ well enough to understand (a) what I was talking about, and (b) why it was a problem.
After struggling with the tool for most of a year, *trying* to make it work, I finally ripped the code out, stripped the Rose comments, and started making real progress.
We now use Doc++ to document the design, and that works much much better. The only thing I miss are the UML diagrams. That last statement is telling: The UML diagrams did a great job of describing complex data structures (of which we have several), but the tool could not generate code to implement the UML diagram that was reasonable.
I hope you have better luck, but I'd be prepared for much disappointment, unless your project is a small one.
I know this thread should really be dead, but I have to respond. I'm not confused at all. I know in great detail what I'm talking about. Here's the scoop:
Hash tables have *amortized* constant time lookup, but worst case behaviour is linear. There are two basic approaches to hash table construction, and they degrade in slightly different ways.
Open coded hash tables use (something like) a vector of cells indexed by the hash value. If there is a collision, you rehash (compute a new and different hash) or scan for an open cell and use that. In either case, you keep going till you find something. This leads to linear scan on a nearly full table. Maintaining these requires the rehashing process you describe.
Bucket hash tables used a list in each cell. You hash to the cell, then scan the list. In this case, an over-full hash-table has long lists to scan. Again, linear in the worst case.
In both cases, we're assuming a good hash function. One easy way to get poor performance out of a hash table is to have a poorly performing hash function.
Now, with respect to the STL, the issue for the designers was, in fact, worst case performance; not expected case performance. Call it a design guideline if you will, but that is what they used as a criterion.
So, as I said in my earlier post, Hash tables were not in the standard because they have poor *WORST CASE* performance. Never-the-less, the good folks at SGI have produced several high-quality hash table implementations that are STL compatable (so have I, for that matter). At some future time, I expect that those hash tables will be added to the STL because they are quite useful, when used properly.
There are several good works on the topic. Knuth's "Art..." being the seminal work on complexity. He covers both types of hash tables in detail in volume 3. I also recall a paper by Stepanov discussing both the ideas behind the STL and the tradeoffs. It's fairly old -- circa 1990 or so IIRC.
Actually, the sorted containers are implemented using red-black trees. Hash tables are not used in the sorted containers because the performance of a hash function can't be guaranteed.
Iterating over the leaf nodes is the same cost as iterating over a list. Finding an element with a known key value is logN for the sorted containers while the same operation in a list is linear.
One might as well ask why anyone would bother building a working Babbage Difference Engine, yet it has been done (and the sucker works too!). I suppose the rationale for building a trebucet is slightly more obvious (throwing things a long distance).
I'm not sure how minor the variations would be. Last I knew, all fuel cells were based on the 2H+O->H2O, where the -> also produces a current. There was research on other types of fuel cells that could "burn" (e.g. oxidize to produce a current) methane (say) in this same manner, but i don't recall any success. What has worked is a process where a hydrocarbon (like methane or gasoline) is cracked to produce H2 and a residue, usually CO2, but sometimes with a quanity of CO as well.
That said, the thing that has to change to burn another fuel is the cracking catalyst. I suspect that the methane catalyst is the easiest to handle, since the operating temperature is reasonably close to room temperature, as opposed to gasoline cracking catalysts, which operate at much higher temperatures, last I knew (which was 15 years ago -- much may have changed since I was a Chemical Engineer professionally).
Does anyone out there have more recent info on fuel cell technology?
Actually, the archetypal bug was a moth that shorted out a pair of contacts in an early computer. It didn't eat anything. It was just attracted by the light of the tubes and landed in a bad location. Grace Murray Hopper was working on that machine at the time. IIRC, the unfortunate moth was duely taped into the log book.
Re: Steel Crystal Structures
on
More WTC News
·
· Score: 4, Informative
Steel (and Iron for that matter) have a number of differenty possible crystal structures, which vary widely in the strentgh, maleability and brittleness. The rusting rate also changes, but that is not interesting in this context, but it is for the design of blades and tooling. The oldest way to change the crystal structure of iron or steel is to heat it up to a certain temperature, then cool it in a controlled way. Fast cooling leads to a hard brittle structure, slower cooling leads to a more malleable structure. Heat the surface and cool it quickly and you've got case-hardened metal in hand. The key thing to remember is (as any blacksmith has experienced at some time or other) iron gets brittle before it gets to the cherry red stage.
I assume that there was both heat-related sag and a brittle region beyond that as you moved farther from the hottest flames. So, it is possible that the metal did, in fact, get brittle and snap in the heat, along with the sagging, leading to a sudden pancake type collapse.
Who would have thought that you needed to plan for hundreds or thousands of gallons of aircraft fuel when sizing fire supression gear in a tower?
Not only did computers exist, Mr. Turing was largely responsible for the design and implemention of one of the first examples that we would recognize as such a machine (with lots of help, as you might imagine). It was/is known as Colussus. IIRC, a restoration/exhibition was begun at Bletchly Park, the home of the Brittish codebreakers during WWII. There are a number of really interesting books on the topic, including "The battle of Wits", and "The Code Book", among others. I also recall that B.P. has a website with some relevant info.
While I generally agree that you need macros in some form, I'll observe that once you have macros with the same expressive power that lisp macros have, you don't need templates anymore. On the other hand, it may be that LISP style macros would prevent the compiler from handling the sort of type matching that C++ templates have (which both lend power, and make them the very devil to implement correctly).
LISP style symbolic manipulation of code permits the construction of special purpose syntax that is closer to the problem at hand, making the code easier to write and understand, provided that the macros are written to make things more clear rather than less. It is certainly true that you can take things too far with LISP-style macro expansion, but you can also go much much farther than you can with any text-preprocessor scheme.
ha == clearly you have not been reading slashdot lately! slashdot really sucks because they don't give equal time to anti-quark doesn't matter engines!!
This is a really interesting observation, one I had never considered before now, but let me take a run at an explanation:
I notice that trade paperbacks for sf/fantasy/horror/mystery titles seem to run from $5 to $12 (usd) for a really long book. CD's, on the other hand, seem to start at $15 and go up, even for short 30 minute releases, unless you want to listen to re-releases of old jazz/classical recordings (like I do) in which case you can find decent CD's for something like $12 for a 70 minute recording. I recently saw a re-release of a Led Zepplin album from 1972 for $17(!).
I read a fiction book once or twice. By contrast, my computer books get read over and over. My wife and daughters will read a good fiction book over and over till the pages start to fall out. I'll listen to the CD's until everyone else is sick of them. I'd guess that the marginal utility of both is about the same, but the CD price is much higher, on average.
I'll also note that few publishers are as flamboyant as the music industry pimps^H^H^H^H^Hpeople.
I think maybe the music lovers feel raped by ticket/cd prices. Imagine that!
Just be *very* sure you stay away from the lm_sensors package. Using that on a thinkpad will turn it into an unbootable doorstop. There is a KDE package that uses lm_sensors (sorry -- don't recall the name -- I don't use KDE). The issue is that lm_sensors accesses (reads!) the BIOS data (some of which is live -- hence the sensors name...), causing a series of events that destroy the BIOS data to such an extent that the system will not boot using any know means. A motherboard replacement is the only known cure. The bug is in the BIOS, btw, not lm_sensors, based on the idea that reading data should not alter it.
The linux-thinkpad users have been trying to get this resolved for some time (more than a year, IIRC), and (AFAIK) still no fix, even for newer systems, let alone older ones.
Slashdot Mirror
I think you want to search for "computational complexity". The classic text is by "Aho, Sethi, and Ullman", IIRC. There may be newer texts by now. Happy reading.
potassium and phosphate, actually. Both are required for fruiting, but not needed so much for general plant growth.
A main component of healthy soil is the availability of organic matter in addition to the clays and sands. Growing a healthy root mass (as legumes do) improves the soil in just that way. Fixing nitrogen is a tremendous aid to that. Fixing nitrogen with bacteria is still better because it leaves behind a more complex matrix than ammonia and roots alone.
Sorry -- that's just not right.
The WWVB time code does have a DST flag that indicates whether DST is in effect. That is true of every radio time-code broadcast I know about (e.g. the Rugby clock in England, MSF).
http://tf.nist.gov/stations/wwvbtimecode.htm
The DST setting on the clocks I have allows me to decide whether I want to display the time in DST or not.
The folks who designed WWVB are not idiots -- they actually thought ahead when the protocol was designed. Don't forget that DST has been used, canceled, used, doubled, and used again. They knew the rules were likely to change, and the original target devices were electromechanical -- no chance for any fancy stuff.
Check out the whole story -- It's good stuff.
http://tf.nist.gov/stations/radioclocks.htm
Relax -- your investment in atomic clocks (really radio-controlled) is safe :) They get DST from the master clock already.
All of the radio-controlled or "atomic" clocks work on the same idea -- they receive a time signal from a low-frequency transmitter (60kHz in the US). The device will typically set an internal quartz clock from the received time code. The time reference signal is strongest at night, so it's typical for these clocks to set themselves at 2 or 3 am (local time). Some newer designs will set whenever the signal strength is high enough for a good read. This redundancy makes for a very reliable device.
The time code contains, among other things, a flag indicating whether DST is in effect. So -- when (if?) this change to the DST rules goes into effect, the folks who run the transmitter will change the flag at the proper moment, and the next time your clock reads the signal, et viola! it reads DST.
The radio station broadcasting the time code in the US is WWVB, and it is managed by NIST. The WWBV system is really an elegant design, involving a wonderful mixture of old and new technology. Check it out:
http://tf.nist.gov/stations/wwvb.htm
By the way, there are 4 other time zones east of US Eastern. The Atlantic time zone, for example applies in Nova Scotia. There are also similar time reference broadcasts in the EU, Russia, and Australia. There might also be one in China - but I've never needed to look that one up. I'm sure that will change one day soon.
Don't feed the trolls, Don't feed the trolls... Uh, OK.
:)
Apparently you have no experience with the UNIX way.
What you don't seem to know is that MS Windows is utterly missing the wonderful collection of little tools available on every UNIX platform (Well, without installing cygwin -- but that's UNIX, right?). Each little tool does one little job, and does it well, and all of the tools can be connected in standard ways. So, I *can* use C++ or C or PERL or Python, but I don't *have* to -- many times all I need is sh and that wonderful collection of utilities...
And yea, I do write huge programs sometimes -- but only when that's really required to get the job done.
I don't think I ever heard of a MF being used for the types of things I get involved with, though. (back to the topic
You might have a look at LyX, which is a LaTeX front end, which looks promising to me.
;)
There is also TeXShop, which is a Mac OS front end for LaTeX.
I personally use LaTeX all the time for fairly large documents (hundreds of really dull pages of specifications, but I digress...) The documents are properly typset, indexed, cross linked, hyperlinked, and available in PDF. I'd go insane trying to keep documents that size workable in Word (and probably OOo, for that matter).
I don't use it for smaller writing, but then I tend to write smaller things in email, or store them in a wiki.
I understand there is also a FOSS DTP package that isn't based on LaTeX, but I don't recall it's name ATM.
Rereading your post, I see that you apparently want to allow others to edit the work. My solution doesn't work so well for that. I tend to accept comments and refine based on that. One way I get comments is via Acrobat writers comment facility. I've often wished for (and wondered how to build) such a tool. I just need about 6 months of free time, I'd guess
Consider this: We've been installing software controls for transit trains for the last 20 years or so. Extensions (adding track), and upgrades (improving performance or train density) have to mesh cleanly with the existing system. That means examining work that might be 10-20 years old. I'd work with it electronically than scan, clean up, *then* edit.
I'm sure other industries have similar issues. It's only the PC that is so ephemeral that they can afford to turn away from relatively recent (in historical terms) formats. Seriously -- 10 year old formats still have *great* value.
So -- choose your formats wisely. You'll probably need to work with them for a long time to come, or redo your work repeatedly.
Cheers.
Actually, most Deisel Electric Locomotives run on DC instead of AC because the system is more reliable. The DC designs require more maintenance (e.g. commutator replacement and adjustment), but the AC regulator components are much more expensive. The failure rate is high enough that the DC design is still superior.
One other factor that is a problem for the AC design is the volume of RF noise they generate. If you happen to have the radio on when one is close by, you can hear the motor turning over in the noise (complete with little variations in the speed that correlate nicely with what you hear from the loco itself), and you cant hear the station you were lisening to.
I'd vote for DC designs for a while.
not and eq existed in the very *first* implementation of LISP on an IBM705. That's, what, 1965? EQ always tested object identity ((eq a b) iff a and b both reference the same address), which in every LISP I'm familiar with ammounts to address equality.
IMHO dates from long before ichat. It doesn't quite predate me, but does predate my first session at a keyboard (circa 1980). In the days of dial-up bulletin boards and USENET News via uucp, modems were slow, and those acronyms were just the thing to get the point across quickly. If you were reading usenet, you knew what they meant. Some of us old timers still use them reflexively. I find myself explaining them occasionally -- but then I point to the Jargon File, and say RTFM. (apologies, ESR, if this slashdots you...)
I'm using pdflatex for a collection of technical documents that run to in excess of 2000 pages each. I'm using epstopdf to make pdf images for inclusion. It works well except for a group of engineers that can't be bothered to actually set their save options.
The documents are heavily cross-referenced and indexed. One group insists on using MS Word and Acrobat Distiller. At this time, the documents cannot be produced with hyperlinks enabled -- Distiller often runs for upwards of a day without completing. When it does finish, the hyperlink boxes are shifted slightly.
Using pdflatex, I can manufacture the same document in just under 10 minutes, and it has all the hyperlinks, and they're properly placed.
When I'm writing parts of this document, I give no thought to formatting, but I do mark up for semantic content.
PDFLaTeX is the only way I can stay sane with documents that big.
My WORD! The useless *BONDAGE*! There is a serious disconnect between UML models and C++ code that makes reverse engineering an impossible task for all but the simplest data models. The problem boils down to the fact that a UML relationship type can be implemented in a number of different ways. Similarly, a particular construct in C++ can represent several different UML relationship types. This leads to a many-to-many mapping of C++ coding constructs onto UML relationships.
I also had a tough time getting Rose to generate a reasonable skeleton when using STL containers. It never seemed to construct the proper container declaration, or place it in the right scope.
Most of the code it produced would have been hopelessly ineffecient, and I could never convince the tool to change its ways. Tech support didn't understand C++ well enough to understand (a) what I was talking about, and (b) why it was a problem.
After struggling with the tool for most of a year, *trying* to make it work, I finally ripped the code out, stripped the Rose comments, and started making real progress.
We now use Doc++ to document the design, and that works much much better. The only thing I miss are the UML diagrams. That last statement is telling: The UML diagrams did a great job of describing complex data structures (of which we have several), but the tool could not generate code to implement the UML diagram that was reasonable.
I hope you have better luck, but I'd be prepared for much disappointment, unless your project is a small one.
I know this thread should really be dead, but I have to respond. I'm not confused at all. I know in great detail what I'm talking about. Here's the scoop:
Hash tables have *amortized* constant time lookup, but worst case behaviour is linear. There are two basic approaches to hash table construction, and they degrade in slightly different ways.
Open coded hash tables use (something like) a vector of cells indexed by the hash value. If there is a collision, you rehash (compute a new and different hash) or scan for an open cell and use that. In either case, you keep going till you find something. This leads to linear scan on a nearly full table. Maintaining these requires the rehashing process you describe.
Bucket hash tables used a list in each cell. You hash to the cell, then scan the list. In this case, an over-full hash-table has long lists to scan. Again, linear in the worst case.
In both cases, we're assuming a good hash function. One easy way to get poor performance out of a hash table is to have a poorly performing hash function.
Now, with respect to the STL, the issue for the designers was, in fact, worst case performance; not expected case performance. Call it a design guideline if you will, but that is what they used as a criterion.
So, as I said in my earlier post, Hash tables were not in the standard because they have poor *WORST CASE* performance. Never-the-less, the good folks at SGI have produced several high-quality hash table implementations that are STL compatable (so have I, for that matter). At some future time, I expect that those hash tables will be added to the STL because they are quite useful, when used properly.
There are several good works on the topic. Knuth's "Art..." being the seminal work on complexity. He covers both types of hash tables in detail in volume 3. I also recall a paper by Stepanov discussing both the ideas behind the STL and the tradeoffs. It's fairly old -- circa 1990 or so IIRC.
Actually, the sorted containers are implemented using red-black trees. Hash tables are not used in the sorted containers because the performance of a hash function can't be guaranteed.
Iterating over the leaf nodes is the same cost as iterating over a list. Finding an element with a known key value is logN for the sorted containers while the same operation in a list is linear.
don't tell me the answer -- i don't have enough spare cycles to answer quickly, and i'm not done yet... :)
One might as well ask why anyone would bother building a working Babbage Difference Engine, yet it has been done (and the sucker works too!). I suppose the rationale for building a trebucet is slightly more obvious (throwing things a long distance).
Hack value has its own sweet savor.
I'm not sure how minor the variations would be. Last I knew, all fuel cells were based on the 2H+O->H2O, where the -> also produces a current. There was research on other types of fuel cells that could "burn" (e.g. oxidize to produce a current) methane (say) in this same manner, but i don't recall any success. What has worked is a process where a hydrocarbon (like methane or gasoline) is cracked to produce H2 and a residue, usually CO2, but sometimes with a quanity of CO as well.
That said, the thing that has to change to burn another fuel is the cracking catalyst. I suspect that the methane catalyst is the easiest to handle, since the operating temperature is reasonably close to room temperature, as opposed to gasoline cracking catalysts, which operate at much higher temperatures, last I knew (which was 15 years ago -- much may have changed since I was a Chemical Engineer professionally).
Does anyone out there have more recent info on fuel cell technology?
Actually, the archetypal bug was a moth that shorted out a pair of contacts in an early computer. It didn't eat anything. It was just attracted by the light of the tubes and landed in a bad location. Grace Murray Hopper was working on that machine at the time. IIRC, the unfortunate moth was duely taped into the log book.
Steel (and Iron for that matter) have a number of differenty possible crystal structures, which vary widely in the strentgh, maleability and brittleness. The rusting rate also changes, but that is not interesting in this context, but it is for the design of blades and tooling. The oldest way to change the crystal structure of iron or steel is to heat it up to a certain temperature, then cool it in a controlled way. Fast cooling leads to a hard brittle structure, slower cooling leads to a more malleable structure. Heat the surface and cool it quickly and you've got case-hardened metal in hand. The key thing to remember is (as any blacksmith has experienced at some time or other) iron gets brittle before it gets to the cherry red stage.
I assume that there was both heat-related sag and a brittle region beyond that as you moved farther from the hottest flames. So, it is possible that the metal did, in fact, get brittle and snap in the heat, along with the sagging, leading to a sudden pancake type collapse.
Who would have thought that you needed to plan for hundreds or thousands of gallons of aircraft fuel when sizing fire supression gear in a tower?
Not only did computers exist, Mr. Turing was largely responsible for the design and implemention of one of the first examples that we would recognize as such a machine (with lots of help, as you might imagine). It was/is known as Colussus. IIRC, a restoration/exhibition was begun at Bletchly Park, the home of the Brittish codebreakers during WWII. There are a number of really interesting books on the topic, including "The battle of Wits", and "The Code Book", among others. I also recall that B.P. has a website with some relevant info.
While I generally agree that you need macros in some form, I'll observe that once you have macros with the same expressive power that lisp macros have, you don't need templates anymore. On the other hand, it may be that LISP style macros would prevent the compiler from handling the sort of type matching that C++ templates have (which both lend power, and make them the very devil to implement correctly).
LISP style symbolic manipulation of code permits the construction of special purpose syntax that is closer to the problem at hand, making the code easier to write and understand, provided that the macros are written to make things more clear rather than less. It is certainly true that you can take things too far with LISP-style macro expansion, but you can also go much much farther than you can with any text-preprocessor scheme.
ha == clearly you have not been reading slashdot lately! slashdot really sucks because they don't give equal time to anti-quark doesn't matter engines!!
;-)
This is a really interesting observation, one I had never considered before now, but let me take a run at an explanation:
:)
I notice that trade paperbacks for sf/fantasy/horror/mystery titles seem to run from $5 to $12 (usd) for a really long book. CD's, on the other hand, seem to start at $15 and go up, even for short 30 minute releases, unless you want to listen to re-releases of old jazz/classical recordings (like I do) in which case you can find decent CD's for something like $12 for a 70 minute recording. I recently saw a re-release of a Led Zepplin album from 1972 for $17(!).
I read a fiction book once or twice. By contrast, my computer books get read over and over. My wife and daughters will read a good fiction book over and over till the pages start to fall out. I'll listen to the CD's until everyone else is sick of them. I'd guess that the marginal utility of both is about the same, but the CD price is much higher, on average.
I'll also note that few publishers are as flamboyant as the music industry pimps^H^H^H^H^Hpeople.
I think maybe the music lovers feel raped by ticket/cd prices. Imagine that!
Well, it's a theory
right -- after using lm_sensors, you will hang in the bios the next time you boot, nothing works, not even POST.
Just be *very* sure you stay away from the lm_sensors package. Using that on a thinkpad will turn it into an unbootable doorstop. There is a KDE package that uses lm_sensors (sorry -- don't recall the name -- I don't use KDE). The issue is that lm_sensors accesses (reads!) the BIOS data (some of which is live -- hence the sensors name...), causing a series of events that destroy the BIOS data to such an extent that the system will not boot using any know means. A motherboard replacement is the only known cure. The bug is in the BIOS, btw, not lm_sensors, based on the idea that reading data should not alter it.
The linux-thinkpad users have been trying to get this resolved for some time (more than a year, IIRC), and (AFAIK) still no fix, even for newer systems, let alone older ones.
There are a few rough edges yet to be worked out.