SynapticNulship

You spend a large portion of your time staring at heads of people. But have you wondered how they evolved? Harvard scientist Daniel Lieberman, Professor of Human Evolutionary Biology, has been studying human head evolution, particularly the unique features relative to other animals.

I attended his lecture at Harvard tonight, “Heads Up! How and Why the Amazing Human Head Evolved to Be the Way It Is,” which is timed with the release of his new book The Evolution of the Human Head.

First, Lieberman took off his shoes. It just snowed again in Cambridge and he doesn’t like wearing his boots (or maybe he has some kind of Mr. Rogers complex).

Second, Lieberman talks about how the functions and ontogeny of the human head would boggle any engineer if they had to make something like that. For instance, it’s hard to imagine how to design and implement a pea-sized robot that grows into a cantaloupe-sized robot while maintaining survival functionality the entire time.

Of course, it’s not an entirely fair comparison since natural products aren’t engineered, but the point is that the head seems overwhelmingly complex to us.

Integration

Not surprisingly (to me), Lieberman’s basic recipe for head development is integration. You can view the development of a body part as a series of interactions with atomic parts, which lie at various levels of granularity. For instance, you have proteins, cells, tissues, organs, etc. All the parts constantly adjust to each other, so as to maintain the overall system.

Lieberman uses the concept of skeletal capsules, but he warns us that it’s just a hypothesis called the functional matrix hypothesis. Some of his past research was to find correlations between various bone structure sizes in mice, and apparently he found a wicked lot of correlations.

He showed two photos of characters from Harry Potter, and claimed that it showed how each person’s nose matches their face. However, it wasn’t very convincing, especially his calling Daniel Radcliffe’s head narrow when it looks really wide to me, like as wide as Elijah Wood’s.

What would have been better is an example of what would happen without the integration between subsystems—would somebody have a nose covering up their eyes or something?

Or the nose would just fall off and run away?

Of course, the environment is also involved in ontogeny—later in the presentation he described an experiment he did with hyraxes, in which they found that if the babies chewed softer food, they had smaller teeth as adults.

Anyway, the way this complex head integration relates to evolution is that it gives evolution something very hackable. It enables evolution to cause major changes in growth from minor tweaks.

The rest of the talk was a quick tour of the evolutionary history of human heads.

Human Head Uniqueness

So what are the aforementioned unusual characteristics of human heads? Well, the brain case is different, our neck comes out of the bottom of our head, we have vertical foreheads, visible eye whites, external nose, no snout, small mouths, small canine teeth, big ear holes, etc.

Unfortunately, Lieberman does not have a good theory for one of the human head’s unique features: the chin. It’s still a mystery.

Image credits:

Robot head: Rodimuspower
Hyrax: Nitzan Cohen Kafri

Cross-posted with Science 2.0.

Every boy should have a journey into the coding wilderness. To prepare yourself for this chronicle, imagine an Australian walkabout, except in the Grid of TRON.

This story begins with my first PC. It was a hand-me-down 286 Turbo, which was 1980s technology (but I got it in the 1990s).

I had used various computers before that (PCs, Apple IIes, Macs, Nintendos, etc.), but it wasn’t until I completely owned one that the real exploring and learning began. When you have your own computer in your room it is truly personal—you have free reign to hack it, break it, fix it, and explore new worlds with wild abandon.

The first development environment I used was the then ancient Microsoft GW-BASIC (which first came out in 1983 and was bundled with MS-DOS). Microsoft got their start with BASIC interpreters (Altair BASIC in 1975) and continued making excellent (for BASIC, that is) IDEs all the way through to the VisualBasic years.

GW-BASIC may look pretty lame compared to pretty much everything that came after it, but it does get points for having a function called TRON (you can see it listed in the function keys at the bottom in the code screenshot above).

The way it happened was I was exploring the programs on the computer and ran GW-BASIC, having no clue what it was. I was presented with a mostly black screen with a prompt, not entirely unlike a DOS prompt. I was not at all impressed and started typing guesses at what the quit command would be. Nothing worked, so I went to find the printed manual and located the command that would quit: SYSTEM, and it worked. But it was too late—I was already reading all the other commands in the manual and immediately set out to make some graphics appear on the screen, and of course try to make video games.

From the get-go, I was coding from scratch. But I found that analyzing and modifying existing source code published in books was a way to accelerate the first phase of learning. The books were usually several years old by the time I got to them—in the 1970s and 1980s they would print BASIC programs in magazines and books and the readers would dutifully type them in and try to run them. Some of those programs were for other dialects, such as on Trash-80s (RadioShack TRS-80) and other 1980s relics, so I had to translate them.

Puberty and Programming

