The "Procrastination" episode of QI has nailed the culprit as perfectionism. And I agree that it is the reason for not having posted on all the topics that speak to me the most. I find it easier to finish posts on topics I care less about because I'm not worried that I got it "perfect"...
Series P: 12. Procrastination
Wednesday, February 6, 2019
Tuesday, July 4, 2017
Programmers also need Moral Philosophy
I stand corrected; programmers need knowledge of moral philosophy too. I realized this after hearing this BBC story about developers of self-driving cars explicitly asking philosophers for help in formulating which person the car should hit. . . . . .
When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming. It turns out that real programmers doing real software development need the OUGHT side too.
One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules. The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know. The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do. In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).
The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds. These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all. The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.
But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.
So, if a self-driving car hits someone, who OUGHT to have responsibility? The auto maker? The car owner? The car's software developer who programmed its rules? If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit? The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?
But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.
When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming. It turns out that real programmers doing real software development need the OUGHT side too.
Hume's IS/OUGHT Divide
The philosopher David Hume wrote that all statements fall into one of two categories: descriptive statements about "what IS", versus, prescriptive statements about "what OUGHT to be", and one can't judge what ought to be without a clear accurate understanding of what is.One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules. The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know. The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do. In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).
The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds. These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all. The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.
But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.
So, if a self-driving car hits someone, who OUGHT to have responsibility? The auto maker? The car owner? The car's software developer who programmed its rules? If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit? The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?
"Moral" Philosophy
When looking at the language describing the scenarios above, we see words like "action", "choice", "responsibility", "cause", "result", "fault", "innocent", "never", and "more likely to survive". These lead to classic concepts in moral philosophy like Action and Agency, Causation, Free Will vs Determinism, Moral Responsibility vs Moral Luck, Desert (i.e. who deserves what) and Legal Punishment, which are intertwined in the following way; we expect those making decisions to be morally/legally responsible for the consequences of their actions, assuming that they were able to make a free choice.But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.
These are just the tip of the iceberg, but it is worth the study since they provide a language for documenting and explaining your ultimate set of rules as well as making you aware of the many non-trivial scenarios. Lest you programmers think that Philosophy is overkill, take a look at books like "The Pig that Wants to be Eaten" cataloging the many well-known moral paradoxes that result from relying on intuition and gut reactions.
Tuesday, February 9, 2016
Absolutely, Holes are Relative
This blog is normally about what computer programmers can/should learn from philosophers. Occasionally though, there is a posting like this about what philosophers can learn from programmers...
In An Introduction to Ontology[1], there is a discussion about whether holes “exist” (where “exist” has a technical Philosophical meaning). In laying out the pros/cons of defining a hole as a region of space, the (fatal?) flaw with the approach is claimed to be that, when the thing that had the hole in it (say a pair of jeans) moved to the next room, the hole wouldn’t/couldn’t move because it was defined as a particular region of space.
I, as a computer programmer, am left dumbfounded that anyone would make the definition of a hole be an absolute region of space, any more than they would define the geometry of each leg in the jeans as being an absolute region of space.
As modeled in typical vector drawing logic, the legs and the hole would each simply be a “part” of the jeans entity. Each part typically has attributes defining its contents (often simplified to just its color), so the left leg is denim/blue and the hole is void/transparent. Alternatively, the hole can be thought of as a “subtractive” part which simplifies the description of the geometry of things that have holes. (Beware of saying “that just simplifies the math but it isn’t real” because that's what they said when Copernicus noted that the math was simpler if planets orbited the sun rather than everything orbiting the earth).
CAD/CAM systems often model things as having parts known as features[2], which include not only subtractive “passages” (two openings, i.e. holes), but also subtractive “depressions” (one opening, i.e. dents) and subtractive “voids” (zero openings, i.e. completely enclosed). These are in addition to additive “protrusions”, “connectors” and “stand-alone volumes”. Don’t think a protrusion is an entity (or at least a part)? Don’t peninsulas exist?
So, just as no one has a problem with saying that the leg part of the jeans is a cylinder whose location is relative to the parent jeans, there should be no problem saying that the hole is passage relative to the parent left leg (just over the knee). After all, isn’t a hole always a hole in something? (yes, I know there is philosophical debate about this, like everything else).
The real head-scratcher, for me, is why it is apparently so non-obvious to the philosopher, that the textbook on this stuff simply ends the a-hole-is-a-region-of-space discussion with “this theory gets it thoroughly wrong”. There is no mention of “you know, there is a trivial rebuttal to that objection”. But that is why occasionally this blog has posts about what Philosophers can learn from Programmers.
[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] Parametric and Feature-Based CAD/CAM, Shah/Mantyla, 1995, Section 7.3.1 Form Feature Schema
In An Introduction to Ontology[1], there is a discussion about whether holes “exist” (where “exist” has a technical Philosophical meaning). In laying out the pros/cons of defining a hole as a region of space, the (fatal?) flaw with the approach is claimed to be that, when the thing that had the hole in it (say a pair of jeans) moved to the next room, the hole wouldn’t/couldn’t move because it was defined as a particular region of space.
I, as a computer programmer, am left dumbfounded that anyone would make the definition of a hole be an absolute region of space, any more than they would define the geometry of each leg in the jeans as being an absolute region of space.
As modeled in typical vector drawing logic, the legs and the hole would each simply be a “part” of the jeans entity. Each part typically has attributes defining its contents (often simplified to just its color), so the left leg is denim/blue and the hole is void/transparent. Alternatively, the hole can be thought of as a “subtractive” part which simplifies the description of the geometry of things that have holes. (Beware of saying “that just simplifies the math but it isn’t real” because that's what they said when Copernicus noted that the math was simpler if planets orbited the sun rather than everything orbiting the earth).
CAD/CAM systems often model things as having parts known as features[2], which include not only subtractive “passages” (two openings, i.e. holes), but also subtractive “depressions” (one opening, i.e. dents) and subtractive “voids” (zero openings, i.e. completely enclosed). These are in addition to additive “protrusions”, “connectors” and “stand-alone volumes”. Don’t think a protrusion is an entity (or at least a part)? Don’t peninsulas exist?
So, just as no one has a problem with saying that the leg part of the jeans is a cylinder whose location is relative to the parent jeans, there should be no problem saying that the hole is passage relative to the parent left leg (just over the knee). After all, isn’t a hole always a hole in something? (yes, I know there is philosophical debate about this, like everything else).
The real head-scratcher, for me, is why it is apparently so non-obvious to the philosopher, that the textbook on this stuff simply ends the a-hole-is-a-region-of-space discussion with “this theory gets it thoroughly wrong”. There is no mention of “you know, there is a trivial rebuttal to that objection”. But that is why occasionally this blog has posts about what Philosophers can learn from Programmers.
[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] Parametric and Feature-Based CAD/CAM, Shah/Mantyla, 1995, Section 7.3.1 Form Feature Schema
Tuesday, September 29, 2015
No Social Constructs in My Little Town
In Paul Simon’s song “My Little Town”, there is the lyric “everything’s the same in my little town”. This can be contrasted with "the big city" that is cosmopolitan, multicultural, not all the same. It is only when you have the experience of more than one culture that it becomes natural to see that there can be more than one notion of how things are. In Philosophy, when there is one “correct” definition of something, due to it existing in nature, independent of man, it is called a “natural kind”. However, when something only exists because people have agreed to think that it does, that is called a “social construction”. Computer programmers need to be aware that, of the things they have to model in their databases, user interfaces & business models, most are social constructions, and hence, there are many ways to skin a cat, but not arbitrary ways. Two case studies are given that show how programmers can err on either side of the spectrum.
Social Constructs versus Natural Kinds
It is common to consider Natural Kinds to be “discovered”, and Social Constructions to be “invented”. An example of something that only exists because we say it does is money. A Bitcoin (or an ounce of gold, or a piece of paper with $100 printed on it) is worth whatever we say it is, and how many Big Macs can be bought with each is whatever we agree upon. And via the computerized marketplace, we can change our collective mind every microsecond.
Social Constructions are also inherently “relative” to some culture, which means that there can be more than one version of it floating around, and each can be equally valid. A traditional example is the definition of what it means to be a woman. While there are the aspects of womanhood that are controlled by DNA and biology, many aspects are defined by society, and there are many different definitions existing simultaneously.
On the other hand, we believe that atoms exists in nature. We may discover better definitions and understandings of them over time, but those would be mere changes in our knowledge of them, rather than making them an invention. When Europeans thought that swans only came in white, and then found black ones in West Australia, their definition of swan changed, but we still think that swans are in fact a natural species, independent of whether you’re European.
Natural Kinds that Aren’t
There are times that something is thought to be a natural kind, but later realized to not be, for example, planets. We thought that planets existed objectively and independent of our latest definition. We now realize that those orbiting chunks of rock and clouds of gas may exist objectively, but our classifications of “planet” versus “dwarf planet” versus “failed star” do not. I.E. they are arbitrary enough that aliens landing here will likely have different ways of classifying orbiting stuff.
Saving the Phenomena
So, if planets aren’t “real”, where did they come from? An early view of the universe was that everything literally revolved around the earth in a perfect circle, except for a handful of “wanderers”, the original meaning of planet. As we gained more knowledge, we would update our definitions. But we always (if only unconsciously) wanted to “save the phenomena”; in other words, make sure that the new definitions didn’t drop any planets and didn’t add any, otherwise, we would be defining something that did not match our intuitive notion of planets.
Of course, recently that became impossible because we realized that we were either going to have to add hundreds of new “planets”, or, drop Pluto, to be consistent. The more that people tried to keep the original collection, the more it became clear that the collection was based on culture and history rather than an objective category of things in space. Some even say that Jupiter is not really a planet, but a failed star.
Case Study: World Headquarters in My Little Town
The world headquarters of Coca-Cola is in Atlanta, and while a world headquarters would be expected to be pretty cosmopolitan, it is in The South which was traditionally very monoculture, conservative, and religious (which I can say because I grew up there). I was there, on a Y2K project, redesigning data files which were using just 2 digits to represent years (even though the file formats had been specified only two years previously, by the way). During discussions with the developers (all Atlanta locals), it was assumed that there was only one obvious “correct” way to represent dates in a string: mmddyyyy. Having lived overseas, I knew to point out that most of the world doesn’t do it that way, instead using ddmmyyyy, or yyyymmdd (and we did not even get into other calendar systems).
The point is that it was assumed that dates were a natural kind when they are actually very socially constructed. In my little town every thing is the same and therefore looks like the one and only way God intended.
Case Study: Bizarrely Arbitrary User Interface at domain.com
While the concept of “social construction” says that there can be several equally-valid ways of defining some things, do not forget about the “social” part! I.E. you should not create an arbitrary definition that no one actually uses and therefore no one will understand.
On the website of domain.com (a domain name registry provider), there is the domain name registration form which includes a mandatory phone number field. The required format is so bizarre though that it took a chat with customer support to figure out what is was. It turned out to require the phone number to be entered as the fractional portion of a floating point number…let that sink in…floating point notation, with a mandatory leading plus sign and mandatory integer of 1. So, phone number “(123) 456-7890” had to be entered as +1.1234567890 ...AND, to make matters worse, the error message received when it was not entered that way, only said that a legal phone number was required, without explaining what the non-obvious required format was.
When I pressed the support chat operator for an answer to my question, WTF?! , I was told (after some time on hold) that “that was the format that the developers chose”. There was no answer to my question: Of all the phone number formats on the planet, who has ever used that? Apparently it was the culture of domain.com off-shored contract developers with no managers who were engineers enough to review the design.
Friday, July 4, 2014
Programmers also need Moral Philosophy
I stand corrected; programmers need knowledge of moral philosophy too. I realized this after hearing this BBC story about developers of self-driving cars explicitly asking philosophers for help in formulating which person the car should hit.
When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming. It turns out that real programmers doing real software development need the OUGHT side too.
One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules. The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know. The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do. In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).
The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds. These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all. The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.
But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.
So, if a self-driving car hits someone, who OUGHT to have responsibility? The auto maker? The car owner? The car's software developer who programmed its rules? If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit? The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?
But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.
When first starting my project to teach other programmers all the practical concepts I was learning from Philosophy, I focused on ontology, the study of describing the world. Philosophy has 2500 years of study of this topic that computer science naively leaves up to intuition. I thought that only the IS side of Hume's IS/OUGHT divide would be relevant to actual programming. It turns out that real programmers doing real software development need the OUGHT side too.
Hume's IS/OUGHT Divide
The philosopher David Hume wrote that all statements fall into one of two categories: descriptive statements about "what IS", versus, prescriptive statements about "what OUGHT to be", and one can't judge what ought to be without a clear accurate understanding of what is.One of the basic tasks of Philosophy is to try to explain and justify one's intuition and gut reactions via a set of explicit logical rules. The IS side of things worries about the best way to describe and categorize things, and how we can justify that we know what we think we know. The OUGHT side of things worries about rules guiding "moral" decisions, and which rules apply in which situations, and what are the overriding goals of each rule system. In other words, what is the "right" thing to do. In both of these categories, it turns out that our intuitions often result in conflicting answers, thus the need to analyze and sort them out (ahem, easier said than done).
The IS statements are the ones that first come to mind when developing a self-driving car. What IS the terrain, the car speed, the distance to the curb, the position the car in the next lane will be in two seconds. These questions are the kind covered in Artificial Intelligence classes, the ones first needed to be able to drive at all. The ones that let a system detect potential collisions, and formulate the set of options available to avoid them.
But, IS statements don't describe which of those options is the "right one", the choice it OUGHT to make. It is only after you realize that sometimes there is no purely "good" option, no option that leaves everyone unscathed, that you realize you will have to program the car to decide who to hit! How does the poor programmer decide that?! Luckily, some programmers had the wisdom to call a philosopher for help encoding moral rules rather than blindly using their programmer's intuition.
So, if a self-driving car hits someone, who OUGHT to have responsibility? The auto maker? The car owner? The car's software developer who programmed its rules? If a bicycle darts in front of the car, but the action of swerving to avoid an inevitable collision will itself cause a collision with someone else, who OUGHT to be hit? The "at fault" bike? The more-likely-to-survive but "innocent" car in the next lane? Override the "never cross the double yellow line" rule and swerve into oncoming traffic (potentially resulting in a chain reaction)?
"Moral" Philosophy
When looking at the language describing the scenarios above, we see words like "action", "choice", "responsibility", "cause", "result", "fault", "innocent", "never", and "more likely to survive". These lead to classic concepts in moral philosophy like Action and Agency, Causation, Free Will vs Determinism, Moral Responsibility vs Moral Luck, Desert (i.e. who deserves what) and Legal Punishment, which are intertwined in the following way; we expect those making decisions to be morally/legally responsible for the consequences of their actions, assuming that they were able to make a free choice.But there are debates about whether the ends justifies the means (Consequentialism) versus a bad deed is a bad deed (Deontological Ethics). There are also debates about what the overarching goals should be; the most good for the most people (Utilitarianism) versus the most deserving (Prioritarianism), or the most freedom (Libertarianism), or the most equality (Egalitarianism), etc, etc.
These are just the tip of the iceberg, but it is worth the study since they provide a language for documenting and explaining your ultimate set of rules as well as making you aware of the many non-trivial scenarios. Lest you programmers think that Philosophy is overkill, take a look at books like "The Pig that Wants to be Eaten" cataloging the many well-known moral paradoxes that result from relying on intuition and gut reactions.
Saturday, February 15, 2014
It's about Time, It's about Space
A 1960s TV series theme song began, "It's about time, it's about space...". Some, from Physics to Philosophy, say it's about both, claiming they are each aspects of a single space-time. Computer systems developers need to consider this as they build GIS applications.
Ontology, being the branch of philosophy concerned with describing "what exists", tackles the topics of Space and Time since they are often used to describe things. An Introduction to Ontology[1] devotes a chapter to each. As usual, things are more complicated than our initial intuition expects, and debate continues about different viewpoints. In a nutshell, the following are discussed:
Ontology, being the branch of philosophy concerned with describing "what exists", tackles the topics of Space and Time since they are often used to describe things. An Introduction to Ontology[1] devotes a chapter to each. As usual, things are more complicated than our initial intuition expects, and debate continues about different viewpoints. In a nutshell, the following are discussed:
- Space is usually defined in terms of "regions"
- Space is either absolute or relative.
- Space is either something things "are in", or it is synonymous with the thing itself
i.e. regions only have properties like size and location, versus, a region itself having the property blue if the stuff in it is blue. - Space is either Euclidean or not (i.e. flat or curved)
- Space is either separate from Time, or parts of the same thing: space-time.
While it is recognized that many problems exist with actual databases of geocoded entities, it is usually assumed that they are in the realm of epistemology rather than ontology. In other words, it is assumed the problem is with "our knowledge" due to inaccuracies in the set of GPS coordinates; not that locations don't actually have a definite set of coordinates.
However, not every entity that takes up space has a well-defined and unchanging mapping to a set of GPS coordinates. ZIP codes, for example, are not defined in terms of geography but rather as collections of delivery routes. Another example, as shown in the title insurance case study below, is in real estate legal descriptions. In addition to a knowledge problem caused by ambiguous language used in these descriptions, they can also refer to ephemeral landmarks.
While a naive assumption that space is different than time is often made in data model design, entities like ZIP codes and Legal Descriptions require a time dimension to be completely accurate. It turns out that the mapping of zip codes to postal routes changes several times a year. And landmarks, referred to in property descriptions, can change location and shape over time.
Case Study: TICOR Title Insurance System
The programmers, having a naive notion of how property boundaries were defined, were surprised to see that a common method is “metes and bounds” which uses plain english descriptions using landmarks. E.G. "beginning with a corner at the intersection of two stone walls near an apple tree on the north side of Muddy Creek road one mile above the junction of Muddy and Indian Creeks, north for 150 rods to the end of the stone wall bordering the road, then northwest along a line to a large standing rock on the corner of the property now or formerly belonging to John Smith, thence west 150 rods to the corner of a barn near a large oak tree, thence south to Muddy Creek road, thence down the side of the creek road to the starting point."
OMEX was a startup that was an early pioneer in creating optical disk technology for data storage. It took on a contract to produce a computer system to support TICOR, the largest title insurance company in the U.S. TICOR itself had the contract to keep backup copies of all the real estate transactions filed with Los Angeles county. As a part of archiving copies of the documents, it was free to use the information in them, and hence support its business of providing title insurance.
The computer system was to replace using microfilm photos of the documents with optical disk storage of the images. It would link these images with a structured database of information related to each property. One of the goals of the database was to enable answering basic questions about property locations.
The computer system was to replace using microfilm photos of the documents with optical disk storage of the images. It would link these images with a structured database of information related to each property. One of the goals of the database was to enable answering basic questions about property locations.
As can be seen, it would be difficult to translate this into a collection of GPS coordinates. But even if you did, you would not be done with the problem. Like ZIP codes that change over time, the location and shape of creeks, rivers, etc change over time. Lest you think this is a merely theoretical problem, for centuries, States have sued each other over land ownership due to border rivers migrating over time.
Ultimately, the computer system wound up just using unstructured text fields to contain the legal description rather than the more ambitious GIS database they had originally promised.
[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] A River Runs Thru It, How the States Got Their Shapes, History Channel, 2011
Saturday, April 27, 2013
Form Input Validation and Defeasibility
A major subcategory within Philosophy is the study of Logic. Computer programmers are very familiar with some categories of logic, for example Boolean logic, but they may not be aware of how many different kinds of logic philosophers have come up with in the past 2500 years. While the familiar systems of logic seek to insure their conclusions are absolutely true, there are other logics that do not require this, and they have lessons for programmers.
Aristotle described a system of logic that was so iron-clad, it was 2000 years before philosophers and mathematicians started seriously adding to it. It is famous for defining the syllogism which is a form of deductive logic, where certain conclusions can be mathematically proved to be true as long as the starting premises are true. The prototypical example of a syllogism is:
P1: All men are mortal.
P2: Socrates is a man.
C: Therefore, Socrates is mortal.
As long as the two premises P1 and P2 are true, C is guaranteed to be true.
However, unlike deductive reasoning, everyday situations usually need to come up with conclusions with less than absolute provability. Jurors need to come up with a verdict even though they have not been given iron-clad arguments. One of the several types of reasoning that is not deductive is called defeasible logic.
Many everyday arguments rely on assumptions that are true "all things being equal". For example, if told that birds were being transported in boxes with no lids, you might conclude that there was a large risk that the birds would fly away, and therefore lids were needed. Given what you know, this is a reasonable conclusion. However, those arguments are defeasible, which means that there are other additional statements that could change the conclusion if they were added to the mix. If we add the statement "the birds being transported are penguins", the conclusion that they might fly away would be defeated since penguins can't fly. On the other hand, some arguments are indefeasible. For example, "John is a bachelor therefore John is unmarried" would not be false, no matter what additional statements are made because being unmarried is the very definition of being a bachelor.
It is helpful to know this little distinction between defeasible and indefeasible conclusions, as is shown in the following little case study.
Case Study: Form Input Validation
Aristotle described a system of logic that was so iron-clad, it was 2000 years before philosophers and mathematicians started seriously adding to it. It is famous for defining the syllogism which is a form of deductive logic, where certain conclusions can be mathematically proved to be true as long as the starting premises are true. The prototypical example of a syllogism is:
P1: All men are mortal.
P2: Socrates is a man.
C: Therefore, Socrates is mortal.
As long as the two premises P1 and P2 are true, C is guaranteed to be true.
However, unlike deductive reasoning, everyday situations usually need to come up with conclusions with less than absolute provability. Jurors need to come up with a verdict even though they have not been given iron-clad arguments. One of the several types of reasoning that is not deductive is called defeasible logic.
Many everyday arguments rely on assumptions that are true "all things being equal". For example, if told that birds were being transported in boxes with no lids, you might conclude that there was a large risk that the birds would fly away, and therefore lids were needed. Given what you know, this is a reasonable conclusion. However, those arguments are defeasible, which means that there are other additional statements that could change the conclusion if they were added to the mix. If we add the statement "the birds being transported are penguins", the conclusion that they might fly away would be defeated since penguins can't fly. On the other hand, some arguments are indefeasible. For example, "John is a bachelor therefore John is unmarried" would not be false, no matter what additional statements are made because being unmarried is the very definition of being a bachelor.
It is helpful to know this little distinction between defeasible and indefeasible conclusions, as is shown in the following little case study.
Case Study: Form Input Validation
It is very common for electronic form systems (e.g. a web page order form) to validate the data entered by a user before allowing the form to be processed. In developing a widget framework used for building a collection of online banking applications, there were two levels of form input validation provided. One level caused error messages to be immediately given to the user, and the other level would only display after the user attempted to submit the form.
Knowing the distinction between defeasibility and indefeasibility is the key to knowing which level any particular validation rule should be. For those input strings that are invalid and no additional input will change that, their error status is indefeasible and the user can be notified immediately. For example, if a field requires a number and the user has entered a letter "A", no additional input will make it a legal number.
On the other hand, if a field requires an email address, and the user has entered "foo@", that is invalid because it is not a complete address. However that status is defeasible because more input can change it to a valid value. Therefore the user should not be harassed about it until a submit is attempted.
Saturday, February 2, 2013
What is Philosophy?
Because I am endeavoring to teach ideas from Philosophy to computer programmers, who typically have no background in it, a question I must answer right off the bat is "what IS philosophy?" Here is the answer I provided to a new MOOC "Introduction to Philosophy":
Of course for programmers who will say, "so what does that have to do with me?", I have to quickly add that even thousands of years ago, philosophers already had come up with some really good techniques for describing the world, and being able to justify that those techniques were better than our intuition. So, since a large portion of our work as programmers is to describe the world via our data models, object models, class hierarchies, classification schemes, etc, etc, we would get better at it if we replaced our intuition with techniques philosophers know but we typically havent been taught.
Given that the single word "philosophy" is commonly used to refer to multiple different (albeit related) things, all answers to the question "Q: What is [Western] Philosophy?" actually depend on one: "doing philosophy; the act of philosophizing" which I explain to even children as:A: Being able to answer the question, Why do you think what you think? Why do you believe what you believe?And while you want to be able to answer to someone else's satisfaction, you foremost want to be able to answer to your own satisfaction because you want to know the truth. (BTW, the western bit is "we believe humans are capable of working it out ourselves")All the other things the word philosophy can refer to build on, and depend on, the above. e.g. Philosophy as meaning "the body of knowledge accumulated by those doing philosophy" (which entails history of philosophy, individual ideas, individual philosophers, tools/techniques/criteria for doing it well, favorite topics for philosophizing about, etc, etc) all naturally spring from someone somewhere starting to "do philosophy".
Of course for programmers who will say, "so what does that have to do with me?", I have to quickly add that even thousands of years ago, philosophers already had come up with some really good techniques for describing the world, and being able to justify that those techniques were better than our intuition. So, since a large portion of our work as programmers is to describe the world via our data models, object models, class hierarchies, classification schemes, etc, etc, we would get better at it if we replaced our intuition with techniques philosophers know but we typically havent been taught.
Wednesday, May 2, 2012
Not All Properties Are Created Equal (Part II: Says Who!?)
It is said that Beauty is in the eye of the beholder. If one were developing a data model for Person, there are various properties that might be attached. Unlike some other properties, it might be more self-evident that a property like isBeautiful would be problematic because it begs the question “Says who?”. There is a relationship between a particular beholder and a particular beheld, in which an isBeautiful property would be more appropriately placed. It may even be a many-to-many relationship with multiple values of isBeautiful coming from multiple beholders as in a beauty pageant panel of judges. Or, as in the case study below, the credit grade of a banking customer is actually several grades, coming from different bankers and algorithms over the life of the business relationship, and international banking regulations now mandate their tracking and optimization.
Of the many subcategories of properties that Philosophers have come up with, an important pair are what John Locke named Primary and Secondary Properties (aka Qualities). The distinction between them being that Primary properties are those that are “objective” and “in the object”, while Secondary properties are “subjective” and “in the mind of the perceiver”. Primary properties of an apple would be its mass, shape, size, etc. Secondary properties would be its color, taste, smell, etc.
Again, as with Essential properties, how is this primary/secondary distinction supposed to make me develop differently than I do now?
Of the many subcategories of properties that Philosophers have come up with, an important pair are what John Locke named Primary and Secondary Properties (aka Qualities). The distinction between them being that Primary properties are those that are “objective” and “in the object”, while Secondary properties are “subjective” and “in the mind of the perceiver”. Primary properties of an apple would be its mass, shape, size, etc. Secondary properties would be its color, taste, smell, etc.
That apple isn't really red?
Color is a classic case in point because it seems that color might be objective. There are surely some collection of wavelengths of light reflected off an apple that could be classifiable as “red”. Alas, there are mountains of evidence that color perception depends on the person and the external conditions.
A famous mountain of evidence (sorry, pun intended) is Ayer’s Rock (aka Uluru) in Australia which attracts thousands of tourists to see it dramatically change colors right before their eyes. Over the minutes of sunset or sunrise, “the color” ranges thru black, red, pink, orange, brown, etc.
In the rain it even turns blue and purple...
So, the mountain can’t really have a simple “color” property with a simple single value.
Again, as with Essential properties, how is this primary/secondary distinction supposed to make me develop differently than I do now?
- Model Clarity: Keeping the properties of an entity or class limited to primary qualities helps to insure that your data model will match data models developed by others. You will be more likely to agree on what the properties are in the first place, and, on what data type best represents that property (see Stronger Types below).
- Better Normalization: Your entity database tables are normalized when limiting to Primary properties because those truly are properties of that entity. By recognizing and removing Secondary properties, you won’t be mixing in columns that are really a flattened relationship with some other beholder entity.
- Better Keys: When deciding which properties of an entity are candidates for being part of it’s “key” or “identifier”, it definitely helps to verify they are really objective properties of the entity. Otherwise, they are based on some external beholder & conditions that can change over time, even though the entity itself didn’t change! A drivers license search will fail if a witness’ notion of a suspect’s hair-color doesn’t match the DMV’s notion of that hair-color.
- Data Provenance: Realizing that each value of a secondary property begs the question “says who?”, you need to identify the authority that provided each value for that property. As you can see, there could be anything from a one-to-one to a many-to-many relationship between the original class and the various authorities providing data values. If the answer is “all values of this property come from a single source X”, then that need merely be noted in the documentation. At the other end of the spectrum, there may need to be a sophisticated sub-model just to keep track of the source and circumstances of each of the several values that property could take on for a single object! (see the Basel II banking case study below).
- Stronger Types: Authorities providing data values for secondary properties, usually define entire “types” rather than just values from some universal type. For example, authorities specifying colors usually limit them to a custom collection of colors (i.e. a palette), or even collections of palettes. Ralph Lauren defines many palettes of colors, most with one or more “reds”, but none of them are the same as the “red” of a 1964 Ford Mustang which comes from the small palette of factory colors from Ford for that year. If you need the simplicity of a single universal “red” value then you are looking at defining mappings from one palette to another. Car salesmen do this mapping intuitively by showing you a "cypress pearl"Infiniti when you ask to see either "black" cars, or "green" cars. Do you need that sort of detailed modeling? You do if you are trying to make it easy for customers to find what they want (see the fabric.com case study below).
 |
| 1964 Mustang Factory Colors |
 |
| Ralph Lauren Palette |
Case Study: Basel II Banking Accord
One of the fundamental practices of banks is to keep a certain amount of money in reserve. When taking customer deposits in, and loaning it out to make a profit from the interest charged, there is a danger if all the deposits are handed out as loans. So, a reserve must be kept, but, there is a conflict between larger reserves for more safety and smaller reserves for more profit. Because banks have erred on the side of more profit, over the past several years international banking regulations have added requirements that the amount of reserve be calculated on a more scientific basis, and be optimized over time.
One of the major criteria in determining how much reserve is required, is to base it on the quality of the customers that the bank lends money to, as measured by their credit grades. A credit grade is really just a prediction of how likely a borrower is to pay back a loan, and how much they would leave unpaid if they did default on a loan.
The regulators recognized (though maybe not in these philosophical terms) that “credit grade” is not a primary property of a customer; it is a secondary property based on the grader and the procedure or algorithm used. The Basel II Banking Accord specified that simply keeping track of customer credit grades was not enough. Banks needed to start keeping track of “says who?” and “what did they base it on?”. With this data, it can be verified after the fact which of these predictions of future default panned out. This enables evolving better algorithms and weeding out graders and methods that were not very good.
One of the major criteria in determining how much reserve is required, is to base it on the quality of the customers that the bank lends money to, as measured by their credit grades. A credit grade is really just a prediction of how likely a borrower is to pay back a loan, and how much they would leave unpaid if they did default on a loan.
The regulators recognized (though maybe not in these philosophical terms) that “credit grade” is not a primary property of a customer; it is a secondary property based on the grader and the procedure or algorithm used. The Basel II Banking Accord specified that simply keeping track of customer credit grades was not enough. Banks needed to start keeping track of “says who?” and “what did they base it on?”. With this data, it can be verified after the fact which of these predictions of future default panned out. This enables evolving better algorithms and weeding out graders and methods that were not very good.
Case Study: fabric.com
In the early days of marketing on the web, the start-up fabric.com (since bought by Amazon) was building a web store to sell clearance fabrics and apparel. Like all online retailers, there is the problem of making it easy for the customer to find the products they want. A common approach is to build a web site with a left-column navigation bar containing filter-by-property controls. This works fine for Primary properties, but is more of a problem for Secondary properties.
Alas, if one doesn’t know that there is a difference, one builds all of the filters in the same manner. For fabrics, filtering by the dimensions of the piece being sold is straightforward and effective because it is a primary property. For color however, there are problems because it is a secondary property, and hence opinions differ on how to describe the color.
Look, even though the “color” of a fabric may be in the eye of the beholder, it is an objective fact that the manufacturer described the color as X, right?. How about we use that since we have to pick something?
Well, two big problems:
Alas, if one doesn’t know that there is a difference, one builds all of the filters in the same manner. For fabrics, filtering by the dimensions of the piece being sold is straightforward and effective because it is a primary property. For color however, there are problems because it is a secondary property, and hence opinions differ on how to describe the color.
Look, even though the “color” of a fabric may be in the eye of the beholder, it is an objective fact that the manufacturer described the color as X, right?. How about we use that since we have to pick something?
Well, two big problems:
- All those colorful color descriptions cause an overly large list of colors in the color filter, plus related colors are spread all thru the list (e.g. avocado, green, lime, olive, etc)
- When the customer searches for “green”, she won’t find all those fabrics with the color described as “lime”.
Okay, fine, we are going to have to go to the trouble of mapping each item to a simple set of colors that we pick. So, Mr. Programmer, go set up a set of simple colors in the database so that we can pick the color when we enter these items into inventory. Well, one other big problem:
- While everyone is entitled to their own opinion, some opinions are worth more than others. The programmers did not have the industry experience needed to pick an appropriate set of colors. It was the brick and mortar fabric sellers that knew things like “stripe is a color”! So, it took someone who had experience with what buyers actually ask for to know that along with “green” in the color list, also needed was “green and white stripe” but not the manufacturer’s description “lime and white stripe”. They also knew that, in addition to simple color families like yellow and brown, subtle categories like "gold, “beige”, and “cream” were needed (and in fact the last two combined into a single category). On the other hand the green family did not need to be augmented by “lime” and "avocado" families.
Tuesday, September 21, 2010
Fuzzy Unit Testing, Performance Unit Testing
Because of the topic of testing coming up in my recent post "Is Morality Eating Your Own Dogfood?", it made me finally publish the following notebook entry from 2007...
In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.
Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.
Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.
In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.
Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.
Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.
Tuesday, August 10, 2010
Not All Properties Are Created Equal (Part I: Essentials)
Just a few years ago, I started reading “Philosophy 101” type books and I was immediately surprised at how relevant the ideas were to day to day software development. So relevant, in fact, that an even bigger surprise is that these ideas are not part of the basic computer science curriculum, nor mentioned in technical books & magazines (with the possible exception of graduate level artificial intelligence). The following idea was the first I encountered that made it clear to me that programmers need to know what philosophers already know. It was also my first clue that philosophy has a whole body of knowledge about developing data & object models that computer science books leave up to intuition.
Did you know that 2500 years ago, philosophers like Plato and Aristotle were doing Object-Oriented Analysis and Entity-Relationship Modeling? More surprisingly, they were already more sophisticated than software developers are now! Why? Well, for one thing, they already understood that the properties of an object are not all created equal. Whereas programmers today basically think that a property is a property, even ancient philosophers understood that there are several different categories of properties. And most importantly, only some properties define WHAT something is; the other properties merely describe HOW it is. Embracing this distinction will change the way you carve up the world into classes and relationships, and which attributes you assign to which entities. I have come to feel that creating data models without this distinction is like wearing glasses so out of focus that distinct objects blur together into indistinguishable blobs.
The properties that something must have, in order to be what it is, Philosophy calls Essential properties. Those properties that something may optionally have are called Accidental properties. For example, for you to be a human, you must have human DNA; it is an Essential property. Being named Smith, however, is an Accidental property because you would still be human even if you had a different name or even no name. So, our everyday meaning for “essential” is different than the philosophical meaning. If a client says that the address is an essential part of the customer data, that doesn’t mean that it is Essential in the philosophical sense. In fact, it is not Essential because whatever a “customer” is, it will still be that same kind of thing even if its address changes. The distinction between essential and accidental properties is even embedded into some human languages like Irish where there are two different “is” verbs; “Tá” is used for accidentals like “He is hungry”, but the verb they call The Copula is used for essentials like “He is Hungarian”.
A hallmark of Essential properties is that they are unchanging. An object’s Essential properties can not change without that object becoming a different kind of thing. There is an ancient philosophical paradox of how something can change and yet remain the same. You are different than you were as a child, and yet you are still the same you. As Heraclitus said, "You can’t step into the same river twice because the water is always different." The solution the Greeks came up with was that Accidental properties may change but Essential properties must remain the same (otherwise, a metamorphosis has occurred!). This philosophy is known as Essentialism.
Socrates taught that everything has an “essential nature” that makes it the kind of thing that it is. His pupil, Plato, taught that these essences are manifest in ideal “Forms” of which all objects are mere copies. Plato’s pupil, Aristotle, taught that Essential properties were those that defined a Form, and Accidental properties were those which distinguished one individual object from another of the same kind. Our object-oriented programming notion of Class is analogous to Plato’s Forms. Like a Class, a Form is unchanging and it pre-exists any objects which instantiate it. Naturally, Entity tables are the database equivalent of Forms with their records being the objects.
So, what is using this idea supposed to buy me? I think a case can be made for at least the following:
Did you know that 2500 years ago, philosophers like Plato and Aristotle were doing Object-Oriented Analysis and Entity-Relationship Modeling? More surprisingly, they were already more sophisticated than software developers are now! Why? Well, for one thing, they already understood that the properties of an object are not all created equal. Whereas programmers today basically think that a property is a property, even ancient philosophers understood that there are several different categories of properties. And most importantly, only some properties define WHAT something is; the other properties merely describe HOW it is. Embracing this distinction will change the way you carve up the world into classes and relationships, and which attributes you assign to which entities. I have come to feel that creating data models without this distinction is like wearing glasses so out of focus that distinct objects blur together into indistinguishable blobs.
The properties that something must have, in order to be what it is, Philosophy calls Essential properties. Those properties that something may optionally have are called Accidental properties. For example, for you to be a human, you must have human DNA; it is an Essential property. Being named Smith, however, is an Accidental property because you would still be human even if you had a different name or even no name. So, our everyday meaning for “essential” is different than the philosophical meaning. If a client says that the address is an essential part of the customer data, that doesn’t mean that it is Essential in the philosophical sense. In fact, it is not Essential because whatever a “customer” is, it will still be that same kind of thing even if its address changes. The distinction between essential and accidental properties is even embedded into some human languages like Irish where there are two different “is” verbs; “Tá” is used for accidentals like “He is hungry”, but the verb they call The Copula is used for essentials like “He is Hungarian”.
A hallmark of Essential properties is that they are unchanging. An object’s Essential properties can not change without that object becoming a different kind of thing. There is an ancient philosophical paradox of how something can change and yet remain the same. You are different than you were as a child, and yet you are still the same you. As Heraclitus said, "You can’t step into the same river twice because the water is always different." The solution the Greeks came up with was that Accidental properties may change but Essential properties must remain the same (otherwise, a metamorphosis has occurred!). This philosophy is known as Essentialism.
Socrates taught that everything has an “essential nature” that makes it the kind of thing that it is. His pupil, Plato, taught that these essences are manifest in ideal “Forms” of which all objects are mere copies. Plato’s pupil, Aristotle, taught that Essential properties were those that defined a Form, and Accidental properties were those which distinguished one individual object from another of the same kind. Our object-oriented programming notion of Class is analogous to Plato’s Forms. Like a Class, a Form is unchanging and it pre-exists any objects which instantiate it. Naturally, Entity tables are the database equivalent of Forms with their records being the objects.
So, what is using this idea supposed to buy me? I think a case can be made for at least the following:
- Better definitions of entities, classes, and relationships result because it forces you to weed out all the non-essentials (pun intended). By striving to understand entity essentials, and not just normalizing data tuples, you will be more likely to accurately model the world.
- Better specifications result because there will now be a place to put all those unwritten (even unspoken) assumptions about the nature of the problem domain. Ironically, when gathering requirements and doing analysis, the essential properties of things are often given short shrift because they mostly don't get stored in databases, because.…that's right, they don't change! It is the changeable accidental properties that get stored, with the unchanging essential properties getting buried as hardwired assumptions in the programming logic.
- Better system interoperability results because universal essential data is separated from local accidental data. The integration of data between a customer system and a patient system and an employee system would be much easier if they had modeled the essential entity, which is Person. When customer and patient and employee are recognized as merely accidental roles of a Person, there is an immediate common entity type to synchronize on rather than widely divergent data tables.
- Better identity systems result because life-long identifiers will no longer be confused with changeable properties like names, addresses, and phone numbers.
- Imagine a Person table where we already understand that using the Name column as the primary key is a bad idea, simply because names are not unique. Some are tempted to create a compound key using name plus some other column(s) like address, phone, etc. With an Essentialism perspective it is clear that, while the compound key may be unique for the moment, it is composed of accidental properties and hence can change at any time! Stored references to previous keys will fail. Current keys won’t match future keys.
We want keys using essential attributes that remains fixed for the life-time of the Person. A unique, fixed, objective, essential attribute like the person’s complete DNA sequence would do the trick! However, a government issued tax ID like SSN can be a practical substitute, plus it’s better than a proprietary “customer ID” because it is something that is effectively universal, and therefore can be used to integrate databases from multiple sources.
Lest you think this example is contrived, I witnessed a Top-5-in-the-USA bank design a customer identity system using a key composed of accidental properties rather than SSN because “we have not traditionally collected SSNs” (despite government “know your customer” security laws requiring it!) They had to continually fix their ever-changing data because they only focused on having a “unique key”.
- In tutorials for any technology that uses entities, the example of a “customer” entity is almost cliche. The design of databases, XML schemas, UML diagrams, SOAP messages, Java Classes, etc, etc, have all used it. But when we ponder the essential nature of a “customer”, there is an immediate problem…
Philosophers have devised many systems for organizing “what exists”, and one of the first of their “20 questions” is: Is its essence physical or abstract? Customers can either be a person (a physical thing that exists in time and space), or a corporation (an abstract thing that doesn't exist in space), so, which is it? This is our clue that it isn’t an entity at all. With some thought (and benefit of reading more philosophy), it becomes clear that “customer” is really just a role that different entities can play. It is part of the relationship between that entity acting as customer, client, buyer and that entity acting as vendor, seller, provider.
Sunday, August 8, 2010
Neural Nets, Vagueness, and Mob Behavior
In response to the following question on a philosophy discussion board, I replied with the short essay below and reproduce it here.
This leads to the entire philosophy of "vagueness". i.e. are there yes/no questions that don't have a yes/no answer? Are some things like baldness vague in essence, or, is our knowledge merely incomplete? e.g. we don't know the exact number of hairs on your head, and/or, we don't know/agree on the exact number of hairs that constitutes the "bald" / "not bald" boundary?
NEURAL NETS
My personal conclusion is that there ARE many vague concepts that we have created that are tied to the way our brains learn patterns (and, as a side effect, how we put things into categories). In contrast to rational thought (i.e. being able to demonstrate logically step by step our conclusions), we "perceive" (ala Locke/Hume/Kant) many things without being able to really explain how we did it.
In Artificial Intelligence, there are "neural network" computer programs that simulate this brain-neuron style of learning. They are the programs that learn how to recognize all different variations of a hand-written letter "A" for example. They do not accumulate a list of shapes that are definitely (or are definitely not) an "A", but rather develop a "feel" for "A"-ness with very vague boundaries. They (like our brains) grade a letter as being more or less A-like. It turns out that this technique works much better than attempting to make rational true/false rules to decide. This is the situation that motivates "fuzzy logic" where instead of just true or false answers (encoded as 1 or 0), one can have any number in-between, e.g. 0.38742 (i.e. 38.7% likely to be true).
WISDOM OF THE CROWD?
Because each person has their own individually-trained "neural net" for a particular perception (e.g. baldness, redness, how many beans are in that jar?), we each come up with a different answer when asked about it. However, the answers do cluster (in a bell-curve-like fashion) around the correct answer for things like "how many beans". This is what led Galton to originally think that there was "wisdom in the crowd". This idea has been hailed as one of the inspirations for the new World Wide Web (aka Web 2.0). The old idea was that McDonalds should ask you if "you want fries with that?" to spur sales. The new Web 2.0 idea is that Amazon should ask you if you want this OTHER book based on what other people bought when they bought the book you are about to buy. I.E. the crowd of Amazon customers know what to ask you better than Amazon itself.
The problem is that there are many failures of "crowd wisdom" (as mentioned in that Wikipedia page in the link above). My conclusion is that most people advocating crowd wisdom have not realized that it is limited to "perceptions". Many Web 2.0 sites are asking the crowd instead about rational judgments, expecting them to come up with a better answer than individuals. The idea of democracy (i.e. giving you the right to vote) has been confused with voting guaranteeing the best answer, no matter the question. In fact, Kierkegaard wrote "Against The Crowd" almost 200 years ago where he recognized that individuals act like witnesses to an event, whereas people speaking to (or as a part of) a crowd, speak what we would now call "bullshit" because they are self-consciously part of a crowd. We can see this in the different results of an election primary (a collection of individuals in private voting booths) versus Caucuses where people vote in front of each other.So, Web 2.0 sites (Facebook, MySpace, blog Tag Clouds, etc) that allow people to see the effect on other people of what they are saying, are chronicling mob mentality rather than collecting reliable witness reports.
BTW, I have written several blog posts related to vagueness, for example:
http://existentialprogramming.blogspot.com/2010/03/model-entities-not-just-their-parts.html
"It was then that it became apparent to me that these dilemmas – and indeed, many others – are manifestations of a more general problem that affects certain kinds of decision-making. They are all instances of the so-called ‘Sorites’ problem, or ‘the problem of the heap’. The problem is this: if you have a heap of pebbles, and you start removing pebbles one at a time, exactly at what point does the heap cease to be a heap?"VAGUE CONCEPTS
This leads to the entire philosophy of "vagueness". i.e. are there yes/no questions that don't have a yes/no answer? Are some things like baldness vague in essence, or, is our knowledge merely incomplete? e.g. we don't know the exact number of hairs on your head, and/or, we don't know/agree on the exact number of hairs that constitutes the "bald" / "not bald" boundary?
NEURAL NETS
My personal conclusion is that there ARE many vague concepts that we have created that are tied to the way our brains learn patterns (and, as a side effect, how we put things into categories). In contrast to rational thought (i.e. being able to demonstrate logically step by step our conclusions), we "perceive" (ala Locke/Hume/Kant) many things without being able to really explain how we did it.
In Artificial Intelligence, there are "neural network" computer programs that simulate this brain-neuron style of learning. They are the programs that learn how to recognize all different variations of a hand-written letter "A" for example. They do not accumulate a list of shapes that are definitely (or are definitely not) an "A", but rather develop a "feel" for "A"-ness with very vague boundaries. They (like our brains) grade a letter as being more or less A-like. It turns out that this technique works much better than attempting to make rational true/false rules to decide. This is the situation that motivates "fuzzy logic" where instead of just true or false answers (encoded as 1 or 0), one can have any number in-between, e.g. 0.38742 (i.e. 38.7% likely to be true).
WISDOM OF THE CROWD?
Because each person has their own individually-trained "neural net" for a particular perception (e.g. baldness, redness, how many beans are in that jar?), we each come up with a different answer when asked about it. However, the answers do cluster (in a bell-curve-like fashion) around the correct answer for things like "how many beans". This is what led Galton to originally think that there was "wisdom in the crowd". This idea has been hailed as one of the inspirations for the new World Wide Web (aka Web 2.0). The old idea was that McDonalds should ask you if "you want fries with that?" to spur sales. The new Web 2.0 idea is that Amazon should ask you if you want this OTHER book based on what other people bought when they bought the book you are about to buy. I.E. the crowd of Amazon customers know what to ask you better than Amazon itself.
The problem is that there are many failures of "crowd wisdom" (as mentioned in that Wikipedia page in the link above). My conclusion is that most people advocating crowd wisdom have not realized that it is limited to "perceptions". Many Web 2.0 sites are asking the crowd instead about rational judgments, expecting them to come up with a better answer than individuals. The idea of democracy (i.e. giving you the right to vote) has been confused with voting guaranteeing the best answer, no matter the question. In fact, Kierkegaard wrote "Against The Crowd" almost 200 years ago where he recognized that individuals act like witnesses to an event, whereas people speaking to (or as a part of) a crowd, speak what we would now call "bullshit" because they are self-consciously part of a crowd. We can see this in the different results of an election primary (a collection of individuals in private voting booths) versus Caucuses where people vote in front of each other.So, Web 2.0 sites (Facebook, MySpace, blog Tag Clouds, etc) that allow people to see the effect on other people of what they are saying, are chronicling mob mentality rather than collecting reliable witness reports.
BTW, I have written several blog posts related to vagueness, for example:
http://existentialprogramming.blogspot.com/2010/03/model-entities-not-just-their-parts.html
Sunday, June 6, 2010
Fuzzy Unit Testing, Performance Unit Testing
Because of the topic of testing coming up in my recent post "Is Morality Eating Your Own Dogfood?", it made me finally publish the following notebook entry from 2007...
In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.
Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.
Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.
In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.
Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.
Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.
Wednesday, May 19, 2010
A hole for every component, and every component in its hole
Amongst the surprisingly simple ideas that aren't so simple when thought about Philosophically are holes. There is a small library of publications on what exactly holes are. A summary can be found online in this Stanford Encyclopedia of Philosophy article on the metaphysics of holes. One of the viewpoints it cites is: ‘There is no such thing as a hole by itself’ (Tucholsky, 1930). This reminded me of one of my very first blog posts from 2000 which I reprint here...
There is no such thing as a Component
I maintain that there is no such thing as a Component in the same way that there is no such thing as a donut hole. Just as the donut hole doesn't exist without a donut to define it, a Component doesn't exist without a Framework to define it. Using a printed circuit board as a metaphor for a framework, it's the "sockets", into which IC chips are meant to be plugged, that define components. So called universal or standalone components are meaningless (and certainly useless) without some framework that expects components of the same purpose and interface.
Ok, so what's your point? The point is that too many developers (and books on the subject) think about components as standalone chunks of functionality that can be "glued together" after the fact. They don't realize that the framework has to come first and foremost in conception and design. Szyperski doesn't get around to talking about frameworks until chapter 21 of his Component Software book for heaven's sake.
Even physical components are like this. The prototypical component, the IC chip, always was designed within a family of chips that were meant to work together. They all needed the same voltage levels for zeroes and ones and tri-states, the same amperage levels, the same clock rates, etc, etc. Other families used other voltage levels. The first reusable, interchangeable parts in history were for rifles. They were meant to be easy and quick to replace (as opposed to the hand crafted muskets they were replacing) but they were meant specifically to make rifles!
Rummaging around a garage, you could find all sorts of "widgets" and "gizmos" that you might guess are components of something, but unless you know what framework they were meant to be a part of, they are not good for anything but door stops or paperweights. In other words, random components don't tend to fit together or work together.
Too many people are trying to make "universal" components without realizing that those components still work within some framework that allows them to be put together and communicate with each other. The problem is that other people doing the same thing have defined other "generic" frameworks that are none the less incompatible.
For example, the toys that baby boomers played with when they were young abounded with generic frameworks of universal components: Tinker Toys, Lincoln Logs, Erector Sets, LEGOs. They all had universal components within a generic framework that let you build anything. BUT, you couldn't mix Tinker Toy parts with Erector Set parts (without glue or duct tape).
Ah, you say. That's why I like duct tape, weakly typed, languages like Perl that lets me glue together parts. Also, what about Play-doh?! You could stick anything together with that! Yes, but there was a reason you made bridges out of Erector Sets instead of Play-doh, and the same reasons apply to software systems (but Strong versus Weak typing is another discussion).
Objects versus Components
Until I had this epiphany about components as donut holes, I didn't have a good answer to the question "what's the difference between an object and a component?". I now understand that all objects ARE components, but not all components are objects. The framework that defines a set of components does not have to be an object oriented framework. But all object oriented languages define an object framework. They are generic enough frameworks that any objects programmed in that language may inter-operate with each other. Unfortunately though, as with Tinker Toys and Lincoln Logs, Java objects typically can't interact with Smalltalk objects.
In the Java language there are at least two levels of object framework. There are plain old Java objects (POJOs) and there are so-called JavaBeans. Whereas any property of a POJO can be accessed (assuming its not protected by the "private" keyword) via a fooObject.barProperty syntax, only special properties may be accessed via the JavaBeans framework. JavaBeans are those objects that have defined special property accessor and mutator methods of the form: getBarProperty() and setBarProperty(). "JavaBean" is the name given to any component that works within that specialized framework. To make matters confusing however, it turns out that Javasoft called more than one framework "JavaBeans" (arrgh!). There are even more specialized versions of JavaBeans that are made to work with fancy GUI toolkits. And of course, they caused even further confusion by calling yet another (different) "widget", from yet another (different) framework, a JavaBean: The Enterprise JavaBean! So, without clearly focusing on frameworks, even Javasoft confuses different component types with each other!
The moral? Don't fret that there is no such thing as a truly "universal" component. Don't spend energy trying to build them, or building "single universal" frameworks. Focus on what is needed for your situation and design a well crafted framework first and foremost. If it needs to work with other frameworks (like whatever Microsoft builds that won't integrate with anybody else), understand that framework bridges will be needed. It is the rare case that a mere "socket adapter" will suffice.
Subscribe to:
Posts (Atom)
Posts
