Hi Ken,
What you say makes sense in relation to simple deduction. It doesn't project well when deduction gets complicated, or, worse, complex. Deductive thinking only has to get a little bit complicated before the issue of feeling whether one is correct (i.e closure decision to act to recognise completeness/conclusion) becomes more dominant than addressing the logic. That is epistemologically, any non-trivial deductive logic situation becomes inductive logic
You wrote,
' Deduction allows you to rule out any proposed product or service that seems to violate physical, chemical, biological, or technical facts — or facts of other kinds. Deduction also allows you to rule out any proposed product or service that seems to violate well established principles of human behaviour.'
In theory, and at its simplest, this is true. In reality, not so.
Epistemologically, for most deductive logics, unique outcomes can be *in theory* be identified - sometimes not even then, there is no requirement for a deductive logic to result in singular outcomes - or even any conclusive outcome.
In practice, the real challenge of non-trivial deductive logic is of closure, of identifying whether one has completed the logic correctly. For anything other than the simplest logical processes we humans struggle and commonly get incorrect answers.
One example, is what we do adding up a long list of figures. If we feel there might be possibility of an error, we add up again as a check. If the second answer is different from the first, we try for best out of three and so on. (actually, even if the first two were equal it would give no guarantee). Remember adding up numbers is simple purely deductive logic!
Failure in deduction breaks the epistemological claim of deduction over induction.
A classic example of the ways human fail in deduction is the bathtub problem set by Sterman. A review of that and similar failures of deduction logic is found in http://web.mit.edu/jsterman/www/Bathtub.pdf
Software programming is another classic example of deductive logic. Software programming offers a touchstone for measuring the claim of the ability of deductive logic to give us the means to ' rule out any proposed product or service that seems to violate physical, chemical, biological, or technical fact'
Dan Kaminsky recently offered a real world description of the practical issues in dealing with a big deductive logic problem in his work on the glibc DNS vulnerability (see http://dankaminsky.com/2016/02/20/skeleton/ ) which remember is a purely deductive logic....
On glibc and cache Dan wrote, e.g.
' Given that rough summary of the constraints, here’s what I can report. This CVE is easily the most difficult to scope bug I’ve ever worked on, despite it being in a domain I am intimately familiar with. The trivial defenses against cache traversal are easily bypassable; the obvious attacks that would generate cache traversal are trivially defeated. What we are left with is a morass of maybe’s, with the consequences being remarkably dire (even my bug did not yield direct code execution). Here’s what I can say at present time, with thanks to those who have been very generous with their advice behind the scenes.
The attacks do not need to be garbage that could never survive a DNS cache, as they are in the Google PoC. It’s perfectly legal to have large A and AAAA responses that are both cache-compatible and corrupt client memory. I have this working well.
The attacks do not require UDP or EDNS0. Traditional DNS has a 512 byte limit, notably less than the 2048 bytes required. Some people (including me) thought that since glibc doesn’t issue the EDNS0 request that declares a larger buffer, caching resolvers would not provide sufficient data to create the required failure state. Sure, if the attack was constrained to UDP as in the Google PoC. But not only does TCP exist, but we can set the tc “Truncation” bit to force an upgrade to the protocol with more bandwidth. This most certainly does traverse caches.
There are ways of making the necessary retry occur, even through TCP. We’re still investigating them, as it’s a fundamental requirement for the attack to function. (No retry, no big write to small buf....
Where I think we’re going to end up, around 24 (straight) hours of research in, is that some networks are going to be vulnerable to some cache traversal attacks sometimes, following the general rule of “attacks only get better”. That rule usually only applies to crypto vulns, but on this half-design half-implementation vuln, we get it here too. This is in contrast to the on-path attackers, who “just” need to figure out how to smash a 2016 stack and away they go. ....)'
Pure deductive logic in theory but pure inductive logic in practice.
In real world situations, non-trivial deductive logic issues are in essence inductive logic problems in which 'evidence' is the content and substates of the deductive logic process.
You wrote that you didn't understand what I had written previously. I hope this is a bit more obvious for you.
Best wishes,
Terence
---
Dr Terence Love
PhD(UWA), BA(Hons) Engin. PGCEd, FDRS, PMACM, MISI
Love Services Pty Ltd
PO Box 226, Quinns Rocks
Western Australia 6030
Tel: +61 (0)4 3497 5848
[log in to unmask]
www.loveservices.com.au
--
-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Ken Friedman
Sent: Wednesday, 16 March 2016 5:38 AM
To: PhD-Design <[log in to unmask]>
Subject: Re: Abduction, Induction, and Deduction
Dear Chuck,
Deduction allows you to rule out any proposed product or service that seems to violate physical, chemical, biological, or technical facts — or facts of other kinds. Deduction also allows you to rule out any proposed product or service that seems to violate well established principles of human behaviour. Where anyone suggests that the facts or principles are mistaken, deductive inference should at least require rigorous testing.
You write, “Please give us an example or two of deduction in design so that we can test its logical certainty and understand its necessity.”
Here are a couple of examples that stand out in my mind. I’ll apologise in advance for the fact that these are specific cases: they are examples of specific situations in which deductive analysis should raise warnings.
Some years back, a design firm created a signage system featuring blue letters against a red background. The argument was that blue symbols on a red background were new and exciting. Deductive inference from general principles of legibility and perception suggested that this would not work. It did not, and the project soon had to be replaced. This is also the case for light type against light backgrounds and dark type against dark backgrounds. There are cases where one may wish to use them — if so, they require rigorous testing for the intended purpose and audience.
Another case in point would be services or service systems based on continuous growth or continued user enrolment that exceeds the likely target population. Con artists and financial sharks design pyramid schemes and Ponzi games. Deductive inference allow potential buyers to question or rigorously test these kinds of ventures rather than participating in them. This is also the case for the financial derivatives that make financial markets so risky these days. Rather than spreading and limiting risk, many derivatives increase risk by distancing the assets that provide underlying value from the instruments that should secure them.
A third case is any designed artefact based on perpetual motion or limitless negative entropy. While patent offices no longer accept applications on anything like a perpetual motion engine, people still try to invent them. Deduction from the laws of physics show that this cannot be done. The Irish company Steorn has been ploughing this field over the past decade or so with poor results. While Steorn has submitted products to tests, the tests demonstrate that these products do not work as claimed. This would be another example of deduction that demonstrates what you can’t design — or how you can’t design it.
I agree with the paragraph you quoted on induction.
I disagree with you when you claim that there is no reason to call on deductive inference for design.
Deductive inference allows you to rule out what will not work, or it suggests that you subject the idea to rigorous testing. Deduction requires a stock of useful background knowledge and information — physical, chemical, biological, or technical facts, facts of other kinds, or a stock of knowledge and information in the social and behavioural sciences. Without this, deduction is difficult. The massive failure rate of new products and services, and the massive failure rate of the companies that develop them suggest that many people design or produce products and services without sufficient knowledge or skill.
Invention and creation entail risk. Designing new products or services also involves risk, as does redesigning products and services. There is no way to eliminate risk. I am saying that it may be possible to reduce risk by using all the intellectual and experiential resources at our command. Deductive inference is one such resource.
Designers who solve problems do best when they use multiple methods to reach conclusions, and they reach conclusions best when they test and examine both premisses and outcomes. To do this, abduction, induction, and deduction are all necessary. There is no point in rejecting any useful mode of thought.
Yours,
Ken
Ken Friedman, PhD, DSc (hc), FDRS | Editor-in-Chief | 设计 She Ji. The Journal of Design, Economics, and Innovation | Published by Tongji University in Cooperation with Elsevier | URL: http://www.journals.elsevier.com/she-ji-the-journal-of-design-economics-and-innovation/
Chair Professor of Design Innovation Studies | College of Design and Innovation | Tongji University | Shanghai, China ||| University Distinguished Professor | Centre for Design Innovation | Swinburne University of Technology | Melbourne, Australia
—
Chuck Burnette wrote:
—snip—
You don’t have to go far in
http://plato.stanford.edu/entries/induction-problem/
to get to the essence of my point about deduction.
“Inductive inferences are contingent, deductive inferences are necessary. Deductive inference can never support contingent judgments such as meteorological forecasts, nor can deduction alone explain the breakdown of one's car, discover the genotype of a new virus, or reconstruct fourteenth century trade routes. Inductive inference can do these things more or less successfully because, in Peirce's phrase, inductions are ampliative. Induction can amplify and generalize our experience, broaden and deepen our empirical knowledge. Deduction on the other hand is explicative. Deduction orders and rearranges our knowledge without adding to its content.”
I grant that deduction can be useful after a design expression has become realized, where contingencies have been tentatively resolved, and a formulation set forth as evidence that can be examined to see if criteria have been met, or the process produces the same outcome, given the same expression, or a similar one where variation is controlled as in a comparative test. But for me, and perhaps Terry who often views design as a plan of action, designs are arrived at abstractly (abductively or inductively) even when factual evidence is considered. So in “A Theory of Design Thinking, I interpret Referential and Relational thought as abstract, and Procedural, and Evaluative thought as “ concrete”, that is - causally dependent on the design. For me these two modes are where empirical testing come into play and deductions can be tested. (Formative thought can have either an abstract expression or a concrete one when the artifact has been realized.)
Please give us an example or two of deduction in design so that we can test its logical certainty and understand its necessity.
—snip—
-----------------------------------------------------------------
PhD-Design mailing list <[log in to unmask]> Discussion of PhD studies and related research in Design Subscribe or Unsubscribe at https://www.jiscmail.ac.uk/phd-design
-----------------------------------------------------------------
-----------------------------------------------------------------
PhD-Design mailing list <[log in to unmask]>
Discussion of PhD studies and related research in Design
Subscribe or Unsubscribe at https://www.jiscmail.ac.uk/phd-design
-----------------------------------------------------------------
|