The early to mid 90s were exciting times for me: I was finishing puberty, I was teaching myself to program computers, and the World Wide Web appeared.

At age 14 I got my first legal paid job (of course I had done jobs before that but not official taxed jobs) during the summer with a youth job training council in NH held at the local high school (which I had never seen before, still being in middle school), which then placed me in an accounting office (David L. Connors & Co. in Concord, NH).  I was like an intern, except I didn’t learn that much about accounting because I preferred to spend most of my time making spreadsheet macros as that was the closest to programming I could get there.

They were running Windows 3.11 at the time and once while exploring that I discovered a link to the DOS program QBasic, which was Microsoft’s free subset of QuickBASIC, their much better BASIC system spawned in the 1980s. When you’ve been using GW-BASIC, the QuickBasic family is like a revolutionary jump forward.

For one thing, the IDE is probably the most user friendly DOS program I’ve ever used. I particularly liked the feature showing just one subroutine/function at a time in the buffer (and accessing the list of subs with one key press). In fact, I’ve been wanting that same feature in IDEs ever since but they never have exactly that, and only recently with code folding can I do something that results in equal efficiency. QB also had a built in help system that was useful.

The second thing is the language itself—not only had it grown, but it added intrinsic support for structured programming. Previously, BASIC programs would quickly turn into spaghetti code. You could still write spaghetti of course, but now you could control the insanity better with true subroutines, functions, do loops, data structures, etc. And those damn line numbers were no longer required.

The Golden Years of Basic on the Web

I believe the first BASIC Internet resource I encountered was the ABC (All Basic Code) packets curated by William Yu, which was started in 1995. Soon after, when the web became popular and more people had access, that hobby exploded into hundreds of websites and meta-sites.

A lot of the code was for QuickBasic 4.5 (and the “professional” superset QBX aka PDS 7.1) but there was also code for competitors like PowerBASIC. Some people even started trying to make new BASIC interpreters like DarkBASIC which intrinsicly support the elements needed for making more modern games. (More recently somebody made a cross platform backwards-compatible compiler called QB64). And of course people were sharing the interpreters and compilers.

Whenever an individual shared some tricks or assembly code that extended QuickBASIC, for instance accessing extended memory or outputting WAVs to sound hardware, it would spread through the community quickly. People were making libraries for loading and saving modern image and audio formats, and making games with those libraries that were pretty good considering these were hobbyists using obsolete software.

Games

I made many games myself but never finished any of them. That was ok for a learning phase, but of course eventually I had to learn that completing a project and having closure was also important.

As is usually the case, I also made and/or modified many utilities for making games, for instance graphics editors, bitmapped font editors (and yes I actually made my own bitmapped fonts), a slide-show based game editor with a GUI system I made from scratch, etc.

This playful sandbox of BASIC enthusiasm continued for many years. I was aware of other languages, and had been informed that C was the best general purpose language in engineering industries. However, BASIC was so much fun that I ignored C for a long time. And as one would expect, an interpreter facilitates exploration and learning rapidly as compared to a compiler.

Paradigm Shift

I realized there was something called C++ and assumed that it must be better than old fashioned C. In high school one day I was at a flea market and happened upon a wicked good book deal—three C++ books for $1 each. One of them, Simple C++ by Jeffrey M. Cogswell, is possibly the best programming introduction book ever—it teaches you object oriented programming (OOP) with examples from a fake project to make a robot dog (and it has a sense of humor too). It was an intro to C++, but it did it the right way, via OOP.

I have observed that many others learn C++ the wrong way, as is common in colleges, with almost no emphasis on OOP. When I was in college I took two C++ courses but I did not buy the books we were supposed to. I chose to read more useful books like Industrial Strength C++ by Mats Henricson and Erik Nyquist (for which I raked up some hefty late fees at the library) and Effective C++ by Scott Meyers.

My point, gentle programmers, is that our forefathers of computing started out in the primordial mud of undocumented disorganization, so now us advanced apes live in the Aftermaths…of CHAOS!
—Samuel H. Kenyon, circa 1998

My programming paradigm progression in the 1990s:

⇨ Mostly-chaotic BASIC spaghetti code.
⇨ Structured QuickBasic.
⇨ Object-oriented C++.

So, my personal development recapitulated a path of programming evolution of the late 1960s to the 1980s.

To be continued…

Image credits:

1. Turbo button: Tamas Kemenczy

