Just get a motion-sensitive flood with 1000W of whatever bulb you want. The impact of 5 minutes of high wattage when you walk outside is minimal compared to leaving a light burning all night.
Hopefully the cheapness and convenience of motion-sensitive fixtures will make the practice of all-night outdoor lighting obsolete, or at least keep them dim until motion is detected.
I actually talked to one of the HR droids at a "10 years of Windows 2000" job, asking them how anyone can have 10 years experience with a 3 1/2 year old OS. . .
These days I take that as a sign that they're not planning on hiring anyone for 6 1/2 years.
I haven't worked there since the 80's, but at that time everything was run on PDP's, with VAXes upstream doing data reduction. It was ancient even for that time, and everything was configured on disk packs that fit into DEC's washing-machine sized hard drives.
The Standardized Wind Tunnel System (SWTS) was run in all the subsonic and transonic tunnels, and we had a contractual obligation to fix any problem within two hours (the $5000/hour cost figure was the reason for that).
The PDP's ran DEC's RSX-11M operating system, which had a file system and a FORTRAN compiler, and not much else. Processes were limited to 64k (or 32k - can't remember), and it was common to daisy-chain processes together, so that one proc would start (or "unstop") the next. If one proc failed, often due to an arithmetic error, someone would have to get in and restart the chain.
It was clunky, but with experienced people and careful documentation, it was highly reliable. However I never found my experience debugging Teledyne RMDU's to be much in demand in the job market.
The warning signs were always really interesting, something like "Do Not Enter - Artillery Fire". This was on my normal route to lunch.
That link is really good; I wasn't aware of an online history. There were always tales of incidents, like this one:
By mid-1975 thousands of blowdowns, during which air was heated above the melting point of steel, had taken their toll. A flange between the nozzle and heater failed, spewing high-pressure gas and incandescent pebbles over a wide area. The tunnel building was damaged severely and numerous fires kindled in the surrounding area, but no one was hurt. Six months later the 3.5-foot tunnel was back in operation.
There's also a section on the Helium tunnel running at Mach 50, BTW.
As the article notes, the 40x80 and the 12' were built during the war. The Ames library has a lot of interesting information in it, ranging from historical documents to books on the FFT.
The 12', also being shut down, was also an interesting beast, operating at several atmospheres in a closed circuit. Someone once calculated that the compressed air had enough stored energy to blow the entire block-sized structure a half mile into the air. It was tested fairly carefully.
The main reason for testing in the high-reynolds, low speed regime is to make sure the damned thing takes off and lands. It doesn't matter how fast it goes in the air; it still has to take off and land in a reasonable distance. This part of flight isn't the most glamorous, but it's the bread and butter of real-flow testing.
As far as "flying the thing for real", it's very hard to get a 3-D picture of the flow around an aircraft in flight, especially if it isn't flyable yet.
It seems like a cheap "this is what really happened" camera would be a boon for people on the road, and insurance companies, etc., would save a lot of litigation of the "I didn't rear end him, he backed into me on the freeway" kind.
I know there's one guy in New York who rides a bike with cameras fore and aft, but I think they're on a conventional portable VTR.
Sounds a lot like Kleinberg's HITS algorithm, circa 1997. Try Teoma for a real-world implementation.
For example, searching a sports-specific Google site for "Giants" would give more importance to pages about the New York or San Francisco Giants and less importance to pages about Jack and the Beanstalk.
Coincidence time: I used the same example in a presentation a couple of years ago to illustrate how subgroupings can be found for a single search term.
Try it on Teoma, and see the various subtopics under "Refine". IIRC each of those is a principal eigenvector of the link matrix.
Topologically speaking, each principal eigenvector corresponds to a more or less isolated subgraph, eg the subgraph for "San Francisco Giants" is not much connected to the nest of links for "They Might Be Giants", and we get a nice list of subtopics.
(I once tried to explain this algorithm to my bosses at my former employer, which is why I have so much free time to type this right now.)
The main performance difference in a main memory DBMS is in the addressing. Systems like Oracle identify a row of data by its tablespace, data file, block, and row number, which means that each reference involves translating the above keys to an address in the cache, and, failing that, doing an I/O to bring the block into memory.
A main-memory DBMS uses pointers to reference data, and requires little translation to access a given row, except that done by the virtual memory system. That's why main-memory DBMS people claim a large performance advantage, even over Oracle running in RAM.
Furthermore, the dangerous Delphic Expanse, likened to the Bermuda Triangle, causes those who enter to "become anatomically inverted (skin on the inside,
organs on the outside)"
Rick Berman has obviously never seen a grown man naked. Or maybe he has, and that's the point.
Since I did that original writeup I've added considerably to what I know about indexing for this sort of thing, and in fact since I submitted this story I've done some work which looks quite encouraging. Rather than post a bunch of replies I'll round up what I can here:
The most promising method for supporting this idea is a full-text index, one which allows any byte sequence in the source to be looked up quickly. That way, a regexp like/ab(le|ility)/ can be matched by finding matches for "ab", then "abl", "able", "abi", etc. An index which allows progressive refinement of the pattern, from "a" to "ab" to "ability", is a big help.
It's also important to know when no longer matches exist, for instance if "ab" has no hits, then "abi" doesn't need to be checked.
The big leap which makes this seem possible is Ferragina and Manzini's FM index. This method takes the size of a full-text index from somewhere around 10 times the source, to around 40%, including the text as well as the indexing. Their algorithm is described in relation to fixed-length patterns, but it's a trivial extension to handle regexp-generated sets of patterns as well.
In the past few weeks I've been working on an implementation of a similar algorithm with possible performance improvements.
So, the short answer is "yes, it's possible". There are a few hitches here and there, but in comparison to what I knew a year ago, it's much more workable than I would have guessed.
Ranking is a separate issue from selection, or gathering raw hits for a query.
Google doesn't have a mind-bendingly better selection system (it's a lot like any other search engine), but their ranking is, of course, their main advantage.
The issue for a search engine like google would be to cut over from a keyword-based inverted index to something a bit more flexible, while maintaining continuity with the current system.
I think it's possible. We have the technology...(cut to six million dollar man intro).
It should be fine for SHEF or any file format. Once one stops expecting bytes to form words, many file types become indexable.
URL's are a good example of difficult-to-parse search targets. At one time I was looking at parsing urls into components and searching those, but even then it was too hard to search with just a fragment.
I agree that the query mix would probably be 99% keywords, and 1% regexp, but sometimes that 1% makes all the difference in usefulness. I think the keyword stuff would work fine also (each keyword qualifies as a regexp, just a really boring one); it would just be an added bonus to be able to do regexp's or any character sequence.
The spam thing is valid, although it's already hazardous to post an email on the web. Try typing your phone number into Google - that's another surprise that most people aren't aware of.
Although you could also search for your own email and find any web page that contains it.
There are a lot of html tag fragments (eg img tags with just part of the src url, href's to a given domain or subsection of a website, etc.) that might be handy to find, at least for technical people.
I share most people's skepticism about regexp's ever becoming mainstream, but it might be a good foundation for value-added services, like finding web pages by color, font, number of images, etc.
Yes, I agree that pathological regexp's are easy to create, but limits on match length and counts are easy to impose.
At the technical level, one indexing method I'm currently looking at (the FM index) has a couple of advantages. First, it is incremental, extending a match one character at a time, and allows backtracking etc. to probe different legs of a regexp. It's also very quick at counting hits at each step, making realtime pruning of query results very easy.
Slashdot Mirror
Just get a motion-sensitive flood with 1000W of whatever bulb you want. The impact of 5 minutes of high wattage when you walk outside is minimal compared to leaving a light burning all night.
Hopefully the cheapness and convenience of motion-sensitive fixtures will make the practice of all-night outdoor lighting obsolete, or at least keep them dim until motion is detected.
I assume it'll just cover the support they provide. After all, if the kernel has any bugs in it, the buyer can return it, right?
For the new Fox reality show, why else?
Yes, but that will all change once they start harvesting energy from people's bodies.
1. Profit!
2. ??
3. Invest billions
4. Come up with dumb idea
IBM perfected this technique in the 80's - PCjr, anyone?
These days I take that as a sign that they're not planning on hiring anyone for 6 1/2 years.
I haven't worked there since the 80's, but at that time everything was run on PDP's, with VAXes upstream doing data reduction. It was ancient even for that time, and everything was configured on disk packs that fit into DEC's washing-machine sized hard drives.
The Standardized Wind Tunnel System (SWTS) was run in all the subsonic and transonic tunnels, and we had a contractual obligation to fix any problem within two hours (the $5000/hour cost figure was the reason for that).
The PDP's ran DEC's RSX-11M operating system, which had a file system and a FORTRAN compiler, and not much else. Processes were limited to 64k (or 32k - can't remember), and it was common to daisy-chain processes together, so that one proc would start (or "unstop") the next. If one proc failed, often due to an arithmetic error, someone would have to get in and restart the chain.
It was clunky, but with experienced people and careful documentation, it was highly reliable. However I never found my experience debugging Teledyne RMDU's to be much in demand in the job market.
You can scale by pushing the air molecules closer together. That's what the 12 foot pressure tunnel (also being shut down) did.
Cryogenic tunnels do the same thing by cooling the gas; it's a bit safer too.
That sucks.
(The fans are downstream from the test section.)
That link is really good; I wasn't aware of an online history. There were always tales of incidents, like this one:
There's also a section on the Helium tunnel running at Mach 50, BTW.
As the article notes, the 40x80 and the 12' were built during the war. The Ames library has a lot of interesting information in it, ranging from historical documents to books on the FFT.
The 12', also being shut down, was also an interesting beast, operating at several atmospheres in a closed circuit. Someone once calculated that the compressed air had enough stored energy to blow the entire block-sized structure a half mile into the air. It was tested fairly carefully.
The main reason for testing in the high-reynolds, low speed regime is to make sure the damned thing takes off and lands. It doesn't matter how fast it goes in the air; it still has to take off and land in a reasonable distance. This part of flight isn't the most glamorous, but it's the bread and butter of real-flow testing.
As far as "flying the thing for real", it's very hard to get a 3-D picture of the flow around an aircraft in flight, especially if it isn't flyable yet.
Apparently this book is out of print, and I had no idea it was so valuable. It's a good collection of original papers from all parts of the spectrum.
It's probably not for beginners, but it has a lot of deeper information, from original sources.
Good source for sig's too.
It seems like a cheap "this is what really happened" camera would be a boon for people on the road, and insurance companies, etc., would save a lot of litigation of the "I didn't rear end him, he backed into me on the freeway" kind.
I know there's one guy in New York who rides a bike with cameras fore and aft, but I think they're on a conventional portable VTR.
The character of Morpheus is based on him.
Not really, but he wrote (co-authored) the book, literally, on matrix algorithms.
Sounds a lot like Kleinberg's HITS algorithm, circa 1997. Try Teoma for a real-world implementation.
Coincidence time: I used the same example in a presentation a couple of years ago to illustrate how subgroupings can be found for a single search term. Try it on Teoma, and see the various subtopics under "Refine". IIRC each of those is a principal eigenvector of the link matrix.Topologically speaking, each principal eigenvector corresponds to a more or less isolated subgraph, eg the subgraph for "San Francisco Giants" is not much connected to the nest of links for "They Might Be Giants", and we get a nice list of subtopics.
(I once tried to explain this algorithm to my bosses at my former employer, which is why I have so much free time to type this right now.)
Yes, RAM has always been a part of every RDBMS.
The main performance difference in a main memory DBMS is in the addressing. Systems like Oracle identify a row of data by its tablespace, data file, block, and row number, which means that each reference involves translating the above keys to an address in the cache, and, failing that, doing an I/O to bring the block into memory.
A main-memory DBMS uses pointers to reference data, and requires little translation to access a given row, except that done by the virtual memory system. That's why main-memory DBMS people claim a large performance advantage, even over Oracle running in RAM.
A slight inaccuracy in the article: Due to fiscal constraints, the challenge phrase has been changed. It is now "Welcome to Burger King, may I take your order?".
Since I did that original writeup I've added considerably to what I know about indexing for this sort of thing, and in fact since I submitted this story I've done some work which looks quite encouraging. Rather than post a bunch of replies I'll round up what I can here:
/ab(le|ility)/ can be matched by finding matches for "ab", then "abl", "able", "abi", etc. An index which allows progressive refinement of the pattern, from "a" to "ab" to "ability", is a big help.
The most promising method for supporting this idea is a full-text index, one which allows any byte sequence in the source to be looked up quickly. That way, a regexp like
It's also important to know when no longer matches exist, for instance if "ab" has no hits, then "abi" doesn't need to be checked.
The big leap which makes this seem possible is Ferragina and Manzini's FM index. This method takes the size of a full-text index from somewhere around 10 times the source, to around 40%, including the text as well as the indexing. Their algorithm is described in relation to fixed-length patterns, but it's a trivial extension to handle regexp-generated sets of patterns as well.
In the past few weeks I've been working on an implementation of a similar algorithm with possible performance improvements.
So, the short answer is "yes, it's possible". There are a few hitches here and there, but in comparison to what I knew a year ago, it's much more workable than I would have guessed.
Ranking is a separate issue from selection, or gathering raw hits for a query.
Google doesn't have a mind-bendingly better selection system (it's a lot like any other search engine), but their ranking is, of course, their main advantage.
The issue for a search engine like google would be to cut over from a keyword-based inverted index to something a bit more flexible, while maintaining continuity with the current system.
I think it's possible. We have the technology...(cut to six million dollar man intro).
It should be fine for SHEF or any file format. Once one stops expecting bytes to form words, many file types become indexable.
URL's are a good example of difficult-to-parse search targets. At one time I was looking at parsing urls into components and searching those, but even then it was too hard to search with just a fragment.
I agree that the query mix would probably be 99% keywords, and 1% regexp, but sometimes that 1% makes all the difference in usefulness. I think the keyword stuff would work fine also (each keyword qualifies as a regexp, just a really boring one); it would just be an added bonus to be able to do regexp's or any character sequence.
The spam thing is valid, although it's already hazardous to post an email on the web. Try typing your phone number into Google - that's another surprise that most people aren't aware of.
Although you could also search for your own email and find any web page that contains it.
There are a lot of html tag fragments (eg img tags with just part of the src url, href's to a given domain or subsection of a website, etc.) that might be handy to find, at least for technical people.
I share most people's skepticism about regexp's ever becoming mainstream, but it might be a good foundation for value-added services, like finding web pages by color, font, number of images, etc.
Yes, I agree that pathological regexp's are easy to create, but limits on match length and counts are easy to impose.
At the technical level, one indexing method I'm currently looking at (the FM index) has a couple of advantages. First, it is incremental, extending a match one character at a time, and allows backtracking etc. to probe different legs of a regexp. It's also very quick at counting hits at each step, making realtime pruning of query results very easy.