IAAVN (I am a visual neuroscientist, and that's TWICE in one week I've been able to say that on Slashdot!), and happen to have done extensive patent research on this very subject.
There *is* prior art, but a good lawyer should be able to argue around it. In one example, visual sensations of auditory input (ie, sound) were generated by applying electrical stimulation to the outside of the head. Reading through the patent, and surmising how much external electrical stimulation it takes to create an effect inside the skull, one has to wonder if these folks were, ah, a little less concerned about their health and well-being than most. Here's a link to the USPTO.
While there isn't any evidence I'm aware of that pulsing is bad in the visual system (the classical notion that epilepsy is uncontrolled synchronous firing has been brought into question of late), and one of the prevaling theories is that synchroized activity is used to bind object characteristics (eg, color, position, orientation, identification), we do have substantial evidence that the visual system has been very highly tuned for the real world -- that is, with illumination which does not flicker.
Personally, I find that my eyes spend more time trying to microaccommodate (focus) on CRT screens than on LCDs.
Excellent question on fluorescent lighting. It turns out that fluorescent lighting isn't nearly as aggressive as CRT illumination in terms of being pulsed. There are three reasons for this, first fluorescent bulbs -- and we're talking about the classic long tubes, not the newer compact fluorescents which are completely different -- are driven by a sinusoidal current rather than an impulse like the CRT electron beam, so that the pulsation is of lower magnitude. Second, the phosphor on fluorescent bulbs is much slower than that used for CRTs, to help filter out even more of the pulsation. Third, fluorescent bulbs have an effective refresh rate of 120 Hz (both half cycles of the 60 Hz sinusoid activate the phosphor). However, not all fluorescent phosphors are made equal, and in countries where AC power is 50 Hz, you can often see the flicker.
So, to return to the question at hand, will using an LCD monitor make a difference given that you have fluorescent lighting in your environment? Yes, but not as much as if the lighting were incandescent. Is it still worth doing? I'd say so.
What do I personally do? (Does the dentist actually chew Trident?) I use 5 screens total in my professional and personal life, three are LCDs, and two are CRTs running at 85 Hz (this is discounting the screens used for experimentation). The illumination at work is stock institutional fluorescent bulbs which would be full-spectrum if the physical plant staff didn't automatically change them every N months, and at home there's a mix of full-spectrum compact fluorescent (which don't pulse at anything close to a perceptually relevant frequency) and incandescent. I much prefer the LCDs to the CRTs.
IAAVN (I am a Visual Neuroscientist). In our lab we have looked at the effects of CRT versus LCD displays on what's known as the early part of the visual system (retina, LGN, primary visual cortex).
If you accurately measure the luminance from one spot on a CRT screen at sufficiently high time resolution, it looks like a regular series of big spikes followed by exponential decay as the electron beam passes by during each vertical sweep. If the beam passes by sufficiently frequently, our visual system temporally smooths this uneven luminance into what we percieve as a solid image through an effect that's called flicker fusion. Most humans have a flicker fusion rate at about 30 Hz, but there's a broad distribution from individual to individual, and the transition between seeing something that flashes and something that's solid isn't abrupt (further, it depends on contrast ratio, which part of the retina, and a host of other things). But, this is why, in general, CRTs tend to appear to flicker when the refresh rate is at 60 Hz, but not so at 85 Hz or above.
When we record the response of individual neurons in the early visual system, the entrainment of activity to the vertical refresh is striking, and has been found even in higher order visual areas (well beyond the primary visual cortex) at refresh rates as high as 135 Hz with CRTs. In my work, I routinely see responses to 90 Hz flicker in the visual thalamus.
If you examine the luminance from an LCD in the same way, instead of big spikes followed by exponential decay, you see staircases as pixels changes from one luminance to the next through the presentation of whatever is on the display. Recording from early visual neurons in the same circumstances shows a vastly different response characteristic than for the same visual presentation made via CRT (as accurately as we can match it).
This physiological result jibes well with my personal experience that a 60 Hz refresh rate on a CRT is just this side of torture, and while 85 Hz appears solid, 100 Hz has a subtle *more* solid and more pleasant aspect to it. And, further, that any current LCD blows away even an ultra-fast CRT (we use 180 Hz at the upper end) in terms of image stability.
Bottom line: the scientific evidence suggests that unless you want your visual system to be pulsing at CRT refresh rates, get an LCD display.
All along, Intel has been producing chips that are cutting edge in terms of processor clock -- the higher clock speeds they can get out of their lines, the better -- which has entailed, at times, some hoary measures to keep power consumption (barely) in control.
But most people don't need a 2.8 GHz processor that dissipates 100 W. My laptop and one of my desktops are 700 MHz machines, and while not the latest zippiest out there, are perfectly adequate for my needs, and I imagine most peoples'. Not all, but most. But these machines have old processors which were designed whith the best then-available technology which means they have fans, dissipate a ton of power, etc. Why doesn't Intel take all of the new technology and develop a somewhat slower, but much lower power processor line by applying it to the older architectures? Via has tried to go along this path with the C3, but that architecture is too improverished for much more than embedded or applicance use. The Pentium M is a good step in the right direction, but why not push harder?
LEDs are one of the few semiconductors where electromigration is a directly observable effect, and where there's a nice, measureable relationship between operating conditions and lifetime that the casual scientist can see. LEDs are specified with expected initial brightness and a fall-off curve of brightness with age which often drops to 1/2 of the initial luminosity. Run the lamp with less current, and the lifetime curve flattens out; run it with more, and it steepens. All of this because the efficiency depends on the integrity of the P/N junctions which degrade as dopant atoms migrate. Migration, in turn, happens at a rate which depends on applied current and junction temperature.
But, IANASSP (I am not a solid-state physicist) so I might be misremembering my college coursework.
what happens if the AI malfunctions? then mission control will get a bunch of useless error reports...
[sarcasm] Yep, I'm positive that the hundreds if not thousands of PhD-level man hours that went into this part of the project didn't consider that. Yep, took that young whippersnapper Quasar1999 to think about it for a few mintues to evaluate and assess the entire effort and proclaim, "it's a stupid self diagnosis test." [/sarcasm]
If one actually reads the referenced article, it sounds like LV2 is, in fact, something far more advanced than a "stupid self diagnosis test." Se.f-diagnosis tests are pretty straightforward and highly tuned to a specific architecture. I've written something like that to evaluate an experimental compiler, with statements like,
define a=1;
if (a+a eq 2) then print 'simple addition works'
But LV2 is very differnt than that. Into LV2 (which, despite the hype in the article, does not need to be on-board) is built a generic model of satelite functionality customized to the particular device in question. When unexpected results are found, the diagnostic software can experiment on the model, asking questions like, "if, in the model, valve G34 is stuck open, does the model behavior match the current anomalous condition?" I'm sure it wouldn't be hard to write up a test script that could iteratively simulate a fault in one or more parts of the system until it found a handful of likely candidates. Given that there are thousands of components in a satelite, this surely can be done faster by a machine than by a human. Then, were we really trying to do something advanced, we might come up with a way of caching these results to guide future diagnoses and build up a set of experiences. Collect these experiences from different projects (since, if LV2 and its descendent software is widely adopted, the data are presumably in common form), and you can guide designs of future satelites to avoid common failure modes, or identify problematic components.
Now, is that AI? Does it think? You probably wouldn't say so. Could it be an aid to ground-based support? You betcha. Is there a reason to disrespect the fine engineers at NASA by demeaning their efforts without giving fair due? I fail to see one.
Uh, basic physics, people. The Universe is comprised of matter, not anti-matter. You can make anti-matter, but it takes a heapload of energy (recall that E=mc^2 applies to anything that has mass), and you cannot go out and mine anti-matter. Why? Mostly because if there were any antimatter around, it would have a nasty tendency to interact with all that matter and be converted to energy.
So, you can use it to create a nice bomb, but it's equivalent to pumping up a pressurized bottle with a lot of air -- the only energy that's going to come out is the energy that you've put in to create the anti-matter. You make some anti-matter, find a way to confine it and later release it in a controlled fasion and you get a very nice bomb which is incredibly powerful given the mass of the active ingredients. But you cannot use it as an energy source because unlike coal, oil, natural gas and uranium, it isn't freely available: you have to make it.
This is in stark contrast with nuclear fusion and fission: there is lots of available material lying around in the ground and in the seas, just waiting to be extracted and used. While you can find ways of generating anti-matter without putting too much energy into the process (eg, by triggering nuclear decay) you just don't get that much mass very quickly. Unless, of course, you've got a right raging nuclear reaction going, and, then, well, your problems of bomb making are pretty well solved.
I understand that there have been glasses/coatings developed for the US military to protect fighter pilots' eyes in the event of a near-by nuclear explosion. Nuclear explosions emit tremendous amounts of light (for a very brief time): the thought with these coatings/lenses is that a control system would be able to go from transmissive to opaque in microseconds.
Anyone know more about this? It seems to be an ideal solution to the laser-light-through-the-cockpit window problem as well.
My reading-through-the-lines on that one was not that they needed a small fast OS for ICECAM, they needed an OS that would cold boot, communicate with a device, write data to CF, and shutdown, ALL IN 30 SECONDS. No version of Linux or Windows I've seen can do that... but perhaps they do exist. Anyone care to correct me?
The various parts of the retina -- fovea, blind spot, etc -- don't vary much from individual to individual. Also, the brain is very plastic as it's developing such that if the fovea isn't precisely at the axis of the eye, the brain will compensate.
Although as with anything biological it's very difficult to say "X cannot ever happen", I'm not familiar with any cases where the blind spot was at the optical center.
Eye dominance is usually not that much of an issue in tracking, although, you are correct that there are definitely cases where it confounds the issue. Normally there is only a very small difference between where the eyes are pointing and where the subject is actually looking (which is to say, the eyes are usually in agreement, position-wise). There are a host of diseases where this is not true, however, and many people are born with minor congenital conditions where their eyes are slightly askew (strabismus) or don't track exactly in accord.
Unfortunately, I have no recommendations other than to search the web. The systems I've seen thus far have been either full-on commercial systems, or one-off projects done in someone's laboratory.
The basic characteristic of any of them, though, is that you need to zoom in very tight on the subjet's eye -- to the point where the eye fills the entire image.
IAAVR (I am a visual researcher) who professionally studies eye position. We use a number of methods to do this, but one of the easiest and quickest way to measure a person's eye position is to arrange an off-the-shelf video camera with telephoto lens to point at the subject's eye. Plenty of software then exists to extract the iris position and therefore the position of the eye in the orbit, and therefore the point in space where the user is looking. Naturally, a more expensive whiz-bang camera will give you better data, but with a run-of-the-mill consumer grade camera you can do better than 1 degree of accuracy. This sort of thing is already done for quadraplegics.
How do you turn this into a high-resolution image of what the subject is looking at? You point a (better) camera in the opposite direction and either adjust it's position to match, or computationally select out the portion of the image where the subject is looking.
Now, that isn't exactly what these researchers did, but it would be a whole lot easier (and it's what we do on a daily basis).
And, for those who don't have a photography habit, many of the current-issue SLRs (Canons, specifically) already read your eye position with some nifty technology that uses reflections of IR LEDs off your cornea and focuses the camera where you're looking in the frame. (If you haven't used a camera which does this, try it; you'll never go back.)
The point? Technology to read eye position exists, and some of it is pretty old (eg, if you're willing to put a contact lens in your eye, then techniques from the 60s work fine). The ONLY interesting part these people did was to use the reflection off the front surface of the eye (which despite what another poster suggests is very high fidelity if captured with high-quality hardware) and applied the appropriate reflection model to undo the optical distortion of looking in the equivalent of a curved mirror. Think of it this way: if we all wore those mirrored sunglasses from the 70s, despite not having exact eye position information, just approximate gaze direction from head angle, we'd be able to tell more-or-less what each person was looking at.
Back in the day, at MIT's Lab for Computer Science, we were working on a new hardware/software system called Project L. The astute readers here have heard me spout on about this project before, as it was years and years ahead of it's time. (Regrettably, funding issues forced it's early demise.)
One of the goals of this project was to create an extensible, modular multiprocessor computer. The idea was that you would have some commodity hardware which was packaged in neat little blocks that you would snap together. Each neat little block would be more-or-less a fully functional unit, so if you had, say $1000 you could buy a 100-node machine, but if you had $2000, you could buy one twice as big, and hopefully, twice as powerful.
One of our demonstrations of the redundancy concepts involved to achieve this kind of extensibility was to have a four-node L machine running a reasonably long parallel process (realtime spectrographs). In the middle of one such computation, we physically removed half the nodes... and the computation chugged along just fine, completing somewhat more slowly than it would have otherwise. These were not idle nodes, but rather ones intimately involved in the computation. While we, naturally, designed the system to be able to do this, it was actually pretty cool.
Just so happens that IAANB (I am a neurobiologist), and am working just such a system. As one of my friends put it, I am creating "The Matrix".
To be blunt, there's a damned good reason that the various approval boards (such as, but not limited to, the FDA) take a long time to allow such experiments to happen. And right now, the field is still in its experimental infancy, many years away from clinical deployment.
Let's just take a look at some related issues on doing something like this at home: is there a (legal) DIY way to inject arbitrary substances into your blood stream? No. Why? Because it's a good way to cause PERMANENT INJURY OR DEATH, if not from the toxicity of what you inject, then from systemic infection due to poor sterile technique. Is ther a DIY way to, say, change the length of your limbs by inserting extra lengths of bone? Nope. Again, serious issues with PERMANENT INJURY OR DEATH. How about replacing a peripheral organ, like a hand or an eye? PERMANENT INJURY OR DEATH.
Now, you want to do the same thing into your brain, where there is a limited immune system?!? You want to put wires into your body? Into your BRAIN?!? At home? With some kind of inexpensive consumer-grade hardware? Might as well try treating cancer with what you can make up from a child's chemistry set.
Direct brain-machine interfaces are unquestionably best left to professionals. Do not do this at home.
And in academia, we were moving computations across *heterogeneous* architectures mid-flight in the early 90s. That is, we could arrest a computation running on a Sun, move the computation to a Lisp Machine, have it continue for a while, arrest it again, move it to some custom hardware, and so forth. This wasn't just changing where the output was displayed (as in changing one's X terminal while retaining the same central server), but changing where the base computation was happening. For the curious, it was called Project L.
In my experience, the best bosses are those who lead by example. If everyone is required to drink red tea while working, then they're the ones who get big clear mugs and have double servings. Nothing inspires more, IMO.
Re:Convergence of Blogging Sites
on
Meet Joe Blog
·
· Score: 1
There are so many sites out there to support blogging as an individual, and a handful of impressive code to do it more seriously (read: you have to wear a sysadmin's hat from time to time) including Slashcode. It feels like this is a boom period for a new communications mechanism, just like the start of USENET years ago, which will lead to a shaking-out time and establishment of conventions, expectations, and leaders in the field.
Personally, I'm interested to see how commercial interests start to integrate blogging into their daily cycles. Will blogging -- or something like it -- replace email for the standard means of communication, data sharing and document archiving?
Also, it seems that although a large number of attempts have been made to establish cooperative document preparation for the corporate mission, this sort of technology hasn't really made it into mainstream personal use. One might argue that we don't need it, but I think various discussion boards (like Slashdot, Wiki, and the above-mentioned Multiply) are beginning to bring a newer sense of community and cooperative document creation.
Microsoft (theoretically) makes more than $2000 from that advertisement.
Microsoft's books might well have been increased by a few additional sales, some additional mindshare. But my brother's company had $2000 more than it had before when it was very small, allowing them to stay in business, eventually purchase hundreds of servers from VA Linux, I forget how many RedHat 7.2 licenses, which helped both of those companies continue supporting and developing Linux, and so forth. Also, at one point, I think my brother's company's server farm was pretty high up on the biggest-web-servers-of-all list clocking in that many more Apache servers and that many fewer Microsoft.
In all, I think it was possibly the worst $2000 Microsoft ever spent, if you look at the big picture. Sure, MSFT might well have had a positive ROI for that quarter on that one particular sale (then again, since they probably averaged it in with a gazillion other sites as part of a particular advertising campaign, they might well have not made any money on my brother's $2k), but in the long run, it was not in MSFT's best interests.
But just because Microsoft is spending money doesn't mean they're losing money.
Way back in the 90s, my brother banded together a bunch of his friends to start a company and put up a web site. It eventually became one of the leaders in it's field with millions of hits per day (it's a sports site that is now run by one of the big television networks). My brother's a big proponent of open source, he's got an ultra-low Slashdot ID (less than 100), the web sites he's built have all been done under Linux and Perl, and has contributed to various open source projects pretty extensively (eg, xemacs, mysql). When the web site was just big enough to attract advertising, they made a $2000 booking from Microsoft, and I admonished him for doing business with the devil. He replied, "yeah, but the money's flowing in the right direction."
Who among us wouldn't rather money flow from Microsoft rather than to them, especially when the recipient is an open-source advocate?
There are two other reasons the graphs are difficult to read and understand which, if corrected, would obviate the JPEG issue.
1. There is no reason to plot half of the barcharts backwards: the indpendent variable should always be on the vertical axis.
2. Use a larger font, test the images for legibility, AND CORRECT THE PROBLEMS.
By plotting half of the barcharts with the independent variable on the vertical axis, the author reveals that he is either naive, incompetent, or trying to pull a snow job. Since he seemed to put a substantial amount of effort into doing a proper job of benchmarking, I'll give him the benefit of the doubt and say he's merely naive. The Linux Gazette editors should have insisted on fixing this (naivite or barcharts-the-wrong-way, take your pick).
But then, by providing a link to a tar file of the images, and nearly apologizing for their illegibility, the author reveals that he has tested them (or recieved sufficiently many complaints) but is unwilling to correct the source of the problem by using bigger fonts.
While I applaud and commend the efforts to take clean scientific data, the presentation falls a little short.
Slashdot Mirror
IAAVN (I am a visual neuroscientist, and that's TWICE in one week I've been able to say that on Slashdot!), and happen to have done extensive patent research on this very subject.
= PT O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=4,664,117.WKU.&OS=PN/4,664,117&RS =PN/4,664,117
There *is* prior art, but a good lawyer should be able to argue around it. In one example, visual sensations of auditory input (ie, sound) were generated by applying electrical stimulation to the outside of the head. Reading through the patent, and surmising how much external electrical stimulation it takes to create an effect inside the skull, one has to wonder if these folks were, ah, a little less concerned about their health and well-being than most. Here's a link to the USPTO.
http://patft.uspto.gov/netacgi/nph-Parser?Sect1
(If that gets garbled, the patent number is 4,664,117.)
While there isn't any evidence I'm aware of that pulsing is bad in the visual system (the classical notion that epilepsy is uncontrolled synchronous firing has been brought into question of late), and one of the prevaling theories is that synchroized activity is used to bind object characteristics (eg, color, position, orientation, identification), we do have substantial evidence that the visual system has been very highly tuned for the real world -- that is, with illumination which does not flicker.
Personally, I find that my eyes spend more time trying to microaccommodate (focus) on CRT screens than on LCDs.
Excellent question on fluorescent lighting. It turns out that fluorescent lighting isn't nearly as aggressive as CRT illumination in terms of being pulsed. There are three reasons for this, first fluorescent bulbs -- and we're talking about the classic long tubes, not the newer compact fluorescents which are completely different -- are driven by a sinusoidal current rather than an impulse like the CRT electron beam, so that the pulsation is of lower magnitude. Second, the phosphor on fluorescent bulbs is much slower than that used for CRTs, to help filter out even more of the pulsation. Third, fluorescent bulbs have an effective refresh rate of 120 Hz (both half cycles of the 60 Hz sinusoid activate the phosphor). However, not all fluorescent phosphors are made equal, and in countries where AC power is 50 Hz, you can often see the flicker.
So, to return to the question at hand, will using an LCD monitor make a difference given that you have fluorescent lighting in your environment? Yes, but not as much as if the lighting were incandescent. Is it still worth doing? I'd say so.
What do I personally do? (Does the dentist actually chew Trident?) I use 5 screens total in my professional and personal life, three are LCDs, and two are CRTs running at 85 Hz (this is discounting the screens used for experimentation). The illumination at work is stock institutional fluorescent bulbs which would be full-spectrum if the physical plant staff didn't automatically change them every N months, and at home there's a mix of full-spectrum compact fluorescent (which don't pulse at anything close to a perceptually relevant frequency) and incandescent. I much prefer the LCDs to the CRTs.
IAAVN (I am a Visual Neuroscientist). In our lab we have looked at the effects of CRT versus LCD displays on what's known as the early part of the visual system (retina, LGN, primary visual cortex).
If you accurately measure the luminance from one spot on a CRT screen at sufficiently high time resolution, it looks like a regular series of big spikes followed by exponential decay as the electron beam passes by during each vertical sweep. If the beam passes by sufficiently frequently, our visual system temporally smooths this uneven luminance into what we percieve as a solid image through an effect that's called flicker fusion. Most humans have a flicker fusion rate at about 30 Hz, but there's a broad distribution from individual to individual, and the transition between seeing something that flashes and something that's solid isn't abrupt (further, it depends on contrast ratio, which part of the retina, and a host of other things). But, this is why, in general, CRTs tend to appear to flicker when the refresh rate is at 60 Hz, but not so at 85 Hz or above.
When we record the response of individual neurons in the early visual system, the entrainment of activity to the vertical refresh is striking, and has been found even in higher order visual areas (well beyond the primary visual cortex) at refresh rates as high as 135 Hz with CRTs. In my work, I routinely see responses to 90 Hz flicker in the visual thalamus.
If you examine the luminance from an LCD in the same way, instead of big spikes followed by exponential decay, you see staircases as pixels changes from one luminance to the next through the presentation of whatever is on the display. Recording from early visual neurons in the same circumstances shows a vastly different response characteristic than for the same visual presentation made via CRT (as accurately as we can match it).
This physiological result jibes well with my personal experience that a 60 Hz refresh rate on a CRT is just this side of torture, and while 85 Hz appears solid, 100 Hz has a subtle *more* solid and more pleasant aspect to it. And, further, that any current LCD blows away even an ultra-fast CRT (we use 180 Hz at the upper end) in terms of image stability.
Bottom line: the scientific evidence suggests that unless you want your visual system to be pulsing at CRT refresh rates, get an LCD display.
All along, Intel has been producing chips that are cutting edge in terms of processor clock -- the higher clock speeds they can get out of their lines, the better -- which has entailed, at times, some hoary measures to keep power consumption (barely) in control.
But most people don't need a 2.8 GHz processor that dissipates 100 W. My laptop and one of my desktops are 700 MHz machines, and while not the latest zippiest out there, are perfectly adequate for my needs, and I imagine most peoples'. Not all, but most. But these machines have old processors which were designed whith the best then-available technology which means they have fans, dissipate a ton of power, etc. Why doesn't Intel take all of the new technology and develop a somewhat slower, but much lower power processor line by applying it to the older architectures? Via has tried to go along this path with the C3, but that architecture is too improverished for much more than embedded or applicance use. The Pentium M is a good step in the right direction, but why not push harder?
LEDs are one of the few semiconductors where electromigration is a directly observable effect, and where there's a nice, measureable relationship between operating conditions and lifetime that the casual scientist can see. LEDs are specified with expected initial brightness and a fall-off curve of brightness with age which often drops to 1/2 of the initial luminosity. Run the lamp with less current, and the lifetime curve flattens out; run it with more, and it steepens. All of this because the efficiency depends on the integrity of the P/N junctions which degrade as dopant atoms migrate. Migration, in turn, happens at a rate which depends on applied current and junction temperature.
But, IANASSP (I am not a solid-state physicist) so I might be misremembering my college coursework.
what happens if the AI malfunctions? then mission control will get a bunch of useless error reports...
[sarcasm] Yep, I'm positive that the hundreds if not thousands of PhD-level man hours that went into this part of the project didn't consider that. Yep, took that young whippersnapper Quasar1999 to think about it for a few mintues to evaluate and assess the entire effort and proclaim, "it's a stupid self diagnosis test." [/sarcasm]
If one actually reads the referenced article, it sounds like LV2 is, in fact, something far more advanced than a "stupid self diagnosis test." Se.f-diagnosis tests are pretty straightforward and highly tuned to a specific architecture. I've written something like that to evaluate an experimental compiler, with statements like,
define a=1;
if (a+a eq 2) then print 'simple addition works'
But LV2 is very differnt than that. Into LV2 (which, despite the hype in the article, does not need to be on-board) is built a generic model of satelite functionality customized to the particular device in question. When unexpected results are found, the diagnostic software can experiment on the model, asking questions like, "if, in the model, valve G34 is stuck open, does the model behavior match the current anomalous condition?" I'm sure it wouldn't be hard to write up a test script that could iteratively simulate a fault in one or more parts of the system until it found a handful of likely candidates. Given that there are thousands of components in a satelite, this surely can be done faster by a machine than by a human. Then, were we really trying to do something advanced, we might come up with a way of caching these results to guide future diagnoses and build up a set of experiences. Collect these experiences from different projects (since, if LV2 and its descendent software is widely adopted, the data are presumably in common form), and you can guide designs of future satelites to avoid common failure modes, or identify problematic components.
Now, is that AI? Does it think? You probably wouldn't say so. Could it be an aid to ground-based support? You betcha. Is there a reason to disrespect the fine engineers at NASA by demeaning their efforts without giving fair due? I fail to see one.
Uh, basic physics, people. The Universe is comprised of matter, not anti-matter. You can make anti-matter, but it takes a heapload of energy (recall that E=mc^2 applies to anything that has mass), and you cannot go out and mine anti-matter. Why? Mostly because if there were any antimatter around, it would have a nasty tendency to interact with all that matter and be converted to energy.
So, you can use it to create a nice bomb, but it's equivalent to pumping up a pressurized bottle with a lot of air -- the only energy that's going to come out is the energy that you've put in to create the anti-matter. You make some anti-matter, find a way to confine it and later release it in a controlled fasion and you get a very nice bomb which is incredibly powerful given the mass of the active ingredients. But you cannot use it as an energy source because unlike coal, oil, natural gas and uranium, it isn't freely available: you have to make it.
This is in stark contrast with nuclear fusion and fission: there is lots of available material lying around in the ground and in the seas, just waiting to be extracted and used. While you can find ways of generating anti-matter without putting too much energy into the process (eg, by triggering nuclear decay) you just don't get that much mass very quickly. Unless, of course, you've got a right raging nuclear reaction going, and, then, well, your problems of bomb making are pretty well solved.
Easy: it originated in the cockpit.
I understand that there have been glasses/coatings developed for the US military to protect fighter pilots' eyes in the event of a near-by nuclear explosion. Nuclear explosions emit tremendous amounts of light (for a very brief time): the thought with these coatings/lenses is that a control system would be able to go from transmissive to opaque in microseconds.
Anyone know more about this? It seems to be an ideal solution to the laser-light-through-the-cockpit window problem as well.
My reading-through-the-lines on that one was not that they needed a small fast OS for ICECAM, they needed an OS that would cold boot, communicate with a device, write data to CF, and shutdown, ALL IN 30 SECONDS. No version of Linux or Windows I've seen can do that ... but perhaps they do exist. Anyone care to correct me?
Not that I know of, but I'm not an expert on available equipment. Try Google.
The various parts of the retina -- fovea, blind spot, etc -- don't vary much from individual to individual. Also, the brain is very plastic as it's developing such that if the fovea isn't precisely at the axis of the eye, the brain will compensate.
Although as with anything biological it's very difficult to say "X cannot ever happen", I'm not familiar with any cases where the blind spot was at the optical center.
Eye dominance is usually not that much of an issue in tracking, although, you are correct that there are definitely cases where it confounds the issue. Normally there is only a very small difference between where the eyes are pointing and where the subject is actually looking (which is to say, the eyes are usually in agreement, position-wise). There are a host of diseases where this is not true, however, and many people are born with minor congenital conditions where their eyes are slightly askew (strabismus) or don't track exactly in accord.
Sounds like a very interesting project.
Unfortunately, I have no recommendations other than to search the web. The systems I've seen thus far have been either full-on commercial systems, or one-off projects done in someone's laboratory.
The basic characteristic of any of them, though, is that you need to zoom in very tight on the subjet's eye -- to the point where the eye fills the entire image.
EOS 5 (in Europe) or EOS A2E (in the US), EOS Elan IIE, EOS 30, EOS 3, EOS Elan 7E, and probably others that I'm not aware of.
IAAVR (I am a visual researcher) who professionally studies eye position. We use a number of methods to do this, but one of the easiest and quickest way to measure a person's eye position is to arrange an off-the-shelf video camera with telephoto lens to point at the subject's eye. Plenty of software then exists to extract the iris position and therefore the position of the eye in the orbit, and therefore the point in space where the user is looking. Naturally, a more expensive whiz-bang camera will give you better data, but with a run-of-the-mill consumer grade camera you can do better than 1 degree of accuracy. This sort of thing is already done for quadraplegics.
How do you turn this into a high-resolution image of what the subject is looking at? You point a (better) camera in the opposite direction and either adjust it's position to match, or computationally select out the portion of the image where the subject is looking.
Now, that isn't exactly what these researchers did, but it would be a whole lot easier (and it's what we do on a daily basis).
And, for those who don't have a photography habit, many of the current-issue SLRs (Canons, specifically) already read your eye position with some nifty technology that uses reflections of IR LEDs off your cornea and focuses the camera where you're looking in the frame. (If you haven't used a camera which does this, try it; you'll never go back.)
The point? Technology to read eye position exists, and some of it is pretty old (eg, if you're willing to put a contact lens in your eye, then techniques from the 60s work fine). The ONLY interesting part these people did was to use the reflection off the front surface of the eye (which despite what another poster suggests is very high fidelity if captured with high-quality hardware) and applied the appropriate reflection model to undo the optical distortion of looking in the equivalent of a curved mirror. Think of it this way: if we all wore those mirrored sunglasses from the 70s, despite not having exact eye position information, just approximate gaze direction from head angle, we'd be able to tell more-or-less what each person was looking at.
Back in the day, at MIT's Lab for Computer Science, we were working on a new hardware/software system called Project L. The astute readers here have heard me spout on about this project before, as it was years and years ahead of it's time. (Regrettably, funding issues forced it's early demise.)
... and the computation chugged along just fine, completing somewhat more slowly than it would have otherwise. These were not idle nodes, but rather ones intimately involved in the computation. While we, naturally, designed the system to be able to do this, it was actually pretty cool.
One of the goals of this project was to create an extensible, modular multiprocessor computer. The idea was that you would have some commodity hardware which was packaged in neat little blocks that you would snap together. Each neat little block would be more-or-less a fully functional unit, so if you had, say $1000 you could buy a 100-node machine, but if you had $2000, you could buy one twice as big, and hopefully, twice as powerful.
One of our demonstrations of the redundancy concepts involved to achieve this kind of extensibility was to have a four-node L machine running a reasonably long parallel process (realtime spectrographs). In the middle of one such computation, we physically removed half the nodes
Just so happens that IAANB (I am a neurobiologist), and am working just such a system. As one of my friends put it, I am creating "The Matrix".
To be blunt, there's a damned good reason that the various approval boards (such as, but not limited to, the FDA) take a long time to allow such experiments to happen. And right now, the field is still in its experimental infancy, many years away from clinical deployment.
Let's just take a look at some related issues on doing something like this at home: is there a (legal) DIY way to inject arbitrary substances into your blood stream? No. Why? Because it's a good way to cause PERMANENT INJURY OR DEATH, if not from the toxicity of what you inject, then from systemic infection due to poor sterile technique. Is ther a DIY way to, say, change the length of your limbs by inserting extra lengths of bone? Nope. Again, serious issues with PERMANENT INJURY OR DEATH. How about replacing a peripheral organ, like a hand or an eye? PERMANENT INJURY OR DEATH.
Now, you want to do the same thing into your brain, where there is a limited immune system?!? You want to put wires into your body? Into your BRAIN?!? At home? With some kind of inexpensive consumer-grade hardware? Might as well try treating cancer with what you can make up from a child's chemistry set.
Direct brain-machine interfaces are unquestionably best left to professionals. Do not do this at home.
And in academia, we were moving computations across *heterogeneous* architectures mid-flight in the early 90s. That is, we could arrest a computation running on a Sun, move the computation to a Lisp Machine, have it continue for a while, arrest it again, move it to some custom hardware, and so forth. This wasn't just changing where the output was displayed (as in changing one's X terminal while retaining the same central server), but changing where the base computation was happening. For the curious, it was called Project L.
... a good team-lead?
In my experience, the best bosses are those who lead by example. If everyone is required to drink red tea while working, then they're the ones who get big clear mugs and have double servings. Nothing inspires more, IMO.
There are so many sites out there to support blogging as an individual, and a handful of impressive code to do it more seriously (read: you have to wear a sysadmin's hat from time to time) including Slashcode. It feels like this is a boom period for a new communications mechanism, just like the start of USENET years ago, which will lead to a shaking-out time and establishment of conventions, expectations, and leaders in the field.
Personally, I'm interested to see how commercial interests start to integrate blogging into their daily cycles. Will blogging -- or something like it -- replace email for the standard means of communication, data sharing and document archiving?
Also, it seems that although a large number of attempts have been made to establish cooperative document preparation for the corporate mission, this sort of technology hasn't really made it into mainstream personal use. One might argue that we don't need it, but I think various discussion boards (like Slashdot, Wiki, and the above-mentioned Multiply) are beginning to bring a newer sense of community and cooperative document creation.
Microsoft (theoretically) makes more than $2000 from that advertisement.
Microsoft's books might well have been increased by a few additional sales, some additional mindshare. But my brother's company had $2000 more than it had before when it was very small, allowing them to stay in business, eventually purchase hundreds of servers from VA Linux, I forget how many RedHat 7.2 licenses, which helped both of those companies continue supporting and developing Linux, and so forth. Also, at one point, I think my brother's company's server farm was pretty high up on the biggest-web-servers-of-all list clocking in that many more Apache servers and that many fewer Microsoft.
In all, I think it was possibly the worst $2000 Microsoft ever spent, if you look at the big picture. Sure, MSFT might well have had a positive ROI for that quarter on that one particular sale (then again, since they probably averaged it in with a gazillion other sites as part of a particular advertising campaign, they might well have not made any money on my brother's $2k), but in the long run, it was not in MSFT's best interests.
But just because Microsoft is spending money doesn't mean they're losing money.
Excellent point.
Way back in the 90s, my brother banded together a bunch of his friends to start a company and put up a web site. It eventually became one of the leaders in it's field with millions of hits per day (it's a sports site that is now run by one of the big television networks). My brother's a big proponent of open source, he's got an ultra-low Slashdot ID (less than 100), the web sites he's built have all been done under Linux and Perl, and has contributed to various open source projects pretty extensively (eg, xemacs, mysql). When the web site was just big enough to attract advertising, they made a $2000 booking from Microsoft, and I admonished him for doing business with the devil. He replied, "yeah, but the money's flowing in the right direction."
Who among us wouldn't rather money flow from Microsoft rather than to them, especially when the recipient is an open-source advocate?
There are plenty of other ways to publish a blog. My favorite happens to be Multiply because it offers so much more than just straight blogging.
THIS is a case where +10 insightful would be worthwhile.
There are two other reasons the graphs are difficult to read and understand which, if corrected, would obviate the JPEG issue.
1. There is no reason to plot half of the barcharts backwards: the indpendent variable should always be on the vertical axis.
2. Use a larger font, test the images for legibility, AND CORRECT THE PROBLEMS.
By plotting half of the barcharts with the independent variable on the vertical axis, the author reveals that he is either naive, incompetent, or trying to pull a snow job. Since he seemed to put a substantial amount of effort into doing a proper job of benchmarking, I'll give him the benefit of the doubt and say he's merely naive. The Linux Gazette editors should have insisted on fixing this (naivite or barcharts-the-wrong-way, take your pick).
But then, by providing a link to a tar file of the images, and nearly apologizing for their illegibility, the author reveals that he has tested them (or recieved sufficiently many complaints) but is unwilling to correct the source of the problem by using bigger fonts.
While I applaud and commend the efforts to take clean scientific data, the presentation falls a little short.