Monday, March 19, 2007
Eavesdropping nuthatches distinguish danger threats in chickadee alarm calls
http://www.physorg.com/news93544258.html
The false separation between research in brain science and psychology
I was recently in a Psychology Library picking out interesting things to read in journals. It amused me to notice the journals I selected were of 2 types: psychology and brain science. Though both subjects interest me, I was dissatisfied with both, and a little reflection showed me why.
Brain science journals are still studying psychological issues that are too small because that is within the scope of the things they can resolve with brain observations. Psychology journals also tackle issues that are, in a way too small, because that is within the scope of things that can be resolved with the methods of psychological experiments (statistics, questionnaires, etc.). In some way, the issues of psychology journals are interesting, but there is another problem---these journals don't really prove things due to the limitations of their methods.
I also realized the solution.
Brain scientists need to start getting more aggressive and tackle questions of larger scope---similar to the questions psychological philosophers tackle in their books, questions about the nature of perception, conceptualization, decision-making, goal formation, action, etc.
It is true that these experiments will be failed scientific experiments at this time; our scientific knowledge of the brain is not yet strong enough, so these experiments will be over-aggressive, not sufficiently controlled, and fail to prove anything. They might even have trouble getting published in a brain science journal.
But they will yield real, interesting knowledge on significant questions about the mind, and that is what we need.
Brain science journals are still studying psychological issues that are too small because that is within the scope of the things they can resolve with brain observations. Psychology journals also tackle issues that are, in a way too small, because that is within the scope of things that can be resolved with the methods of psychological experiments (statistics, questionnaires, etc.). In some way, the issues of psychology journals are interesting, but there is another problem---these journals don't really prove things due to the limitations of their methods.
I also realized the solution.
Brain scientists need to start getting more aggressive and tackle questions of larger scope---similar to the questions psychological philosophers tackle in their books, questions about the nature of perception, conceptualization, decision-making, goal formation, action, etc.
It is true that these experiments will be failed scientific experiments at this time; our scientific knowledge of the brain is not yet strong enough, so these experiments will be over-aggressive, not sufficiently controlled, and fail to prove anything. They might even have trouble getting published in a brain science journal.
But they will yield real, interesting knowledge on significant questions about the mind, and that is what we need.
I've come up with an idea to allow CAD/CAM designers to backtrack
Recently, I was reading a slightly out of date (perhaps a month old, I'm not sure) NASA Tech Brief article about the biggest outstanding problems facing the designers of CAD/CAM software. NASA Tech Brief, by the way, is a monthly magazine put out by NASA about a variety of extremely cool technical subjects. occasionally the subjects are directly related to space exploration. I suppose all of the articles could be related to space exploration in some way, but most of them, like the CAD/CAM software article, have no particular direct connection to space exploration. There is also an online version of this and both are highly recommended.
One major problem delineated by the CAD/CAM article was that designers like to be able to backtrack to a previous point in the design, but they are generally not able to do so with currently existing software.
I came up with the solution---although I am admittedly not qualified in this area (and perhaps not qualified in any area!)
My idea is to have a "shadow" CAD/CAM hardware/software system that would-be slaved to the main system actually utilized by the user to create the design. This would be a master/slave set up, analogous to a master/slave flip-flop---but instead of the slave system being an inversion of the master system, the slave system would be an identical copy of the Master system.
At the core of this new CAD/CAM system, I presume, would be a pair of microprocessors linked together. Microprocessor 1 would be like an ordinary microprocessor at the core of the CAD/CAM system---except it would output a second stream of signals duplicating each signal in its ordinary output. The ordinary output would interface with the CAD/CAM system in the ordinary way doing things like changing the screen display, changing the data file describing the design, etc.
The second output of microprocessor 1 would be the input to microprocessor 2. Microprocessor 2 would not need to concern itself with user inputs since all of its inputs would come from microprocessor 1. Nor would microprocessor 2 need to concern itself with inputs from the knowledge base of the system, since it would be operating in "simple slave" mode. The main thing microprocessor to would do would be to compile a duplicate design data file, identical to the "real" design data file created by microprocessor 1.
Periodically, microprocessor 2 would rapidly copy the entire current design data file. I can't indicate how frequently such a snapshot would need to be taken because of never done CAD/CAM. All of the snapshots would be stored, thus providing a way for the designer to backtrack.
The tricky part of the system is being able to take the snapshots without screwing up the process all of maintaining an accurate design data file. This would be achieved via the insertion of a variable delay line in the data stream connecting microprocessor one and microprocessor 2. The size of the delay would be controlled by microprocessor 2 depending on how "pressed for time" it was.
Suppose a snap shot was once taken every five minutes. Microprocessor 2 would have the capability of shutting off all output from microprocessor 1 for 2-1/2 minutes, thus allowing the system 2-1/2 minutes to make a complete copy of the current design data file. During this 2-1/2 minute period, the content of the working design data file for microprocessor 2 would be frozen, enabling the copy process to go forward.
Once the copy was completed, microprocessor 2 would start allowing new data to flow into itself and start updating the design data file---for 2-1/2 minutes. Microprocessor 2 would be able to input new data twice as fast as microprocessor 1, thus allowing it to "catch-up" with the 5 minute data gap over the 2-1/2 minute period. Microprocessor 2 would also have the power to accelerate the flow of data through the dateline, enabling the "catch-up."
I can't see any logical flaw in this system. Obviously a large amount of storage space would be required for all these designs. in most cases however once the design of the project was finalized and sent to manufacturing, these various partial design data files could be erased---regaining the storage space. It occurs to me that this type of CAD/CAM system might work best with a dumb terminal directly connected to a server.
One major problem delineated by the CAD/CAM article was that designers like to be able to backtrack to a previous point in the design, but they are generally not able to do so with currently existing software.
I came up with the solution---although I am admittedly not qualified in this area (and perhaps not qualified in any area!)
My idea is to have a "shadow" CAD/CAM hardware/software system that would-be slaved to the main system actually utilized by the user to create the design. This would be a master/slave set up, analogous to a master/slave flip-flop---but instead of the slave system being an inversion of the master system, the slave system would be an identical copy of the Master system.
At the core of this new CAD/CAM system, I presume, would be a pair of microprocessors linked together. Microprocessor 1 would be like an ordinary microprocessor at the core of the CAD/CAM system---except it would output a second stream of signals duplicating each signal in its ordinary output. The ordinary output would interface with the CAD/CAM system in the ordinary way doing things like changing the screen display, changing the data file describing the design, etc.
The second output of microprocessor 1 would be the input to microprocessor 2. Microprocessor 2 would not need to concern itself with user inputs since all of its inputs would come from microprocessor 1. Nor would microprocessor 2 need to concern itself with inputs from the knowledge base of the system, since it would be operating in "simple slave" mode. The main thing microprocessor to would do would be to compile a duplicate design data file, identical to the "real" design data file created by microprocessor 1.
Periodically, microprocessor 2 would rapidly copy the entire current design data file. I can't indicate how frequently such a snapshot would need to be taken because of never done CAD/CAM. All of the snapshots would be stored, thus providing a way for the designer to backtrack.
The tricky part of the system is being able to take the snapshots without screwing up the process all of maintaining an accurate design data file. This would be achieved via the insertion of a variable delay line in the data stream connecting microprocessor one and microprocessor 2. The size of the delay would be controlled by microprocessor 2 depending on how "pressed for time" it was.
Suppose a snap shot was once taken every five minutes. Microprocessor 2 would have the capability of shutting off all output from microprocessor 1 for 2-1/2 minutes, thus allowing the system 2-1/2 minutes to make a complete copy of the current design data file. During this 2-1/2 minute period, the content of the working design data file for microprocessor 2 would be frozen, enabling the copy process to go forward.
Once the copy was completed, microprocessor 2 would start allowing new data to flow into itself and start updating the design data file---for 2-1/2 minutes. Microprocessor 2 would be able to input new data twice as fast as microprocessor 1, thus allowing it to "catch-up" with the 5 minute data gap over the 2-1/2 minute period. Microprocessor 2 would also have the power to accelerate the flow of data through the dateline, enabling the "catch-up."
I can't see any logical flaw in this system. Obviously a large amount of storage space would be required for all these designs. in most cases however once the design of the project was finalized and sent to manufacturing, these various partial design data files could be erased---regaining the storage space. It occurs to me that this type of CAD/CAM system might work best with a dumb terminal directly connected to a server.
Friday, March 9, 2007
Paul Mercer---former iPod guru---takes on the iPhone
Today's New York Times has a story about how Palm has hired Paul Mercer, who was instrumental in developing the iPod, to help Palm compete with the iPhone. ("Palm Responds to the iPhone", p. C7)
This article interested me, so I looked up another article on the Web--- here is a small quote.
"'He is an unusually detail-oriented software engineer," said Steve Capps, a former Apple and Microsoft software engineer, who was one of the designers of the original Macintosh interface and the leader of the Newton project, which created a hand-held computer. "He knows how to architect small pieces of software code.'
"Alliances between small firms and big electronics makers are becoming increasingly common as companies are forced to bring new devices to market practically every season.
"'We're seeing the rise of independent specialists who have a deep understanding of things that big companies don't have the ability to do,' said Paul Saffo, a Silicon Valley consultant who is chairman of Samsung's science board, an advisory group."
"He Helped Build the iPod, Now He Has Built a Rival;" the New York Times, February 27, 2006; http://www.nytimes.com/2006/02/27/technology/27mercer.html?ex=1298696400&en=7ea45081168b7a7f&ei=5090&partner=rssuserland&emc=rss
Here is another reference of some interest I found on Paul Mercer.
"Little-known startup was behind iPod's easy-to-use interface,
Firm's founder now working on the latest handhelds"; San Francisco Chronicle, August 16, 2004; http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/08/16/BUGTG878AR1.DTL
This article interested me, so I looked up another article on the Web--- here is a small quote.
"'He is an unusually detail-oriented software engineer," said Steve Capps, a former Apple and Microsoft software engineer, who was one of the designers of the original Macintosh interface and the leader of the Newton project, which created a hand-held computer. "He knows how to architect small pieces of software code.'
"Alliances between small firms and big electronics makers are becoming increasingly common as companies are forced to bring new devices to market practically every season.
"'We're seeing the rise of independent specialists who have a deep understanding of things that big companies don't have the ability to do,' said Paul Saffo, a Silicon Valley consultant who is chairman of Samsung's science board, an advisory group."
"He Helped Build the iPod, Now He Has Built a Rival;" the New York Times, February 27, 2006; http://www.nytimes.com/2006/02/27/technology/27mercer.html?ex=1298696400&en=7ea45081168b7a7f&ei=5090&partner=rssuserland&emc=rss
Here is another reference of some interest I found on Paul Mercer.
"Little-known startup was behind iPod's easy-to-use interface,
Firm's founder now working on the latest handhelds"; San Francisco Chronicle, August 16, 2004; http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/08/16/BUGTG878AR1.DTL
Subscribe to:
Posts (Atom)