82,891
edits
Template:M intro design System redundancy: Difference between revisions
Template:M intro design System redundancy (view source)
Revision as of 20:18, 5 August 2023
, 5 August 2023no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary Tags: Mobile edit Mobile web edit |
||
| Line 20: | Line 20: | ||
We have a theory that this “data reductionism” reducing everything to quantisable inputs and outputs — owes tends to a kind of [[reductionism]], only about ''time'': just as radical rationalists see all knowledge as reducible to, and explicable in terms of, its infinitesimally small sub-atomic essence, so the data modernists see it as explicable in terms of infinitesimally small windows of ''time''. | We have a theory that this “data reductionism” reducing everything to quantisable inputs and outputs — owes tends to a kind of [[reductionism]], only about ''time'': just as radical rationalists see all knowledge as reducible to, and explicable in terms of, its infinitesimally small sub-atomic essence, so the data modernists see it as explicable in terms of infinitesimally small windows of ''time''. | ||
This is partly because computer languages don’t do [[tense|''tense'']]: they are coded in the present, and have no frame of reference for continuity. <ref>I have put some thoughts together on that [[Code and language|here]]. I should say this is all my own work and | This is partly because computer languages don’t do [[tense|''tense'']]: they are coded in the present, and have no frame of reference for continuity. Whereas existential continuity backwards and forwards in “time” is precisely the trick that the human brain plays: this is the thing that demands “things”, just one of which is “me”, moving through a spatio-temporal universe, interacting with each other and hence requiring definitive boundaries. <ref>None of these things are necessary, or even coherent, without a sense of continuous time. Hence any [[difference engine]] that can operate wholly without needing a concept of continuity won’t evolve consciousness why would it? I have put some thoughts together on that [[Code and language|here]]. I should say this is all my own work and is likely therefore to be nonsense.</ref> And it is partly because having to cope with history, the passage of time, and the continued existence of objects, makes things exponentially more complex than they already are. An atomically thin snapshot of the world as data is enough of a beast to be still well beyond the operating parameters of even the most powerful quantum machines: that level of detail extending into the future and back from the past is, literally, infinitely more complicated. The modernist programme is to suppose that “time” is really just comprised of billions of infinitesimally thin, static slices, each functionally identical to any other, so by measuring the [[delta]] between them we have a means of handling that complexity. | ||
That is does not have a hope of working seems beside the point. | That is does not have a hope of working seems beside the point. | ||
In any case, just in time rationalisers take a cycle and code for that. What is the process, start to finish, what are the dependencies, what are the plausible unknowns, and how do we optimise for efficiency of movement, components and materials, to manage | In any case, just in time rationalisers take a cycle and code for that. What is the process, start to finish, what are the dependencies, what are the plausible unknowns, and how do we optimise for efficiency of movement, components and materials, to manage | ||
=== It’s the long run, stupid=== | === It’s the long run, stupid=== | ||
The usual approach for system optimisation is to take a snapshot of the process as it is over its lifecycle, and map that against a hypothetical critical path. Kinks and duplications in the process are usually obvious, and we can iron them out to reconfigure the system to be as efficient and responsive as possible. Mapping best case and worst case scenarios for each phase in that life cycle can give good insights into which parts of the process are in need of re-engineering: it is often [[What will it look like?|not the ones we expect]]. | The usual approach for system optimisation is to take a snapshot of the process as it is over its lifecycle, and map that against a hypothetical critical path. Kinks and duplications in the process are usually obvious, and we can iron them out to reconfigure the system to be as efficient and responsive as possible. Mapping best case and worst case scenarios for each phase in that life cycle can give good insights into which parts of the process are in need of re-engineering: it is often [[What will it look like?|not the ones we expect]]. | ||