Self Knowledge
Locked
 
|
On 11/27/05, Nicholas Thompson <nickthompson at earthlink.net> wrote:
>So, that is not my CPU telling me about my CPU, right. If not, > who is it and on the basis of what incomplete knowledge is it telling me > what the CPU is doing. Sorry, I saw this after I saw the other. So my response was a but to the left. Here: The CPU (a machine that is a component of a larger machine) has properties that are "exposed" to other parts of the larger machine, so that those other parts can "inspect" those properties. One of these properties is information about what tasks the CPU is being made to work on at any moment, and how much of the CPU's time is being spent on those tasks. SO, it's less the CPU telling about the CPU that it is some other device (made of software) "reading" the properties of the CPU and interpreting the results, and reporting on this interpretation. That the CPU itself participates in this process (by actually running the software that is reading and interpreting the CPU's state information) is potenially confusing and prone to over-interpretaion by philosphically minded folks, but is rather straight-forward (so it seems) to the folks who actually design and build these crazy things. Its like this: you use the car to drive to the garage, so that the car can be diagnosed and repaired. But even though the car, in a sense, participates in it's own caretaking, that doesn't imbue the car with any awareness of itself or capability for self-repair. This is fun. ~~James |
|
|
Nick,
I think the 'real' problem comes to light when one thinks about when the computer gets so sick it can't run the software for a diagnosis or for anything else. Then the diagnostic software systems are useless. So it's only a relatively healthy computing system that can say anything about how well it is. Obviously well enough to respond. If one wants a diagnostic system to operate across the entire range of failures some kind of parallel architecture is implied where one system can act as the 'diagnostician' to the other using a variety of sensors. But then what can be diagnosed is limited by the Subject Matter Expert's (SME) knowledge (usually its incomplete representation of the SME's incomplete knowledge). Many diagnostic systems use precursors to failure to predict a problem is about to get worse. This is the main advantage of diagnostic systems in industrial abnormal situation avoidance. In the abnormal situation there are or are about to be heavy costs: downtime, offspec product, spills, fires, injuries, illnesses, fatalities, environmental impacts, equipment damage, CPU overheating, and so on. So if a computer looks like it's going to overheat, the diagnostic system, using the SME's model on temperature trends, can warn ahead of time. So I think this is a cue. Perhaps the problem is the question of timing. Diagnosing what caused the fatal crash is obviously valuable. Avoiding the fatal crash is perhaps not really the job of a 'diagnostic system', may be we should call them 'prognostic systems' and avoid much confusion? On another tack, when a CPU takes time to figure out how it's spending time on it's tasks (called processes) it's obviously less efficient than one that doesn't. So how does it know (calculate) what time is spent on the task of analyzing task time? Jiggerypokery code springs to my mind! Robert Cordingley www.cirrillian.com James Steiner wrote: >On 11/27/05, Nicholas Thompson <nickthompson at earthlink.net> wrote: > > >>So, that is not my CPU telling me about my CPU, right. If not, >>who is it and on the basis of what incomplete knowledge is it telling me >>what the CPU is doing. >> >> > >Sorry, I saw this after I saw the other. So my response was a but to >the left. Here: > >The CPU (a machine that is a component of a larger machine) has >properties that are "exposed" to other parts of the larger machine, so >that those other parts can "inspect" those properties. One of these >properties is information about what tasks the CPU is being made to >work on at any moment, and how much of the CPU's time is being spent >on those tasks. SO, it's less the CPU telling about the CPU that it is >some other device (made of software) "reading" the properties of the >CPU and interpreting the results, and reporting on this >interpretation. That the CPU itself participates in this process (by >actually running the software that is reading and interpreting the >CPU's state information) is potenially confusing and prone to >over-interpretaion by philosphically minded folks, but is rather >straight-forward (so it seems) to the folks who actually design and >build these crazy things. > >Its like this: you use the car to drive to the garage, so that the car >can be diagnosed and repaired. But even though the car, in a sense, >participates in it's own caretaking, that doesn't imbue the car with >any awareness of itself or capability for self-repair. > >This is fun. > >~~James > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at Mission Cafe >lectures, archives, unsubscribe, maps at http://www.friam.org > > > An HTML attachment was scrubbed... URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20051129/65db330a/attachment.htm |
«
Return to Friam
|
1 view|%1 views
| Free forum by Nabble | Edit this page |