Transhumanists are into improvements, and many talk about specific problems, for instance Nick Bostrom. However, Bostrom’s problem statements have been criticized for not necessarily being problems, and I think largely this is why one must consider the problem definition (see step #2 below).

Sometimes people talk about their “solutions” for problems, for instance here in H+ Magazine. But in many cases they are actually talking about their ideas of how to solve a problem, or making science-fictional predictions. So if you surf the web, you will find a lot of good ideas about possibly important problems—but a lot of what you find will be undefined (or not very well defined) problem ideas and solutions.

These proposed solutions often do not attempt to find root causes or assume the wrong root cause. And finding a realistic complete plan for solving a problem is rare.

8D (Eight Disciplines) is a process used in various industries for problem solving and process improvement. The 8D steps described below could be very useful for transhumanists, not just for talking about problems but for actually implementing solutions in real life.

Transhuman concerns are complex not just technologically, but also socioculturally. Some problems are more than just “a” problem—they are a dynamic system of problems and the process for problem solving itself is not enough. There has to be management, goals, etc., most of which is outside the scope of this article. But first one should know how deal with a single problem before scaling up, and 8D is a process that can be used on a huge variety of complex problems.

Here are the eight steps of 8D:

1. Assemble the team
2. Define the problem
3. Contain the problem
4. Root cause analysis
5. Choose the permanent solution
6. Implement the solution and verify it
7. Prevent recurrence
8. Congratulate the team

More detailed descriptions:

1. Assemble the Team

With an initial, rough concept of the problem, a team should be assembled to continue the 8D steps. The team will make an initial problem statement without presupposing a solution. They should attempt to define the “gap” (or error)—the big difference between the current problematic situation and the potential fixed situation. The team members should all be interested in closing this gap.

The team must have a leader; this leader makes agendas, synchronizes actions and communications, resolves conflicts, etc. In a company, the team should also have a “sponsor”, who is like a coach from upper management. The rest of the team is assembled as appropriate; this will vary depending on the problem, but some general rules for a candidate can be:

• Has a unique point of view.
• Logistically able to coordinate with the rest of the team.
• Is not committedd to preconceived notions of “the answer.”
• Can actually accomplish change that they might be responsible for.

The size of an 8D team (at least in companies) is typically 5 to 7 people.

The team should be justified. This matters most within an organization that is paying for the team, however even a group of transhumanists out in the wilds of cyberspace will have to defend themselves when people ask, “Why should we care?”

2. Define the Problem

Let’s say somebody throws my robot out of an airplane, and it immediately falls to the ground and breaks into several pieces. This customer then informs me that this robot has a major problem when flying after being dropped from a plane and that I should improve the flying software to fix it.

Here is the mistake: The problem has not been properly defined. The robot is a ground robot and was not intended to fly or be dropped out of a plane. The real problem is that a customer has been misinformed as to the purpose and use of the product.

When thinking about how to improve humanity, or even how to merely improve a gadget, you should consider: Have you made an assumption about the issue that might be obscuring the true problem? Did the problem emerge from a process that was working fine before? What processes will be impacted? If this is an improvement, can it be measured, and what is the expected goal?

The team should attempt to grok the issues and their magnitude. Ideally, they will be informed with data, not just opinions.

Just as with medical diagnosis, the symptoms alone are probably not enough input. There are various ways to collect more data, and which methods you use depends on the nature of the problem. For example, one method is the 5 W’s and 2 H’s:

• Who is affected?
• What is happening?
• When does it occur?
• Where does it happen?
• Why is it happening (initial understanding)?
• How is it happening?
• How many are affected?

For humanity-affecting problems, I think it’s very important to define what the context of the problem is.

3. Contain the Problem

Some problems are urgent, and a stopgap must be put in place while the problem is being analyzed. This is particularly relevant for problems such as product defects which affect customers.

Some brainstorming questions are:

• Can anything be done to mitigate the negative impact (if any) that is happening?
• Who would have to be involved with that mitigation?
• How will the team know that the containment action worked?

Before deploying an interim expedient, the team should have asked and answered these questions (they essentially define the containment action):

• Who will do it?
• What is the task?
• When will it be accomplished?

A canonical example: You have a leaky roof (the problem). The containment action is to put a pail underneath the hole to capture the leaking water. This is a temporary fix until the roof is properly repaired, and mitigates damage to the floor.

Don’t let the bucket of water example fool you—containment can be massive, e.g. corporate bailouts. Of course, the team must choose carefully: Is the cost of containment worth it?

4. Root Cause Analysis

Whenever you think you have an answer to a problem, as yourself: Have you gone deep enough? Or is there another layer below? If you implementt a fix, will the problem grow back?

Generally in the real world events are causal. The point of root cause analysis is to trace the causes all the way back for your problem. If you don’t find the origin of the causes, then the problem will probably rear its ugly head again.

Root cause analysis is one of the most overlooked, yet important, steps of problem solving. Even engineers often lose their way when solving a problem and jump right into a fix which later on turned out to be a red herring.

Typically, driving to root cause follows one of these two routes:

1. Start with data; develop theories from that data.
2. Start with a theory; search for data to support or refute it.

Either way, team members must always remember keep in mind that correlation is not necessarily causation.

One tool to use is the 5 Why’s, in which you move down the “ladder of abstraction” by continually asking: “why?” Start with a cause and ask why this cause is responsible for the gap (or error). Then ask again until you’ve bottomed out with something that may be a true root cause.

There are many other general purpose methods and tools to assist in this stage; I will list some of them here, but please look them up for detailed explanations:

• Brainstorming: Generate as many ideas as possible, and elaborate on the best ideas.
• Process flow analysis: Flowchart a process; attempt to narrow down what element in the flow chart is causing the problem.
• Fishikawa: Use a Fishikawa (aka Cause and Effect) diagram to try narrowing down the cause(s).
• Pareto analysis: Generate a Pareto chart, which may indicate which cause (of many) should be fixed first.
• Data analysis: Use trend charts, scatter plots, etc. to assist in finding correlations and trends.

And that is just the beginning—a problem may need a specific new experiment or data collection method devised.

Ideally you would have a single root cause, but that is not always the case.

The team should also come up with various correction actions that solve the root cause, to be selected and refined in the next step.

5. Choose the Permanent Solution

The solution must be one or more corrective actions that solve the cause(s) of the problem. Corrective action selection is additionally guided by criteria such as time constraints, money constraints, efficiency, etc.

This is a great time to simulate/test the solution, if possible. There might be unaccounted for side effects either in the system you fixed or in related systems. This is especially true for some of the major issues that transhumanists wish to tackle.

You must verify that the corrective action(s) will in fact fix the root cause and not cause bad side effects.

6. Implement the Solution and Verify It

This is the stage when the team actually sets into motion the correction action(s). But doing it isn’t enough—the team also has to check to see if the solution is really working.

For some issues the verification is clean-cut. Some corrective actions have to be evaluated with effectiveness, for instance some benchmark. Depending on the time scale of the corrective action, the team might need to add various monitors and/or controls to continually make sure the root cause is squashed.

7. Prevent Recurrence

It’s possible that a process will revert back to its old ways after the problem has been solved, resulting in the same type of problem happening again. So the team should provide the organization or environment with improvements to processes, procedures, practices, etc. so that this type of problem does not resurface.

8. Congratulate the Team

Party time! The team should share and publicize the knowledge gained from the process as it will help future efforts and teams.

Image credits:
1. Inception (2010), Warner Bros.
2. Peter Galvin
3. Tom Parnell
4. shalawesome

Also published in H+ Magazine.

I improved my TRON:Legacy-esque illuminated vest and added some illuminated leg cladding. Here is a photo of me from last night (New Year’s Eve):

What Worked

This time the vest front and back worked without fail for several hours.  The overall design worked—everybody either understood the TRON reference or thought it was cool even if they had not heard of TRON (yes, there are many people who have no clue what TRON is despite all the advertising).

The leg cladding looked really cool, but it only worked for a few minutes.

What Failed

One point in the EL wire on my left leg right before the knee failed before I even got to the destination.  After a while the EL wire next to that one also broke.  Since the leg cladding was one long wire, this caused my entire trousers to be conspicuously not shining.

So I had to walk around and dance with a bunch of cardboard strapped to my legs for no reason.

Human factors of crotch access: Another problem with the cyber trousers ensemble is due to rushing at the last minute I used just one long wire for both legs instead of two.  This resulted in an illuminated wire going straight across my fly, a clear violation of human factors.  After all, I would be drinking and that will inevitably result in needing to urinate, and hence needing to open my fly. Also if I wanted to illuminate my crotch I could come up with a much more attractive scheme than a wire going straight across.  So my quick fix was to cover it with a black wire shroud and push it against my belt, but that in turn probably made the strain on the EL wire much worse.

The arm band: I figured the tiny connector and wires on my arm band would probably fail, and sure enough they did.  I had added some tape as strain relief but it wasn’t enough:

Lessons Learned

Having dealt with lots of wires and connectors in the past on robotics and wearable computers, I knew that the connectors and wires should be robustified, however I ran out of time before the event.  Also, EL wire really does not handle flexing and pulling very well, so I will pay special attention to that.  Also, a more robust solution than having one long EL wire for both legs would be to have separate EL wires so that if one fails the other will stay illuminated (it’s somewhat annoying though to solder EL wire because you have to scrape the phosphorous off the center lead).

Also, making the cardboard attachments for my legs forced me to figure out how to make crude patterns.  Interesting, but certainly not something I’d want to do all the time!

So, next time we will see what else I can come up with to improve this getup before I get completely bored with it.