Dynamics of Programming

Samsung Galaxy Note

2012-02-18T09:52:00.000-08:00

Yesterday I got a new phone, a Samsung Galaxy Note. I had been using a Motorola FlipSide that I got to have something inexpensive with a keyboard. It was underpowered with a tiny screen. Even with those limitations though, it showed me that Android was what I needed because it integrated so nicely with Trinity's Google based T-mail.

The last month or so, the FlipSide started doing some unhappy things like drying a few times each day such that it needed the battery removed to be able to reboot. That prompted me to look for alternatives. AT&T had a nice pre-order offer on the Note (I wasn't up to the point where I could get a normal upgrade) so I went with it. I've read a bunch of the reviews and the general conclusion is that this is a phone/tablet that you will either love or hate. I'm less than 24 hours in, but I love it right now and I don't see that changing.

The name Note refers to the stylus like S-Pen that comes with it. I've taken it out a few times. I won't use it often. However, I do occasionally do symbolic math on paper. Often that goes on little slips that get lost after a while. My plan is to move that to the Note using their SMemo software. That's a small deal for me though. What really matters for me is the screen, both is size and in resolution.

The Note is getting press because the 5.3" screen really is quite big. When I extend the FlipSide with the keyboard out it has a significantly smaller area than the screen of the Note. For some, this will be a problem. One of the reasons I felt confident buying the Note without having seen it is that I'm 6'4" with hands (and clothing) appropriate for that fact. If you are under 6', you need to play around with the Note before buying unless you intend to use it more as a small tablet than as a phone. It works great for me though. I have been putting it in the pockets of my Jeans even. They are a Levi's 560 Comfort fit. Because of my proportions I typically wear a relaxed or comfort fit jeans. The Note probably won't go so well in skinny jeans, but the phone itself is skinny so even jean pockets are fine if you have larger jeans.

IMO, the real gem of the Note is the 1280x800 OLED screen. There are lots of laptops and even desktops that don't go above that resolution. The result is a crystal clear display that is great for surfing the web or reading. It also means that the lack of a physical keyboard isn't terrible. In profile orientation, the on-screen keyboard is sufficiently large that I don't have a problem with it. The landscape keyboard is downright big and I found that I could type with it error free significantly faster than I ever could on the little physical keyboard of the FlipSide.

All-in-all, I'm extremely excited about this device. It makes me wish that much more that my car could drive itself because spending time driving really is wasting time I could spend doing something else.

I haven't been posting much, but I expect a rush of things early next month. I hand off the book to the publisher at that point and I have some ideas I really want to get out on this blog, but they have taken a back seat to writing the book.

Diagnosis Without Doctors

2011-12-11T19:46:00.001-08:00

I should be doing other things tonight, but this thought hit me and I feel compelled to write a short post on it. I have a number of other thoughts for longer blog posts, but they will have to wait until February after my textbook draft is in.

Earlier today I shared this article. It refers to "Race Against the Machine" and includes quotes from one of the authors. In many ways I think it is a great article. However, I was struck by how they list doctors as a relatively safe profession. Martin Ford points out how many specializations for MDs are at serious risk. However, I haven't seen anyone who is predicting the demise of the primary care physician. I'm going to predict that here. I had a previous post about the "Doc in the Box" idea of having scanners watching people in a clinic. I still think that works well. However, I'm going to take it a step further.

Let's start with WellPoint hiring Watson. This is basically an insurance company setting big-data analytics loose on a bunch of medical data. I want to up the ante a bit and make the data bigger. Imagine WellPoint distributing something like the JawBone UP to people on plans with them under the condition that they really use it. Go a bit further and set people up with some low cost devices or apps to monitor other things like this. Maybe a scale and something to measure blood pressure. How about giving them an easy way to indicate eating habits and other things that might impact their health. Feed all of that into the machine. Now we are talking some really big data. Within five years I have a feeling you completely change the shape of medicine.

Five years isn't enough time to really see what happens with any given person. However, you will make up for that quite a bit by having previous medical history (much less detailed data) combined with tracking huge numbers of people. Get some lab on a chip stuff going as well and it's over. You have a company that will be "watching" body changes in hundreds of thousands of people all the way down to activity levels and blood work. You won't go to your doctor when you get sick. They will start warning you 24 hours or more in advance that you are getting sick and tell you what to do about it.

Note that I put the word "watching" in quotes above. That's because no humans need be involved in this process at all. This only works because you can throw vast amounts of data at computers that can crank through more information in a day than a human could process in a lifetime.

What do you think? Would you sign up to have your health habits tracked closely by an insurance company so they could turn medical diagnosis from the current state of a flawed art to a true science?

Flat Wages Results of Sociology, not Politics?

2011-11-06T10:40:00.000-08:00

This first plot in this gallery of what OWS is really about was something that struck me. I have friends who argue they don't say enough about where they get their data from, but I don't buy that. My gut tells me that this is real and you don't have to play games with the data to see it. That leads to the interesting question of what caused it. The plot highlights 1980 as the tipping point. That would indicate that the problem was induced by policy changes brought in during the Reagan administration. However, the real peak is before 1980 and it looks like wages actually stopped growing as quickly around 1973. There might be some type of policy changes that led to this, but I was recently hit by an alternate explanation that is more sociological in nature. I wanted to throw it out there and see what people think. (Disclaimer: I am neither a sociologist nor an economist.)

This idea was born from an image in my head of the US in the 1950s in a "Beaver Cleaver" world where employers cared for their employees. I'm sure this image is a largely fictitious stereotype, but it started the ball rolling. There are a few factors that I see as having changed in the last six decades that could contribute to this. Cities have grown, people commute further to work, and fewer employers are really locally owned. What really matters here is that in the past you had a situation where employers were more likely to live in a fairly tight knit community with their employees and have regular interactions with them. The movement of people into cities (http://www.wsdot.wa.gov/planning/wtp/datalibrary/population/PopGrowthSMSA.htm) and the growth of large corporate chains have altered this landscape.

I that 1950s world you don't have to assume that employers were kinder and really wanted to look out for their employees. However, they did live closer to their employees and they interacted with them more often. Their wives might have played cards together or they went to the same churches. If you were a stereotypical Scrooge, people in the community would know about it and there could be a real cost to you socially and possibly economically. I picture a small town where everyone knows what everyone else is doing. If the local grocer isn't treating his employees well, that will get out. The owner will be shunned and might even lose sales if residents have other options. Basically, failure to treat employees well had real costs to you as an employer.

Over time, communities got bigger and the stores/shops around us increasingly became chains. The number of connections to co-workers outside of the work environment dropped. It became more common that the person setting a person's salary/wages lived in a different city/state. The social cost of paying employees poorly dropped away for more and more employers.

Of course, this is not all a tale of gloom. There were significant efficiencies of scale that came with this transition. This led to things being cheaper. However, that flows back around as well. If you are still locally owned and operated, you have to compete with the larger organizations that aren't. You will wind up dropping your wages to continue to compete. With communities being more spread out and less personal, the social costs of doing this was on the decline anyway.

From a pure economics view, employers always strive to pay their employees only what the market can support. My argument here is that social costs helped to keep the labor market moving upward until the 1970s. At that point, social changes removed those costs and let the labor market operate as a more pure market. In addition, increased specialization reduced the fluidity of the labor market. You have a lot of jobs where you can't just move over to a different company and maintain the same productivity you had with the old employer. That forms a barrier to movement and allows employers to keep wages lower as they don't have to worry about employees leaving as readily for higher wages.

Of course, in this blog I have to pull this back into my main topics so what role does automation play in all of this? It is all over the place. The same social forced that make it easier to keep employee wages lower also make it easier to introduce automation. As automation takes more and more routine jobs, what is left are more specialized tasks that are less transferable from one employer to another. Looking forward, a globalized market has basically no social costs for replacing human workers with automata. The neighbors and friends of the owner of a large corporation aren't going to treat him/her worse when he/she fires all the people working in the parts of the business related to shipping and stocking of goods. The way we can compartmentalize our lives, all the people he/she interacts with are probably do the same thing in their own firms.

Two Types of People: Busy and Not Busy

2011-09-23T12:06:00.000-07:00

For a while now I have used expressions like "Busy, but it is better than the alternative." when asked the ubiquitous "How are you?" With unemployment the way it is I think that many people can identify with that. I have also mentioned to people that I view being overly busy as the plague of modern life. Of course, not everyone is overly busy. There are plenty of people who have nothing to do but wish that they did.

This morning I had a thought which took me back to this article at Forbes.

http://www.forbes.com/sites/quickerbettertech/2011/07/18/9-2-unemployment-blame-microsoft/

The article is remarkably brutal in its honesty. It describes that people aren't being hired for jobs because they aren't needed. They aren't needed, because there are other options, many of which are based on technology. It goes on to say that you will get hired if you can demonstrate an advantage over those alternatives. To get hired, you have to be able to do something the software/automation/offshoring can't.

How do these things link together? I see two links. Being better than the competition, in many fields, requires a lot of effort. One of the big advantages of computers is that they can work constantly. They don't need to sleep or eat. They don't get sick. They also don't get bored or distracted. Even if you can do something that the computer hasn't mastered, they have changed the work environment so that now you can, and are expected to, be working virtually all the time. If you do something the computer can compete in, you definitely can't give it the advantage of working longer hours.

The second link is that computers and automation are capable of taking over many different tasks. When they do, they make the skills for that task nearly obsolete for humans. Humans that have those skills need to try to retrain to something else. That's a problem because retraining humans is a fairly slow process. This can put the skills that aren't yet automated in very high demand, and increase the odds of shortages in those areas. Lack of people with competitive skills means the few have to do everything. Hence, they work more time than they might otherwise want to.

Of course, if the only skills you have become automatable and you don't push down the retraining path, for one reason or another, you fall into a group that has virtually nothing to do. At least not anything productive. There are things that can keep you from being completely bored. You can play games and the machines can take on the role of entertaining you, but each day you become less and less likely to find yourself needed for productive work as the bar of automation moves steadily upward.

Hence, we move toward a world where there are only two types of people. There are the employed who are incredibly busy and who can barely stay on top of their tasks, and the unemployed who lack much of anything to do and are likely to be unable to change that.

Doc in a Box

2011-09-18T15:53:00.000-07:00

This is something I have been thinking about for a while, but recent events have turned now into the time to put my thoughts together. In case you hadn't heard, Watson, the computer that beat the top humans at Jeopardy!, now has a job. (http://gizmodo.com/5839257/ibms-watson-gets-its-first-real-job and http://www.hpcwire.com/hpcwire/2011-09-15/can_supercomputing_help_cure_health_care_.html) IBM had said that they wanted to aim the DeepQA technology that made Watson what it was at the medical field for diagnosis and now they have done it. The second article above describes how this could help out with problems we have in healthcare. Martin Ford, the author of The Lights in the Tunnel, has an op-ed in the Washington Post where he goes through some implications of this (http://www.washingtonpost.com/opinions/dr-watson-how-ibms-supercomputer-could-improve-health-care/2011/09/14/gIQAOZQzXK_story.html). The insight on the recent Supreme Court decision is really significant, but I don't think Martin goes far enough when he is looks at how this could play out in the future. (Probably because if he said what I'm going to say here people would laugh at him and the piece would not have been published.) He mentions a situation where you have people with lower levels of training who can talk patients through things and then input information to Watson for diagnosis. I think the humans just get in the way here, especially given what I have heard about the caliber of most medical assistants.

What I see happening instead is the creation of a "Doc in a Box" chain of diagnostic clinics. These would be similar to the diagnostic clinics that are popping up around the US today with the one exception that they don't have humans in them. To make this happen, I'm going to call on three things: Watson's DeepQA, Microsoft's Situated Interaction, and remote sensing.

The first demonstration of Situated Interaction was the virtual receptionist. This technology greets you and runs the small waiting room associated with each office. As "exam rooms" become available, patients are directed toward them. The situated interaction requires video so I expect every inch of this place is being monitored all the time. In fact, the monitoring in the waiting room could be part of the input for diagnosis as well because it extends the baseline for observation.

In the exam room you have a virtual doctor. This is a combination of Situated Interaction with DeepQA. You sit in a chair that has the ability to take blood pressure, temperature, pulse, weight, and other basic vitals. The patient and the machine talk through everything a medical assistant, nurse, and final provider would normally do. That could include medical history, but honestly, this system works best if medical history has been put into a generalized database already. That generalized database can also make Dr. Watson extremely effective as it will have petabytes of previous diagnosis and outcomes to mine.

In addition to the normal vitals, I see this room having a whole array of more complex sensing capabilities. Samples or breath, blood, saliva, skin swabs, and whatever else could be taken. It should also be equipped with cameras that go beyond the visible. IR is easy and inevitably has diagnostic benefits, especially after it has been used with a few million patients. Other basic scanning technologies could be included as well. X-ray seems pretty easy though you have to be careful about exposure. You could probably do some other interesting things similar to MRIs. If they sit there for a while there might even be something useful you could get from detecting background radiation interacting with their bodies. Of course, cameras with high resolution could look at regions of the skin as well as in eyes, ears, nose, and mouth and they could do it with a lot more sensitivity than the human eye and easily go beyond the basic visible part of the spectrum to include near IR and UV.

I expect this system would be able to do a good job on day one. By the end of a year or two, it will put human doctors to shame when it comes to basic diagnosis, because it will have statistics based on this advanced sensing of every single customer that has visited. To really complete the circle, outcomes should be linked in as well. If the treatment is pharmaceutical, the Doc in the Box dispenses drugs, payment is done electronically and the patient is off.

Non-pharmaceutical treatment will take longer to get into this format. Robots aren't going to put in stitches for a while. They won't set bones for a while either, even if they can see what needs to be done. That will come, but it adds 5-10 years. In the mean time, I can easily see a setup where most primary care is done in a way where the only human involved is the patient. Of course, a patient might want to see a human practitioner and they certainly should be allowed to. However, that should become a luxury and have a price associated with that fact. This type of system could make basic healthcare have a very low marginal cost. So low that you could probably provide it to everyone in the country without causing the nation to go bankrupt.

Jobs and Exports

2011-09-08T09:49:00.000-07:00

Today I heard two interesting facts about our economy for the July/August 2011 time frame. First, unemployment was flat. We aren't seeing new jobs. Second, exports were at an all time high. Here are some links with evidence, plots, and further analysis.

http://www.economicpopulist.org/content/big-fat-zero-jobs-august-2011-and-unemployment-still-91

http://seekingalpha.com/article/292427-exports-surge-to-new-all-time-high-in-july

To me this just called out that automation is making it so that companies don't have to hire humans to do things. After all, companies and making and even exporting more goods than even, but they aren't employing additional humans to do it.

That was just based on the brief sound bite of these two statistics. Looking at the plots though you can see this isn't just for right now. Look at what has happened with exports since the end of the recession in mid-2009. They have climbed from just over $120 trillion to just under $180 trillion. That's 50% growth in about 2-years. No wonder corporate profits are doing well.

Now look at the jobs numbers for that same period of time. Both unemployment and job counts are basically flat. Exports rose 50% with virtually no new hires.

I've heard people describe that some of the fact that employment hasn't gone up with efficiency is because of globalization and free trade. Those inevitably were significant factors in and around 2000. That doesn't explain this though. That's a rise in exports. That isn't stuff produced in other countries, that is stuff produced here and sold abroad. That is that part of free trade that really comes back to benefit us. There definitely are people benefiting. The problem is that those benefiting represent a very small fraction of the population and no matter how hard an average person works, it will be virtually impossible to break into that group. Unless you have the capital to buy robots to make stuff for you, humans simply can't compete for large scale manufacturing today. There are likely other areas they can't compete in today either and there will be more in the future.

Review/Analysis of "The Lights in the Tunnel"

2011-08-30T10:05:00.000-07:00

I recently bought and read "The Lights in the Tunnel: Automation, Accelerating Technology and the Economy of the Future". You can get a copy here: http://www.thelightsinthetunnel.com/. That includes the option of a PDF that you pay what you want for. The book isn't that long. I thought it was well written and an easy read so neither time nor cost are real excuses for not reading it.

Review

The short review is that I thought this was a great book and I think everyone should read it. When I read the introduction I literally felt like I was reading my own thoughts. The main premise of the book is that exponential improvements in technology are going to lead to automation taking over a lot of jobs and creating a situation where the average person in the US can't find jobs. If you go through this blog you'll see I've been saying similar things. The author, Martin Ford, said it before I was really thinking about it though. This book was published in 2009, probably around the time I really started considering the topic.

While I tend to focus on technology and society, this book brings in a lot more economics. What happens when a large fraction of people are out of work? They have no income and stop buying things. That leads to a downward spiral. The author is a big supporter of the free market. However, he makes it clear that our economy is driven by the mass market and that for the mass market to work, you have to have money in the hands of the masses. The success of our economy isn't driven so much by supply as it is by demand. Robots and computer programs don't buy things. If automation makes enough industries capital intensive instead of labor intensive, you don't have enough people with money to spend and things go downhill.

One of the big differences between this book and what I have written about on this blog is that Mr. Ford isn't even pushing things hard on the technology side. He isn't looking at strong AI. He isn't going into the things that sound more Sci-Fi. I think that is a great strength of the book because even people who don't believe in strong AI or who question things like the Singularity can't deny that robotics can do things like Soap.com (http://www.youtube.com/watch?v=6zXOW6v0c8s) or many other examples of places where automation is making industries that had been labor intensive much less so.

This book also presents some solutions. However, I'm not going to repeat all of his arguments or his solutions. The reason is that I think Mr. Ford has done a great job of doing that in a very crisp and succinct manner. Attempting to paraphrase would only screw things up. Instead I simply suggest you read his words for yourself.

Corrections/Modifications

Of course, this doesn't mean I agree with everything in the book. So here are a few things I disagree with. You might consider coming back to this after reading it. I would argue that these are details. They don't impact the main conclusions of the book. However, I think they could impact people's choices and perhaps policy decisions so it is worth bringing them up. The book shows that without changes we will go from point A to point B. Nothing I say here will change that. All that changes in my view is a few wiggles in the road. I also present one other suggestion for how to make things work better on his suggestions to help us get to point C (which is a much better place than point B).

My only significant disagreement with Mr. Ford is that I disagree with his analysis of which jobs will be automated early and which ones will stick around. He expresses repeatedly that anything that is easily outsourced will be automated and that things that don't outsource are "safer". It seems to me that he is basically saying that software AI is a lot easier than robotic AI. I agree that robotic AI is hard, but I think he is too broad in his conclusion that software AI can take over all knowledge jobs. This leads him to a number of other conclusions that I disagree with, but I think it is worth explaining why I disagree.

In the book, an example of a "safe" job that he gives in a truck driver. In 2008-2009 I can see how some people might have thought that. In late 2011 no one should believe that. The Google car should have made that clear. That is only a normal car, but there is work happening in the EU that is specifically aimed at long-haul trucks. Truck driving seems to me to be one of the most unsafe jobs you could train for today. Other examples in the book are house keeper, car mechanic, and plumber. I don't see house keeper as safe either. I think that object recognition systems are getting too good as are systems that have mobility without rolling around. Car mechanic might work, but only for "older" cars. As he mentions in the book, newer cars will probably be built such that robots can do repairs. I expect that to be especially true of electric cars. Plumber might be the best option for a safe job in this list. It combines the need to go into a normal house, work in areas that are often highly cluttered, and other factors that I see being really hard to automate. Granted, I think automation will get there, but if someone is looking for a job to train into that won't be automated too soon, plumber might be a fairly safe one.

On the other side, Mr. Ford assumes that all knowledge jobs and anything that can be outsourced is easy to automate. His main example is a radiologist. I agree 100% on that job. I expect computers will do that better than humans very soon if they can't today. However, he paints with too broad a stroke here. To see why, consider other jobs that can be outsourced: creative writer and graphic design artist. There are people working on getting software to do those things. However, I think most people would agree those are really challenging to automate, even if they are software only, no robotics involved. He doesn't mention those, but he does mention programming. I point out creative writer first to make it clear I'm not just "defending my turf". This isn't a knee jerk defensive reaction to telling people they shouldn't major in CS. I strongly believe that writing software has more in common with writing fiction and painting than it does with building bridges. What is more, unlike creative writing, software construction has been proven to be non-computable in the general case. The Halting Problem demonstrated that as one of the earliest results in CS. That doesn't mean computers will never be good programmers. At some point I expect they will get as good and better than non-augmented humans. After all, humans put bugs in code too. However, it isn't at all straightforward and I would argue it will be very hard to do. It will certainly take longer than automating truck drivers and house keepers.

So my main complaint is that I think Mr. Ford draws the wrong line in saying what jobs are "safe" in the near future. It isn't about whether it is a knowledge worker or not, it is about algorithmic describability. It is about "art" vs. "science". This also means that it isn't about college vs. non-college type jobs either. The real line has a lot more nuance to it. Still, Mr. Ford's conclusions stand. Over time that line will move and more jobs will rely more heavily on automation because they can. Thanks to the natural optimization of the market system, they will. The result will be that companies put a lot less money into the general public through employee wages or that the money is much more concentrated in a few individuals with specialized skills.

In his solutions, Mr. Ford mentions a number of changes to policy that will help to preserve jobs. They basically remove government forces that go against job creation. Things like payroll taxes and job based health insurance are policies that put an extra burden on companies that hire humans. To preserve jobs we want the cost of employing a human to be that person's wages, nothing more. Adding additional costs just gives employers a reason to try to do the job without a human. (Or in the case of outsourcing, an American. Employers don't pay FICA on non-US workers.)

I think there is one other big policy change that Mr. Ford misses. We need to remove the minimum wage. In fact, I think this might remove some of the hurdles he goes through talking about job sharing. The minimum wage sets a bar where, when the cost of automation goes below that bar, industry will flip 100% from humans to automation. If automation really does bring prices down the way it should, some money is better than no money, and having a job making that money is better than sitting at home while a robot does it. For those worried that people will be squeezed to the point where they can't live, I'll just say that Mr. Ford introduces other ways of getting money into consumer's pockets. They aren't handouts, but they help to keep our system running.

There are inevitably other tweaks that would have to be made to Mr. Ford's proposals to make things work, but on the whole I found this book to be very valuable and I honestly wish we could get everyone in the country to read it. Life moves pretty fast and technology is making the pace even faster (in an exponential way). I agree with Mr. Ford that we are going to have to make some changes in how our society works to keep up with it.

A Radical Idea for Education Reform?

2011-08-27T09:38:00.000-07:00

Background

The question mark in the title is because it is possible this won't be seen as such a radical idea. I think it would represent a major shift at the very least, and I expect most people to see it as pretty radical. Let me know what you think.

I believe most people would agree that we have problems with educating our society. The problems are the result of systemic issues in society. They can't be laid at the feet of teachers or schools. Parents, media, and many other factors play an equally significant role, to the point that just working on schools and changing up teaching isn't going to fix it. There is only so much a teacher can do with an unmotivated student whose parents really don't care.

I've generally been against the proposals I've seen to "fix education". I think accountability for teachers is a good thing, but I hate the "teach to the test" mentality that current standardized testing produces. I don't blame the teachers and schools though. If I were told that my salary and job security were to be based on my student's results on one of today's tests, I would teach to that test too. I'd be stupid not to.

I also have generally rejected voucher proposals because I fear that they will lead to a number of different problems, especially in areas of lower population density that can't support lots of schools using the standard model. I like the idea of market forces and competition, but I see problems with vouchers that outweigh the benefits.

Modified Testing

The solution I present here was really born from something that my friend, Jason Hughes, said in a discussion about education. The comment was that you want to pay people when students pass the tests, not before then. Home schooling was part of the conversation as well. This happened about the same time that IBM's Watson was beating humans at Jeopardy!. That combination was significant for me because I don't think I could support that idea if the tests were the standardized tests of today. However, I think Watson like technology gives us the ability to make much better tests that we could literally reconfigure the entire education system around, with the idea that people get paid when the tests are passed.

I don't give multiple choice tests. I know they can be built fairly well, but I insist on short answer with the possibility of partial credit. I just think this is better. It isn't the best though. The ideal test format is an oral exam. It gives the tester the ability to really probe into the student's brain to see what they do and don't know. The tester can help occasionally with little steps and take that into account for the grading. If the student can get 90% of the problem, it generally shouldn't matter too much what the 10% they miss is. However, with other testing techniques, if that is near the beginning they miss pretty much the full problem because they can't get started.

Oral exams aren't used in many places though. They are simply too labor intensive. Even at a small school like Trinity they are often prohibitively expensive. On a larger scale you would also run into problems of uniformity in the testing if a single person can't give all the tests. This is where a Watson-like computer could really help. The computer could have expert level knowledge of concepts and ask questions that start with the basics and work up, going through a web of knowledge associated with the topic and probing how far the student knows things. The computer results could be very uniform across huge populations and really tell what the student does and doesn't know.

This is different from normal tests because the computer could explore a huge range of topics. If the student doesn't know things, it stops asking questions in that direction. A normal test covering the same material would require thousands of questions. This means you could have detailed reports on what the student has mastered and what needs to be worked on. You can also give credit or pay out for fractional mastery of a subject and track improvement over time in a far more detailed way.

The Proposal

Combine this type of testing with "pay people for the tests" and you can fundamentally change the economics of education. The main idea is that "people" becomes parents/students, not schools. Schools will still exist and parents can pay schools to teach their kids, but the money comes to the parents first. If you are poor and can't get a job that pays well, home schooling might be your best source of income. In that situation the parents will support their kid's learning because that is how they pay the rent and buy the food.

The market will create schools and professional tutoring locations because many parents won't have an economic incentive or the knowledge to teach everything their kid needs to know. The difference between this and vouchers is that it will scale to any size. In regions of low population density, you might not be able to support schools with diverse values, but smaller tutoring services would work well and could easily pop up to fill in voids without being 50+ miles from a kid's house. What is more, because this lets parents get paid for teaching their kids, rural locations, where jobs are often hard to come by, will probably see a lot of home schooling and you get a system where the economic ideal for many parents will be for them to learn new material so they can teach it.

The Details

Of course, the devil is in the details and I certainly won't claim to have worked them all out. However, I think one of the wonderful things about this system is that there aren't many details. It basically comes down to, what do you test on and how much do you pay for it? IMO this is a decision to be made at the state or local level. However, you can get a general idea pretty quickly. Start with topics that are the current education requirements in the state. Consider building from there. As for how much to pay, figure out how much you pay in education right now, subtract off the cost of running the testing centers (which shouldn't be all that high) and then divide by how many kids are in the state and how many topics you expect kids to master each year. It is also possible to pay out differently for different topics. I'm sure that there could be ways of doing that intelligently, but I am not convinced it should be attempted on the first cut.

Another detail that will have to be dealt with is whether to scale payments based on number of children in a family. I don't know if this would really be needed, but I could see situations where people have more kids just to keep getting those education checks. For some reason I don't think this is a real problem. First, you don't start paying until they are several years old. That removes a lot of the possible incentive right there. Second, teaching little kids and older kids at the same time will be hard and potentially inefficient. You probably make more getting your kids up to calculus and advanced composition than you would if you stop early with the older ones and try to get new younger ones. Indeed, having payouts increase for higher level topics would make sense and would help to prevent people from having kids just to get checks.

Other Benefits

One of the potential problems with schools today is that they become daycare centers with teachers spending lots of time just watching over the "children". That is a waste of time and effort in a number of different ways. If you get paid for passing test for material mastery, you want to use the time teaching, not baby sitting.

Another potential advantage, though one that people might find controversial, is that kids stop when they are done. If a student reaches his/her limit, and simply can't master any other skills, it is time to move on to something other than education. Hopefully something that uses what they have learned productively. What I think might really happen though is that students max out in some areas, but keep improving in others. The result is maximum utilization. They take things as far as they are capable, and because they have real economic incentive (as do their parents) they really will try to keep going as long as they can. Current school systems don't work this way.

Adult Education

While the details of how it would work and how far it can be pushed are less clear in my mind, I really do think that this idea could be extended past normal school age. We already have government programs to help re-educate people who have lots their jobs to give them new skills so they can find new jobs. These programs pay for the school, not the results. Pay out when mastery has been demonstrated, and those programs would probably work a heck of a lot better.

I'm sure this also applies to college curricula, but I'm not certain how much or how well. It likely does very well in some areas, but I'm not sure if it really works for all. Still it is something worth thinking about.

Government of Infrastructure

2011-08-13T20:55:00.000-07:00

I'm not really a very politically minded person. Like everyone, I have opinions about politics, but it isn't my day job and I don't strive to stay informed about what is happening in politics. The reality though is that politics impacts all of our lives, whether we want it to or not.

As a general rule, I don't fit into either party. I'm pretty centrist in many ways. On fiscal things I'm a bit more conservative. On social things I'm a bit more liberal. It seems odd, but in many ways the platform I often agree the most with is Libertarian. I only want government involved in the things it really needs to be involved in and even then it should be involved using the lowest level of government that works. So the federal government should get out of most of the things it does, IMO, and let state and local governments deal with those things. What is more, I think that the capitalist market can be very efficient for many, many things and where it is efficient, I think government should stay out completely and let the market do the work.

However, if I have a discussion with a "true" Libertarian, we'd argue about things like NASA and NSF which I consider to be part of the essential things that the national government needs to fund. This leads to the question of what I think is essential and why. From the above we can glean two criteria:

The market won't do it well/efficiently.
It has a scale/scope that needs to be national and won't be as efficient if done more locally.

So what do I think qualifies for #1? The title of this post gives away the answer. In a general sense, I consider the market short sighted. Investors want their profits today. It is hard to invest in things that won't pay off for an extended period. I have come to the conclusion that the best term for these long-term aspects of society is "essential infrastructure". What is more, I think the authors of the constitution had a similar opinion.

Why do I think the founding fathers felt this way? The Constitution is a fairly bare bones document. They really gave the majority of the power to the states. The US had just come out from under an oppressive government and they didn't want to set up a replacement for that here. Despite the minimalism of the federal government they set up, they included a federal postal system. It does stand out as a bit odd. However, I'd argue that they viewed it as the one essential piece of infrastructure for the time that couldn't be done on a smaller scale than national and couldn't be trusted to private industry.

For a nation to work, you have to be able to communicate. 200 years ago that meant a postal service. You had to be able to trust that communication and make sure it worked across state lines as well. Today the postal service isn't as essential. There are other options and, quite honestly, the free market can do it better. Things change over time. There are still essential infrastructure elements, they just look different. The interstate highway system is probably one of the best examples of a parallel to the postal service. It was a huge cost and it really needed federal government involvement to pull off. However, the ROI has been remarkable.

What about today? What are the things that the national government needs to be funding today using this selection rule? It is things that significantly add to national competitiveness in 20 years, but that don't work as well if implemented on smaller scales. It is possible to debate what should go into that, but here are my inclusions with some rational.

Fundamental Science Research - If you are reading this, your entire life is based on Quantum Mechanics. However, the time between the development of the theory and when there were products that could use it was measured in decades. The market doesn't do well supporting things with those turn around times. They are vital to the future progress of our society in 20-50 years though. Just like interstate highways, they are also something that works best at the national level. This is where things like NASA, NSF, and NIH (along with DARPA) come into play.
Science Research Education - Local governments can handle most of education. This bullet is actually tied to the one above it. The people who discover tomorrow's version of QM are being educated today. You can't know exactly what hypothesis of today will shape tomorrow. Nor can you know which students will wind up really making the big contributions. That's fine because industry needs a lot of trained researchers too and they can't afford to train them in house. This is NSF, NASA, NIH, and DARPA again. Science funding is a bit scatter shot because not everything will turn into a breakthrough. The things that don't are still beneficial to the knowledge base and hopefully they can be done in labs that are helping to train the next generation of researcher.
Energy/Network Infrastructure - Highways still matter, but this matters more. The market actually does a very good job with a lot of this, but this is an issue of national security and productivity. It needs some oversight and more help to give it a boost and diversify it. Our electric grid needs serious updating. Utility companies can't afford to do this. I have to admit this is something I really wish the "stimulus plan" had done something with. Giving a little boost to things like wind and solar isn't just green, it helps diversity our energy sources. Nuclear too. Fission might not be active today, but projects like NIF tie this in with the two bullets above it.
Air Flight Infrastructure - Here is another one I wish the stimulus plan had done. Air traffic control barely squeaks by. Most airlines barely squeak by too so you can't milk money out of them. This is still a very important part of our transportation infrastructure that crosses state borders.

Roads are still big, but I honestly think that can be left to the states in general. Don't filter the money through the federal government the way it happens now. Reduce the federal taxes and let states decide how much tax to put on things to keep their own roads up. I think this is a system that we have the technology to do much better these days, but it's a state issue.

General education is a state issue. I liked that the Obama administration put forward a national curriculum. I think such a thing is a very good idea given the high mobility of our population. That should only be a strong suggestion though and states or smaller governments should handle education issues in general. The ideas I have for this might well become my next post.

There is probably something to be said for enforcing costs of externalities, but that's not going to fit into this post.

What you'll notice is missing is entitlements. They are a huge chunk of the current federal budget and I honestly think they should be axed. I do believe some form of entitlements are required. The future I see with automation making many people unemployable will require this. However, that isn't an issue for the federal government and they should get out of that business. Then we can have 50 states "playing" with possible ideas. Actually running different experiments will go a long way to figuring out what works. What is more, I'm guessing this isn't a problem with a single solution. Texas and North Dakota could very well need different solutions to this.

Abstracting Properties GUIs

2011-08-13T17:12:00.000-07:00

I've had a lot of ideas running around in my head related to things like government and education. However, I figured that before I posted on those I should do one that is directly related to programming, so here it is.

A problem I run into fairly frequently is having an object that has properties that I want a user to be able to interact with through a GUI. In the past this was typically something I encountered in Java. This last week I hit it when writing code for my textbook using Scala. Some "standard" approaches would be to a JavaBeans approach using reflection to make the display code generic of apply an MVC pattern. These are big hammers for what is often a fairly small problem. Those are also solutions that aren't going to fly early in a second semester course

To give you a feel for what I'm talking about, consider this code for the situation I'm talking about.



class Fractal extends DrawLeaf {

  private var (xmin,xmax,ymin,ymax) = (-1.5,0.5,-1.0,1.0)

  private var (width,height) = (600,600)

  private var maxIters = 100

  private var propPanel:Component = null



  // code we don't care about that uses data



  def propertiesPanel() : Component = {

    if(propPanel==null) {

      propPanel = new BorderPanel {

        layout += new GridPanel(properties.length,1) {

          contents += new BorderPanel {

            layout += new Label("X min") -> BorderPanel.Position.West

            layout += new TextField(xmin.toString) {

              listenTo(this)

              reactions += { case e:EditDone => xmin=text.toDouble; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("X max") -> BorderPanel.Position.West

            layout += new TextField(xmax.toString) {

              listenTo(this)

              reactions += { case e:EditDone => xmax=text.toDouble; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("Y min") -> BorderPanel.Position.West

            layout += new TextField(ymin.toString) {

              listenTo(this)

              reactions += { case e:EditDone => ymin=text.toDouble; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("Y max") -> BorderPanel.Position.West

            layout += new TextField(ymax.toString) {

              listenTo(this)

              reactions += { case e:EditDone => ymax=text.toDouble; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("Width") -> BorderPanel.Position.West

            layout += new TextField(width.toString) {

              listenTo(this)

              reactions += { case e:EditDone => width=text.toInt; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("Height") -> BorderPanel.Position.West

            layout += new TextField(height.toString) {

              listenTo(this)

              reactions += { case e:EditDone => height=text.toInt; changed = true }

            } -> BorderPanel.Position.Center

          }

          contents += new BorderPanel {

            layout += new Label("Max Count") -> BorderPanel.Position.West

            layout += new TextField(maxCount.toString) {

              listenTo(this)

              reactions += { case e:EditDone => maxCount=text.toInt; changed = true }

            } -> BorderPanel.Position.Center

          }

        } -> BorderPanel.Position.North

      }

    }

    propPanel

  }

}

I have 7 properties here and a whole bunch of redundant code to set up a GUI for setting those properties. This code is ugly. When I write it, it kind of makes me want to cry. There are basically 7 copies of the same thing here with only minor variations. In Java I never found a way to deal with this that I liked that I could present at this level. The standard rule of "abstract that which varies" led to huge code overhead or writing a separate library for fields that could be edited via code.

There are three things that vary. The first is just a String. The second is a value that is converted to a String. The third is setting a value. The third one is the challenge. In C/C++ you could use references/pointers to handle the setting code here, but you would have bigger challenges if what you were setting weren't "primitive" types. In Java you don't have references so you need to encapsulate setting functionality. That means making an interface with a single method and making a bunch of anonymous inner classes. Huge overhead. The code winds up being even longer than the original and as such it isn't really significantly easier to modify.

Scala provides a much nicer solution, mainly because function literals can be written so succinctly. Having tuples helps too. So I make an array of tuples. Each element in the tuples corresponds to one of the things that varies. A loop can run through and add them all.



  private val properties:Seq[(String,() => Any,String => Unit)] = Seq(

    ("Real Min", () => rmin, s => rmin = s.toDouble),

    ("Real Max", () => rmax, s => rmax = s.toDouble),

    ("Imaginary Min", () => imin, s => imin = s.toDouble),

    ("Imaginary Max", () => imax, s => imax = s.toDouble),

    ("Width", () => width, s => width = s.toInt),

    ("Height", () => height, s => height = s.toInt),

    ("Max Count", () => maxCount, s => maxCount = s.toInt)

  )



  def propertiesPanel() : Component = {

    if(propPanel==null) {

      propPanel = new BorderPanel {

        layout += new GridPanel(properties.length,1) {

          for((propName,value,setter) <- properties) {

            contents += new BorderPanel {

              layout += new Label(propName) -> BorderPanel.Position.West

              layout += new TextField(value().toString) {

                listenTo(this)

                reactions += { case e:EditDone => setter(text); changed = true }

              } -> BorderPanel.Position.Center

            }

          }

        } -> BorderPanel.Position.North

      }

    }

    propPanel

  }

This code isn't just shorter, it is less brittle and easier to maintain. Want to add a new property? No problem. Declare the variable and add one line of code to the sequence. Need a more complex set? That's not a problem either.

As written here, this code won't handle things that don't go into text fields, but it isn't hard to imagine an extension that does that. I need to play with it some more, but I think the "properties sequence" that includes getter and setter functionality might be a great way to write a general library for properties that is easy to work with and maintain. Pull the GUI building part out and the presentation becomes independent of the data as well.

Efficiency of Automation

2011-07-16T21:45:00.000-07:00

I normally think of the impact of the current wave of automation in terms of the level of skill/knowledge it takes to have a job that can't be automated. This article here pointed me toward a different approach.

http://techcrunch.com/2011/07/16/tale-of-two-countries-silicon-valley-unemployed/

Instead of simply thinking of the level of non-automated jobs, just think of the efficiency benefit you get from a skilled/trained person using a certain tool (including computers and robots) versus someone who isn't skilled or trained using older technology. That ratio of efficiency basically sets pay scales. So instead of looking at the capabilities of non-automated jobs, we simply look at the skills required to do jobs after they have been highly automated and whether it even makes sense to have anyone do anything the old way.

In one of the comments on the article someone argues that the same type of article could have been written about plows, sewing machines, or other historical advances. I think this comment is a little oversimplified. One of the responses to it brings this out by asking how much more efficient is a person who has mastered the plow compared to someone who hasn't mastered it and uses it poorly. Compare that to how much a programming guru can accomplish relative to a complete novice. That ratio is very significant and we'll come back to it later.

I think we can dig deeper still into this analogy. (Pun intended.) How long does someone have to work with a plow to get within a certain fraction (say 25%) of a master? How much more efficient is the master with the plow compared to a person with just a spade? Now go to the modern equivalent. How long do you have to work with a computer to be able to be 25% as efficient as a master coder? How efficient would a non-coder be using older technology (not a computer) for various tasks?

I have to admit I don't have much experience with plows, but I'm guessing I could get to 25% of the best in under a year. Actually, my gut tells me a week, but it is quite possible that I'm missing something. As for the plow compared to the spade, it is probably at least a factor of 10 and probably closer to 100. But what about the modern equivalent? Most people who have gone through 4 years of academic study and a few years of professional practice probably still won't get to 25% of a coding guru. As for the efficiency ratio of a skilled computer user on a modern computer compared to any previous technology (like paper pushing), the programmer and computer have to be at least several thousand times faster for the majority of tasks these companies work with.

How does this ratio impact employability and wages? Well, because it is a nice round numbers, let's assume that a skilled person makes $100/hour. An unskilled person is economically if their salary is reduced by the efficiency percentage. So once if they can get to 25% of the efficiency of the skilled person in a reasonably short period of time, they are probably a good bargain for an employer as long as they make under $25/hour. (Ignoring all types of things like taxes, benefits, and cost of infrastructure/equipment to keep things simple.) However, if the unskilled person has an efficiency that is more than 100x lower and it will take them a long time to improve that significantly, they are basically unemployable. For it to be a bargain for the employer they would have to make pennies per hour and would be better of begging or resorting to petty crime.

The argument that previous advances in technology have increased overall productivity and led to new job creation are perfectly accurate and I guess in theory they apply today as well. There is just one problem. I'm pretty sure the efficiency ratio grows exponentially just like technological advancement. It certainly has for decades, if not centuries, of recent time and I fully expect that to hold out another decade or two. This exponential growth isn't slow either. That means that once it starts to break away, it just soars off. Taken to the extreme you can imagine a world where any particular job can be accomplished by a single, skilled person. You don't hire a second one because there isn't a need to. The first one can do it all. That is the extreme, and that might not be realistic, but you don't have to go to that point before many things start to break down.

One of the links in the above article goes to this.

http://techcrunch.com/2010/06/03/soap-com/

Simply watch the movie and you see a company that has huge volume and very few employees. It doesn't take much imagination to see how you could get rid of most of the people you see doing unskilled work and replace them with different types of robots that are managed by a much smaller number of people. The way this scales you have a company that can handle a huge fraction of the non-perishable goods purchases in the country with very few employees. Such, they buy a bunch of robots, but those robots were built in dark factories. Only the designers and programmers are humans, not the builders. Now introduce self-driving delivery vehicles and things get even more interesting.

Of course, the normal economic model is that this all creates new jobs. Costs go down and people can buy more. How much training/skill do you need for the jobs it created though? How much stuff do we really need to buy? There is a point of diminishing returns. We might well have already passed it. The normal model of growth has been fueled by growing populations and growing wealth. I see that breaking down. No exponential can go forever, even at low rates. (To see this, simply calculate what happens with 1% growth per year for a few thousand years.) So we have a race of exponential growths here. Which one crashes out first and to what end?

Drugs, Crime, and Automation

2011-07-12T17:55:00.000-07:00

I should be planning some stuff for a conference right now, but an idea hit me that I just had to write about. I have long been a supporter of the idea that drugs should be legalized. Prohibition failed once. Why are we trying so hard to make it work this time? It is more than that though. There are basic economic reasons why it would be a huge benefit to legalize and tax drugs. It would take a lot of financial pressure off states for things like prisons and instead give them an alternate source of revenue. I also expect ti would lower crime rates for things like theft because the legal drugs would be legal and cost less. What is more, instead of having the profits of drugs go into crime cartels, they would go to legitimate companies.

This is where the thought for this post comes in. My basic assertion is that criminals don't use automation. That had never occurred to me before, but it probably should have. Criminal activities stay human intensive. They don't set up giant corporate farms for growing drugs. They don't set up online sales or have computer controlled routing. These things don't work when your whole operation is based on flying under the radar and not getting busted by law enforcement.

Now, automation does allow things to be cheaper. So does not having to avoid cops. Passing federal regulations will make things more expensive, but I'm guessing the net impact on product cost is still a drop. However, the question I have to wonder about it what this does to employment rates. How many people are there who are generally non-employable in modern society who are currently employed in drugs? Maybe this isn't a large number of people. I haven't given it that much thought. However, I think what I'm coming to see here is that because of the automation it allows, legalizing drugs would change the employment profile of the industry. The total job count likely goes down (though initially a lot of the jobs lost could well be in other countries). However, it would produce a set of higher paying jobs for the people who oversee that automation. Basically, it would work just like everything else in this regard.

Computer Performance Future

2011-05-25T11:52:00.000-07:00

The topics of automation, AI, and the impact these will have on society have been big on this blog. This is because they are things that I think about a fair bit. I'm not in AI, my interest are numerical work and programming languages, but I live in the world and I train the people who will be writing tomorrows computing software so these things interest me. I've been saying that things get interesting around 2020. I think the social changes become more visible around 2015 as automation begins to soak up more jobs and by 2025 we are in a very odd place where a lot of people simply aren't employable unless we find ways to augment humans in dramatic ways.

Cray just announced a new supercomputer line that they say will scale to 50 petaflops. No one has bought one yet so there isn't one in existence, but they will be selling them by the end of the year and I'm guessing by next year someone builds one that goes over 10 petaflops. That's on the high end for most estimates I've seen of the computing power of the human brain so this is significant.

Thinking of the Cray announcement it hit me that I can put my predicted dates to the test a bit to see how much I really believe them, and as a way to help others decide if they agree or not. We'll start with the following plot from top500.org. This shows computing power of the top 500 computers in the world since 1993.

What we see is a really nice exponential growth that grows by an order of magnitude every 4 years. I couldn't find exact numbers for the Flops of the Watson BlueGene computer, but what I found tells me it would probably come in between 100 and 800 TFlops though that might be too high.

The thing is, that the processing power of the top 500 machines in the world isn't really going to change the world. MacDonald's isn't going to replace the human employees if it costs several million to buy the machine that can do the AI. However, smaller machines are doing about the same thing as these big machines. Right now if you can get a machine that does ~1 TFlops for about $1k assuming you put in a good graphics card and utilize it through OpenCL or CUDA based programs. So workstation machines are less then 2 orders of magnitude behind the bottom of the Top500 list. That means in 8 years a workstation class machine should have roughly the power of today's low end supercomputer. To be specific, in 2021 for under $10000 you will probably be able to buy a machine that can pull 100 TFlops. So you can have roughly a Watson for a fraction of a humans annual salary, especially if you include employer contributions to taxes and such. I'm guessing that running a McDonald's doesn't require a Watson worth of computer power. So if the reliability is good, by 2021 fast food companies would be stupid to employ humans. The same will be true of lots of other businesses that currently don't pay well.

Comparing to Watson might not be the ideal comparison though. What about the Google self-driving car or the Microsoft virtual receptionist? In the latter case I know that it was a 2P machine with 8 cores and something like 16GB of RAM. That machine probably didn't do more than 100 GFlops max. Google wasn't as forthcoming about their car, but it wasn't a supercomputer so I'm guessing it was probably a current workstation class machine.

What about the next step down in the processor/computer hierarchy? The newest tablets and cell phones run dual core ARM processors that only run about 100 MFlops. That's the bottom of the chart so they are 3.5-4 orders of magnitude down from the workstation class machines. Keep in mind though that given the exponential growth rate, the low power machines that you carry around will hit 1 TFlops in 16 years, by 2027. That means they can run their own virtual receptionist.

Networking and the cloud make this even more interesting because the small device can simply collect data and send it to bigger computers that crunch the data and send back information on what to do. What is significant is that the chips required to do significant AI will extremely cheap within 8-16 years. Cheap enough that as long as the robots side can make devices that are durable and dependable, it will be very inexpensive to have machines performing basic tasks all over the place.

So back to my timeline, a standard workstation type machine should be able to pull 10 TFlops by 2015, four years from today. I think thins like the virtual receptionist and the Google cars demonstrate that that will be sufficient power to take over a lot of easy tasks and as prices come down, the automation will move in. By 2020 the cost of machines to perform basic tasks will be negligible (though I can't be as certain about the robots parts) and the machines you can put in a closet/office will be getting closer to 100 TFlops, enough to do Watson-like work, displacing quite a few jobs that require a fair knowledge base. By 2025 You are looking at petaflop desktops and virtual assistants that have processing power similar to your own brain.

So I think the timeline is sound from the processing side. I also have the feeling it will work on the software side. The robots are less clear to me and they might depend on some developments in materials. However, graphene really appears to have some potential as a game changer and if that pans out I don't see the material side being a problem at all.

Scala 2.9 and Typesafe

2011-05-15T10:01:00.000-07:00

It is remarkable how far Scala has come in the 18 months or so since I first started learning it. The final release of Scala 2.9 just came out and Odersky has started a company called Typesafe that is intended to get more companies on line with Scala. These things excite me because I see them being very beneficial for both my personal programming and what I do in the classroom.

Having Typesafe should make it easier for companies to use Scala more and right now that is one of the very valid points against Scala, it simply isn't used as much out in the market place as other options. I truly expect that to change with time and I see this being a step in that direction. It will also make it easier for our sys-admins to get everything set up nicely and that is a big plus.

The number of additions in Scala 2.9 is significant. You can read all about them on the Scala site, but I want to highlight the ones that I think will be good for my teaching. The first one is the additions to the REPL. The REPL is a great teaching tool. It truly allows the student to get started typing in single statements and then to keep playing around with things later on to see how they work. Through 2.8 the REPL in Scala had some rough spots. The list of fixes for 2.9 seems to cover most of the problems I've run into so I'm very hopeful that the students next semester will have a much better experience with it.

The key addition for most developers in 2.9 is parallel collections. These will impact the second semester and beyond because I introduce parallelism in the second semester. Early on, this makes it easier to to parallel loops in Scala than it would be with even OpenMP. Consider this code that calculates and prints Fibonacci numbers.

for(i <- 0 to 15 par) println(fib(30-i))

When you run this using the slower, recursive version of fib, you get the numbers back out of order with the biggest values near the end. Just adding the call to par is all it takes. Of course, the for loop and collections can do a whole lot more than this and they will also do their tasks with the simple addition of a call to the par method.

Not only did the collections get parallel, they got a new set of methods that come standard: collectFirst, maxBy, minBy, span, inits, tails, permutations, combinations, subsets. These just make the already rich set of methods on collections a bit richer. The last three, in particular, strike me as easily enabling some interesting problems.

The last addition I want to highlight is one that I really don't know all that much about and as such I'm not certain how much it will impact my teaching. However, I'm optimistic about it. This is the addition of the scala.sys and scala.sys.process packages. I use the scripting environment of Scala in the first semester. I love how this lets us write programs with a low overhead. Up to now though, Scala hasn't really been good for scripting in the sense of launching lots of processes and dealing with the OS. These packages look like they will help to bridge that so that I can use Scala for those types of things instead of having to move to the ugliness that is Perl.

Real Implications of Automated Cars

2011-05-01T09:59:00.000-07:00

In case anyone had forgotten, I really want a car that drives itself. I don't like to drive. I find it to be a waste of time. I liked buses in the Denver-Boulder area, but the system in SA, especially where I live, isn't up to the same level and my life here doesn't support that. Just the ability to read during commutes was great for me. I would get through a lot more of my intended readings if I could sit back and read during my morning and evening commutes.

The ability to do other things while the car drives is only a first-order effect though. It is using the car like we do now, but just more automated. Where things get interesting is when you look at the higher-order effects. The examples that come to my mind are uses of the car that occur without having a licensed driver present. It might take a while longer for these to take effect because people/society will have to truly trust the automated driving mechanism before it will be legal to have the cars really drive themselves without a person who is responsible for them being present. However, I think that point will be reached and that is when the full impact of this change will become apparent.

There are two main categories that jump out

No humans in the car at all.
Non-licensed drivers in the car.

The first thought I had related to the initial item was because I see automated cars as needing to have a high level of safety maintenance. Things like cleaning sensors and doing regular checks that they work will be required for legal reasons and for insurance. The work itself will be largely automated and it won't take long before people want to just send their car out to do it while they are at home or at work.

Ever had one of those late night cravings for some type of food that you don't have in the house? Maybe a fast-food pick-up. You don't really need to be there for that. You place the order online (possible on a phone or tablet) then send the car to pick it up. A little extra automation will be needed, but nothing too difficult.

Remember in the dotcom bubble there were companies that wanted to deliver groceries with online orders? It didn't scale well because of the cost of delivery. If people can simply send their car to pick it up that problem is solved.

This also leads to a new specialized product: mini-cars that don't carry humans, only other stuff. The vehicle that goes to get your combo meal doesn't need to be big enough to carry a human or have the nice seats. Same for all these other tasks. You can have a much smaller device that exists just to transport goods to end users.

The second bullet was normal cars driving without a licensed driver. Driving the kids to school in the morning? Why does a parent have to be there physically? I can see all types of bad social implications of this with parents sending their kids out all the time and never seeing them. Then again, how different is it to do that with your self-driving car versus their bike? Less exercise for the kid, but not less contact with the parent. In fact, with video call capabilities the parent could be interacting with the kid while they are being transported.

Of course, automation is going to alter all types of other things in the world in the coming years. This was just a few thoughts on some of the less obvious implications of cars that drive themselves.

My Automated Greenhouse

2011-03-20T20:18:00.000-07:00

In EPCOT we want on the “Living with the Land” ride. I love that ride. It brought to mind a dream that I have of putting a solar power, automated greenhouse in my backyard. More generally, it makes me think that structures like that should be commonplace in suburbia. On “Living with the Land” you get to go through sections where they are growing all types of plants in greenhouse structures using interesting techniques. Since the last time I went on that ride, students at MIT did a class project where they had robots growing and picking tomatoes. Given the strides in automation, I see no reason why all the things they are doing at EPCOT couldn't be automated as well.

What I'm not certain of is how much food one could produce in the area of a normal suburban yard, or a reasonable fraction of it. I'd be happy to give 50% or more of my yard over to an automated greenhouse. Whoever makes it can not only charge me for software upgrades and possible hardware upgrades, but also for seed packets that I would add every so often. Just hook up electricity and water and pour in seeds then every so often you get fresh fruits and vegetables. At EPCOT they also raise fish because the two can work well together. I'm not certain how viable that is for this application, but it could certainly be a consideration.

Combine this with serious solar panel coverage on every house and you have a situation that is probably fairly sustainable. It would turn the wasteful suburban lifestyle into something much better for the planet. Indeed, for the purposes of energy and food production the suburbs probably come a lot closer to being able to sustain themselves than dense cities can. The primary problem of the suburbs is transit and sprawl. These might not be such a big deal in a future world where more work is done remotely and energy requirements for transport are reduced thanks to lighter weight autonomous vehicles. Indeed, the possibility of growing more food close to where people live might go a fair way to offsetting other elements of transit. I'd have to do some calculations to get a decent estimate of how well this works on the whole. Perhaps that can remain as an exercise for a future blog post.

Automation and Jobs

2011-03-20T19:51:00.000-07:00

This is following on my previous blog entry about automation and social impacts. The whole NY Times series on Smarter than you think is very relevant to the topic. The most recent article is about lawyers being displaced by e-Discovery systems. Those are truly high paying position being eaten up there. Another significant article is this one about automated cars. Note that they forecast a 10-year window for full automation. Don't go into truck driving at this point. I'd also expect loading equipment like forklifts to be automated on a slightly shorter timescale.

What I wanted to write this blog on is a thought that occurred to me while checking into the Disney cruise. In the last blog post I had a link to the Microsoft virtual receptionist. My thoughts combine that with this clip put out by Corning called “A Day Made of Glass”. There are a large number of jobs that I can think of that could easily be replaced by a reasonable quality virtual receptionist with large touch sensitive electronic displays. In fact, probably 90% or more of the Disney park employees and people at the cruise registration could be replaced that way. Airline counters too. Throw in a little robotics and the flight attendants either go away or get their numbers cut way down. With that little bit of robotics this hits a whole other set of jobs. Move more documents onto those touch surfaces and the paperless office might become more of a reality. That removes the need for a lot of people as well.

Apparently there are a number of restaurants that are working on the idea of using iPads for customers to order. Some are giving those iPads to waiters, but others put them right in the hands of customers. Corning would love tables that have Microsoft Surface capabilities for this purpose in the not too distant future. I have to admit though, I don't see Microsoft being the driving force behind this in the end. For food chains where the food is fairly routine, robots will quickly come into play for food preparation and even serving.

Watson beat the top Jeopardy! champs and while it certainly isn't infallible, it ranks above most all humans in that game. IBM is aiming it squarely at the medical field for diagnosis. Throw in this work with automatic processing of medical images and work various people are doing on having robots care for the elderly, and I'm not even certain that the medical field is all that safe an employment option. This is contrary to the predictions that the medical field will see huge job growth. There will be a surge in the amount of medical work done, but that actually provides a driving force to automate as much of it as possible.

This leads to a question that I find rather interesting. What fields are safe for young people to go into? As one would expect, I think that CS and software development are pretty good. However, even there it might only apply to higher end work. Law and medical practice could easily stagnate with automation. Engineering? That isn't a given either. The article that mentions Lawyers being replaced also mentions that Computer Engineering positions are stagnating because software is so good at helping make people more efficient at designing chips. What about other fields of Engineering? I expect that software is pretty good at bridges and mechanical work too. It doesn't have to do the job. It just has to make one human doing the job more efficient to prevent additional hires.

So what won't computers move into? If I only project until 2030 I see two areas. They are things that have a noticeably human touch, and those that require work that borders on non-computable. The former might not even be all that safe as people get more comfortable interacting with computers and the computers get more human. The latter is where the field of programming lies. Thanks to the non-computability of the halting problem, writing software is, in general, non-computable. Granted, humans make mistakes when programming so I see no reason to believe computers will never get as good or better than humans. I just see this being one of the later problems they get to. What else is provably non-computable? I don't know exactly. I don't know if people have really asked what tasks are and aren't computable. I have a theory that things which we consider to be “art” are non-computable while things we consider to be “science” are computable. Does that mean arts are safe and sciences aren't? Not really. It means fields where practitioners follow specific algorithms and there are known recipes for success are risky. Fields where people develop a sense for what is good through practice are safer. Since the value of a job is determined by demand regardless of automatability, artistic fields that no one wants to pay you for doing aren't going to make good career paths even if they can't be easily automated. For this reason, I'd add research scientists to my list of safe job paths. New science will always be needed to drive the next round of technology and research is much more of an art than a science. Creative jobs that involve some form of content creation can also work, but one has to be careful because they are only as valuable as their products are in demand. However, I also expect the wave of automation to open up whole new possibilities for creative jobs.

So how different is this from having a sewing machine make seamstresses more efficient? For me, the difference is that the jobs being replaced now are often the ones at the top end of the spectrum. It will also hit those at the very bottom end of the spectrum as well. The sewing machine made products cheaper and increased wealth so the people trained up into a whole new level of jobs. This round of automation will also improve efficiency and increase general wealth. It will make products cheaper and make it easier for everyone to enjoy a higher standard of living. Unfortunately, unless you can augment human capabilities with wetware it isn't at all clear to me that this round will make new jobs that humans can train into. Why not? First, the jobs you are eliminating here are at the top of the spectrum of what humans do. Where do you train up to when you already have a doctorate level degree in medicine, law, or engineering? Second, the timescale of training for jobs at that level is really long. If it takes a human 4 years to train for something that hasn't been automated when the start the training, what are the odds it won't be automated before they finish. Even if it isn't, how many years until it is? Train 4 years then work 2? That's not exactly a good approach to making a living.

So where does this leave us? Well, if wetware develops quickly and we start augmenting humans at or before 2020, then maybe we get Kurzweil's singularity. Barring that (and only looking forward to 2030 right now), we have a need for dramatic social change as total wealth grows dramatically, but the number of humans who are able to hold down jobs for extended periods of time drops dramatically.

Selling My Soul To Google?

2011-01-08T08:30:00.000-08:00

Yeah, another long breaks between posts. When I started this John told me that what I needed to do was write every day. The thing is, I do write every day. I write a lot every day. I just write it in different places. The textbooks I'm writing don't belong on a blog. They are often high priority as well and taking the time to write here takes away from that. With the semester approaching I definitely have other writing to be doing, but I have some thoughts bouncing around that definitely belong in this venue.

Just recently my wife and I got new phones. The effect this has had on my life and how I'm doing things has been so pronounced that it it nothing short of remarkable. It isn't just because of the phone though. Other factors certainly come into play as well and the total effect is that the value of certain technologies that had seemed a bit silly to me has really come into focus.

My wife got an iPhone. I kid her that she has sold her soul to Apple. It was a gradual process. It started with iTunes and then went to iPods for her and the kids. The iPhone has just cemented it. She truly belongs to Apple now in a way that she will have a hard time reversing. She doesn't mind it right now and perhaps never will. We will see.

I understand this because I was tethered to Microsoft for a while. I managed to break free piece by piece going to OpenOffice first. The move away from Exchange was the hardest, but Evolution was close enough and I got my files moved over so it worked out well. When I got a laptop with Vista on it I cut the link completely and wiped the drive and put Ubuntu in its place. I am a much happier person as a result.

For small form factors I have been an early adopter. I got the Compaq iPaq shortly after it came out. It was a thing of beauty. A little computer I could hold in my hand. It was Windows, but I could forgive that at the time. My next handheld was a Zaurus. With the slide out keyboard and Linux on board I loved that thing. Those devices weren't phones though and I didn't carry them with me everywhere because I didn't want to have to carry multiple devices. About three years ago I got a T-mobile Dash as my first smartphone. It was Windows and at the time I was still tethered to MS so it worked well with what I was doing. It had a little QWERTY that worked well for me, but no touch screen. That turned out to be a problem because so many of the programs for the platform needed to you be able to point. When I broke free of MS it wouldn't talk to my Linux boxes at all. So it because just a phone with a keyboard for texting.

My new phone is an Android Motorola Flipside. The advances in smartphone technology are staggering to me. The Dash seemed nice to me, but the reality was they were trying to put a little PC in my hand. In the three years since the OS developers have figured out how to do handheld devices. This phone has a slide out keyboard, but it isn't a handheld PC. It is a smartphone and the user interface is wonderful. I love the multiple workspaces.

In the last year Trinity moved from Exchange to T-mail which is hosted by Google and it really G-mail. That hadn't been a big issue for me when using Evolution. The switch was just a change in what machine I was pulling things down from to store on my laptop. However, this phone automatically synched to my T-mail account. Unfortunately, the way I was doing things it wasn't too helpful because my laptop would take things off the web and store them locally. I liked that because I liked to be able to work on e-mail when I wasn't connected to the internet. The phone is far more connected though and getting to see my e-mail from anywhere my phone was trumped has for the moment trumped the ability to work offline. So I have basically moved from Evolution to using G-mail. The calendar features and the way they work on my phone are also great.

What is really happening here is that I'm moving into the cloud. This does worry me a bit because I really don't have this data locally anymore. I might start having Evolution pull stuff down for that purpose, but we'll see.

In this move I'm also playing now with Google Docs. It had always seemed like a novelty before, but now I'm seeing some of the value. The ability to share documents is significant for many applications. I'm also starting to see the brilliance of Google in other areas as well. Chrome has tabs that can easily break off into new windows and each tab runs as a separate process. That is touted as good for stability and it made sense to me, but I didn't see it as groundbreaking. However, in my changes over the past week or two my tabs have now turned into my apps. One is my e-mail. Another is my calendar. Now some will be my documents. Chrome OS starts to make a lot more sense as well.

So the question is, am I selling my soul to Google as surely as my wife has sold hers to Apple? I'm afraid the answer is yes. I haven't sold out completely though. I couldn't replace my laptop with an Android tablet for example (though the ones from Asus with keyboards are very tempting). That is only because I do some things that aren't in the Google toolbox yet. They have no equivalent for Eclipse. Similarly, their text documents aren't a replacement for LaTeX/LyX in editing large documents. However, I can see a world now where those things would be run either in the browser or in something that spawns off the browser.

Many of you reading this probably moved in directions like this a while ago. What are your thoughts? How has the transition been? Where are the rough spots? What can't you do in the cloud? What things do you see never moving into the cloud?

Proof in Programming

2010-12-04T07:07:00.000-08:00

This post is based on some discussions that have been happing in my Next-Gen Programming languages class. This follows on the thoughts of an earlier post relating to AI and automation. This article on the military using robots is also relevant.

http://www.nytimes.com/2010/11/28/science/28robot.html?_r=1

The basic argument in this is that software systems are going to increase in size and complexity and languages/tools need to do something to keep up with that. I am a strong proponent of static type checking in large part because it allows the compiler to prove that certain aspects of a program are correct. Without this you have to perform more testing at every step and because testing never gets complete coverage, you can never be as certain based as tests as you could be with type checking.

Type checking only does correctness proofs for a certain fraction of the program. It seems to me that in order to really trust software to drive our cars and shoot our guns, we need to have more of the systems correct to the level of proof. You can prove an algorithm correct by hand. It is tedious and painful and it certainly doesn't scale very far. However, proof can be fairly well automated in most places and my question is how far that idea could be pushed and what are the possible implications.

We are seeing more and more of type inference systems in languages. ML and family have had it for many years. Now it is in languages like Scala and even the next version of C++ (C++0x) has type inference in the mix. The idea here is that types are fairly algorithmic as well. The compiler can figure out types for things most of the time. Humans just have to step in at certain points to help out.

What if a language/programming system had a similar concept for proofs of correctness? The system automatically discovers as much as it can about what a function or some other grouping of code does. Every so often a human might step in to help out if the automatic system doesn't "get it". However, the human's overrides won't be allowed to be incorrect, just set constraints that make it so the proving agent can figure more out. That is what type inference systems do. The user can give a more constrained type for something to help out, but if they provide an incorrect type, they get an error.

This made me think of something I had learned about Modula-3. Modula-3 had safe and unsafe modules. The safe modules were garbage collected and had pointers that were like Java references. They were always safe and the language/system dealt with things. Of course, you can't do systems programming in Java and the engineers at Digital wanted to allow systems programming in Modula-3. Unsafe modules allowed pointer arithmetic and let you do the unsafe things you can do in C/C++. The idea was that you only used them when needed and did most of your programming in safe modules.

So consider extending this a step further to "proved" modules. These modules will only have code in them that has been proven to be "correct". In my head I picture something like hover-overs you get in newer editors when type inference is involved. The automatic proof system will tell you everything that it can about the code. The programmer would set constrains until the desired result was attained. Then the parts of that result you really cared about could be "locked in" in some way. That way, if you or someone else changed the code later in such a way that a desired outcome wasn't provable, you would get an error.

You would probably want the ability to move code around, but moving things down a step from proven to safe or safe to unsafe might trigger all types of errors/warning when dependent code was no longer safe or provable. The goal though is to make as much code as possible in a system proven correct and what can't be proven you want to be safe unless it absolutely has to be unsafe. Moving things up levels wouldn't be as challenging, you just have to clean it up a bit to match the requirements of the higher level of safety. Code calling on it would generally go unchanged.

This leads to a very interesting theoretical question, how much can you prove? What fraction of the large systems that we are interested in could go into a proven module? I don't know if we have a good answer for this yet, but it would be interesting to find out. My gut tells me that the answer is a lot and if that is true, this would make programming a much safer and more reliable process.

Now to something even more theoretical and esoteric. I have a certain conjecture that while human intelligence is computable, the things we consider artistic aren't. We consider them art in large part because we can't give an algorithmic description of how to do them so they are more individual and subjective. My new conjecture on this line is that intelligent behavior, while computable, isn't provable. In order to get intelligent behavior, you would need to include significant non-computable aspects. If this conjecture is true, then limiting development as much as possible to provable modules could also be what is required to prevent scenarios like Terminator or the Matrix. Granted, there are all types of ifs in this paragraph and it is nothing more than conjecture.

Understanding of Gravity -> Technology Revolution?

2010-10-18T13:09:00.001-07:00

This post relates to a thought that I had driving into work this morning. Most of the technology that we use today and the advances that literally drive our economy come as the result of our understanding of quantum mechanics. We have gotten extremely good at manipulating things in the small. An understanding of solid state physics along with control of light and other subatomic particles have allowed for remarkable advances in miniaturization. Humans have dominated the small scale down to atomic nuclei and electrons. We don't do much below that yet, but perhaps that will come. Still, what we have done has far outstripped most of the imaginings of science fiction writers and those who would predict future trends.

On the other hand, we have failed miserably to keep up with these things at larger scales. We don't jet off into space whenever we want. Humans can't visit other bodies in our solar system. We are constrained to Earth and we are constrained to move around fairly slowly. We have plans for tall buildings and every so often a new structure is built that goes higher than where we got before, but there is no space elevator. There are also no flying cars that are really useful. In a sense, we have mastered the microscopic and failed to do much with the macroscopic.

One of the biggest areas of future discovery for humans is the merging of quantum mechanics and relativity. Both theories work wonderfully in their areas. They are both very accurate in the domains where they dominate. However, we know there is a problem with our understanding because the two theories don't get along. A lot of the research in basic physics has been aimed at figuring out how a combined theory would work or at getting experimental data that will help point us in the direction of a combined theory. I have argued in the past that having funding go to this is essential to our future. We don't know what advances will come out of it, but I have always felt confident that they would be huge and have significant social implications. My thought this morning was just a tiny insight into what that might be.

So what could we really gain from a Grand Unified Theory as the theories that merge QM and relativity are often called? How about mastery of the macroscopic? Our understanding of the force of electromagnetism along with the weak and strong nuclear forces has been instrumental in mastering the microscopic. We don't make full use yet of the two nuclear forces, but the most advanced of our technologies do rely on our understanding of these. The forces that we have a unified theory of only control behaviors in the small. The macroscopic world is dominated by gravity, the one force we know of that we have brought into unification. It is the force that holds us to the planet and makes it so darn hard to fly or visit other planets. Really understanding gravity might be what helps us to get past that.

I'm not proposing that we will find a way to "get around" gravity. We certainly haven't stopped electromagnetism of the nuclear forces either. What we did was learn how to manipulate them to do the things that we want to get from them. Perhaps the same will be possible with gravity. Perhaps finding the GUT will allow us to slowly build our ability to manipulate gravity in the same way we have slowly developed our ability to manipulate the other forces and eventually give us the control of the macroscopic that we currently enjoy over the microscopic.

Automation and Social Change

2010-10-18T09:56:00.000-07:00

I haven't posted in quite a while. Life is busy and I didn't feel I had all that much to say. However, some things have come into my mind that I thought might be worth putting up here.

http://www.good.is/post/automation-insurance-robots-are-replacing-middle-class-jobs/

This is an article that I shared on Facebook. This is something that I had thought about a fair bit, but this opened my eyes a little because I had made a few mistakes in my assumptions. The article focuses on how robots are replacing middle-class jobs. I have been thinking for a few years about the fact that robots will be replacing jobs and the impact that would have on society. I made a mistake in my thinking though in that I was considering the most vulnerable jobs to be at the low end of the pay scale. The idea being that those are low skill and easy to replace. I hadn't seen that happening so I thought this was just something for the future.

In reality low-skill jobs often require things that are hard to make robots do. What is more, they don't pay much so the robots will have to be really cheap before they can replace humans. The mid-level jobs are much more vulnerable because if they are repetitive, the pay scale is high enough to validate using robots instead. So automation eats away starting at the middle, not the bottom. That makes slight alterations to the social implications, though the fall out in the end is similar.

Something else happened recently that brought this topic up to the front of my thinking.

http://gizmodo.com/5662005/test-driving-googles-driverless-car

This is further ahead than I thought things were. Not in a bad way. I really want my car to drive itself. I don't care a bit if it flies. I just don't want to have to drive so I can be productive on the way to work or anywhere else.

The reality is that computers are going to eat out larger and larger fractions of the job market in the coming years. When they can drive, transportation and warehouses will be completely run by machines. Humans will just get in the way or only come into play for oversight. As time goes on the amount of oversight will drop. Once the robots are cheap enough, they will flip your burgers and make your fries. You will only be served by a human if you want to pay for the "personal" aspect of such service.

This will have a huge impact on society. Yes, the automation improves efficiency and reduces the cost of everything, but what happens when unemployment soars because there simply aren't enough lower level jobs to put people in? Today's unemployment numbers of ~10% are a significant concern. What happens when that goes to 30-40% because so many jobs are automated? It will then continue to grow, assuming society doesn't fall apart. How far it goes depends a lot on ones beliefs about the limits of computing power and AI. It also depends on the rate of development of wetware. Here are some different options:

Societal collapse - modern society is rather delicate in that we all need a lot of infrastructure to do things. Anti-automation mobs could push things over the edge and send us into a modern version of the Dark Ages.
Human Utopia - This could happen with either a high level of weak AI or a well behaved strong AI. Automation takes over everything and humans just sit back and enjoy it doing whatever they want. Think Wall-E here. However, the implications of this aren't all that clear. What happens to humans who don't have any motivation to do much of anything? The first generation probably behaves much like their parents, but I could see this going in odd directions after a few generations.
Singularity - This is Ray Kurzweil's prediction. This requires strong AI and that wetware keep up enough so that humans can integrate themselves ever more tightly with the growing capabilities of the AI. A more negative view of this might be the Borg from Star Trek Next Generation.
Human Eradication - What happens if you have strong AI that has a will of its own and wetware doesn't keep up? Think Terminator or the Matrix except remove the plot line because humans don't stand a chance. The computers become self-sustaining and increase in efficiency and capabilities exponentially. We become insignificant and if we are lucky they just ignore us. If we aren't luck they see us as competition for resources and eradicate us.
Elite Workforce - This is one that occurred to me yesterday that I haven't heard anyone discuss before. What happens if you get really weak AI? It isn't just inferior to humans, it never manages to be capable of some of the top level activities we need in society. Then 90+% of jobs get automated, but you still need smart humans in the remaining 10% to keep things running. What world does that leave us with? It probably depends on how the 10% of employable humans treat the rest of humanity.

There are probably cases I'm not thinking of. Feel free to comment on those. So what is the time line for these things? I think that in 10-15 years we will start seeing the impact of the social squeeze of more things being automated. However, things won't really blow up until the 20-30 year time frame. That is when we will find out if AI can be strong or if it will always remain weak. We'll also see how well wetware does in keeping up the pace with normal hardware. One way or the other, I fully expect to see a very different society before I die.

Additional note: A few years back I saw a Microsoft presentation on the Virtual Receptionist technology. Here's a link. Just another segment of jobs that can disappear in a few years.

http://community.research.microsoft.com/blogs/techfestlive/archive/2009/02/25/the-virtual-receptionist.aspx

x86 Open64 Compiler

2010-08-27T15:19:00.000-07:00

I recently updated both my laptop and my home machine to Ubuntu 10.04. This had one significant negative side effect on my workstation in that it broke the Intel compiler I had installed by the system maker. I started doing a bit of searching and the problem I have is a known problem with the newer libraries so it isn't clear that paying Intel more money would actually fix the problem. However, during my searching I came across the x86 Open64 compiler. This is an optimizing compiler from AMD. It is fairly new. I have vague memories of seeing announcements of the release back in 2009, but I didn't look closely at it at the time. Not having a working compiler other than gcc on my system made me consider taking a second look.

While they say they have only really tested it under RedHat and Fedora, the binaries work just fine for me on Ubuntu. I have now also installed it on all the machines at Trinity. I need to do a direct speed test between it and the Intel compiler on my cluster, but I haven't done so yet. The set of optimizations that they list is quite impressive and from what I have seen it certainly isn't significantly slower than Intel on my home machine.

There is one very odd thing that I have noticed on my home machine though. My rings code uses OpenMP for multithreading and big simulations typically run on all eight cores of my home machine. Smaller simulations often sit at a load of 5-7. I started a large simulation using x86 Open64 and it keeps all 8 cores busy. However, smaller simulations that run through steps really quickly are running at loads of 3-4. The load level is also far less ragged than what I had seen with the Intel compiler. At this point I can't say if this is a good thing or not. At first I worried it wasn't properly parallelizing. Now I'm wondering if it just does a better job of keeping jobs to specific cores and keeping those cores loaded instead of having stuff jump around. That would certainly be a smart thing to do as it would improve cache performance, but only benchmarking and profiling will tell me for certain.

LyX

2010-08-24T09:43:00.000-07:00

This blog has been dormant for a while because I spent a week in Oklahoma visiting my wife's dad with the family. It's a good place for me to get work done that can be done offline. Many of the tasks that I normally procrastinate get done there. This year I worked on papers and textbooks. The Scala book started getting a bit big and I thought maybe I should try out a different tool. There are lots of reasons why big documents should be done in LaTeX. I've been well aware of the arguments. I just haven't been willing to clutter my brain with the extra commands. LaTeX, like many other tools along those lines, has a decent learning curve and you can't do much of anything until you have climbed a fair bit of the curve. I also like OpenOffice for the GUI. I didn't want to edit my big documents in vi.

I had looked around for GUI programs that sit on top of LaTeX and already had this program called LyX installed. I had played with it just a bit, but not enough to figure out anything about it. They said read the manuals and after a few paragraphs they lost my attention so I stuck with OpenOffice. Oklahoma provided more time though and with the Scala book getting to 100 pages I decided it was time to seriously try it out. The book was long enough to benefit from the LaTeX advantages and if it got much bigger I wasn't going to be willing to convert it.

So I did a massive cut and paste and started reformatting. It took a fair bit of a day, but the result was definitely worth it. Seeing the wonderful and automatically generated Table of Contents for the first time made it worth while. As I have learned more about LyX I have been able to use more capabilities. It is a really nice way to interact with LaTeX. I highly recommend it to anyone who has thought that LaTeX might be nice but wasn't willing to climb the learning curve to get started. You can even have it show you the LaTeX source as you write so it can help you learn LaTeX along the way.

Another Huge Simulation

2010-08-06T09:31:00.000-07:00

I've talked some in earlier posts about the F ring simulation that I recently started. I've now posted a fair bit from that simulation including plots and movies that are constantly being updated as the simulation advances. Just today I started another simulation. This one is related to my work on Negative Diffusion. I have a paper that I submitted to Icarus and got back a review for on the topic. The reviewers wanted a number of changes that I hope to get done before the beginning of classes.

One of the issues with this work is that I have to use some interesting boundary conditions to use a local cell with a perturbing moon. These boundary conditions wrap particles in the azimuthal direction such that they preserve the gradient in the epicyclic phase induced by the rate of passage of the cell by the moon. These boundary conditions aren't something that everyone uses. One reviewer wanted me to explain them better, which I can certainly do. However, I realized something that I had thought of before which was that to really convince people, I needed to do a large simulation without the periodic local cell, something more global, and show that the same thing happens. I know it will work because I have seen this behavior in global simulations of the F ring and nearly global simulations of the Keeler gap. I know that this isn't a result of the boundary conditions. However, I feel it would be good to do this with a simulation that basically matches what I had done for one of the local cell simulations for a direct confirmation. The only problem is, there was a reason I was using a local cell. With a local cell these simulations only need 10^5 - 10^6 particles. If you don't use a local cell, the requirements get a lot higher.

So I just started the simulation using 14 nodes of my cluster. That's 112 cores and 112 GB of RAM. I tried using a particle size at the top end of what I had used in the paper. Unfortunately, that ran into swapping. It had nearly 400 million particles and the master machine wasn't happy about that. It wasn't so big that it flat out crashed, but it was just big enough that the memory footprint caused it to run too slowly. So I increased the particle size just a bit to a 156 cm diameter. This gives me just under 266 million particles. That's still a huge simulation, but it is just small enough that it runs without the master doing significant swapping.

I started the simulation this morning and I looked at the first output and things seem to be going well. It looks like it will take about 5 hours per orbit and get to the point where conclusions can be made in a little over a month. That's pretty good for the biggest simulation I've ever run.

First snapshots of F ring simulation (and a comment on moonlets)

2010-08-03T21:23:00.000-07:00

I described in an earlier post the mother of all F ring simulations. This has now gone far enough that I feel I can say it is working properly and I can make a plot of what it happening in the early going. I have put this up on my normal research site. I have a fair bit of discussion along with two plots. The plots don't show all that much beyond the initial configuration because there simply hasn't been that much time for the system to evolve yet. Still, I think they will give anyone with a feel for the F ring a feel for what this simulation might be able to show us.

It also hit me this evening that while I feel like this simulation isn't running all that fast, the reality is that it is running in close to real time. It finishes an orbit in about 7 hours. The real material in the F ring takes almost that long to get around Saturn. So on the whole I'd say that is pretty good. Maybe after this one has gone far enough to wipe out the transients I can consider scaling it up a bit more. I'd be really interested in seeing what happens if I make it so that Prometheus really does run into the apron of material at the edge of the ring. I expect the computers will be less than happy about such an experiment though.

As a side note, on the recommendation of Matt Tiscareno I did some simulations on moonlet stability that didn't include the background. Unlike previous work by Porco, et al., I am not putting a large central core into these moonlets. I am assuming all particles of nearly the same size. This is significant because the Hill sphere of the large body can enclose nearby smaller bodies when two bodies of the same size sit largely outside of one another's Hill spheres. I was able to find a configuration where a moonlet was stable without background material and got broken up when background material was present. The moonlet was made as a lattice roughly filling a triaxial ellipsoid at 130,000 km from Saturn. The lowest density I could get to be stable i this configuration with a 2:1:1 ratio was a bulk density of 0.7 g/cm^3 or 1.0 g/cm^3 for the constituent bodies. Even with that high a density, it got knocked apart when I put it in a background. I'm not going to be doing too much more work on this right now because Crosby found it interesting and will likely work on it as part of his senior research project in Physics.

Writing a Scala Textbook

2010-08-03T12:19:00.000-07:00

So this coming fall I am going to be teaching the CS1 course at Trinity (CSCI 1320) using Scala. This is part of an experiment we are conducting to see how we might want to change the languages used in our introductory sequence. One of the challenges in using Scala is that there really aren't that many resources currently out for the language and none that work as a textbook for new programmers. All the current material assumes that students know how to program in one or more other languages and then builds on top of that. To address this, I am writing my own materials going into the beginning of the semester.

I have done this previously for Java with our CS2 (CSCI 1321) and CS0.5 (CSCI 1311), the latter using Greenfoot which also didn't have an existing text when I started using it. In some ways, the topics of introductory CS are the same no matter what language you use. However, the nature of the language can alter the ideal way to present information.

As it stands, we intend to keep our CS1 as a normal introduction to programming. We don't want this to be an objects-first type of class. The second semester will get into OO. The first semester is just about building logic and figuring out how to break programs down and use a programming language to construct solutions. So while Scala is 100% OO, that isn't being stressed early on. The functional aspects can be stressed early on.

Indeed, it is the more functional side that convinced me that Scala was worth trying to a CS1 course. Scala has a REPL and allows writing scripts. It works very well for programming in the small. However, unlike normal scripting languages, Scala is statically typed so students get to learn about types and see compile time error messages. Indeed, I'm hoping to run the class very much like what I have done in C for the last decade or so. We will work in Linux with the command line. They will edit scripts with vi. Unlike C, they can use the REPL to test out little things or load in the code from files instead of running them as standalone scripts.

Using Scala as the language though does change some aspects of what I see as the optimal order of presentation. It also adds richness to certain other topics. The big ones I've run into so far are functions and collections. Normally I do my introduction to Linux and the basics of C. Then I talk about binary numbers. That is followed by sequential execution, functions, conditional execution, and recursion. After that will come loops and arrays. In Scala, the functions aspect gets richer because it is a functional language. It has function literals that can be created on the fly. It is possible to easily pass functions as arguments and return them. In C, function pointers and void* were about the only topics I didn't cover. Those same ideas will be covered in Scala and early on because they are a lot smoother.

The biggest change so far though is where I am doing "arrays". In C there wasn't really any point introducing arrays until you had loops. You simply couldn't do much with an array without a loop. That isn't true in Scala. Collections in Scala, be they arrays, lists, whatever, have a rich set of methods defined for them. Indeed, the Scala for loop does nothing more than translate to calls of these other methods. So in Scala the logic goes the other way. Because they know functions, it makes sense to introduce collections and talk about the methods like map, filter, and reduce. Once those have been covered, then we talk about loops and see how they provide us with a nicer way to write a lot of the iteration behavior that we had done before using either recursion or higher order functions on collections.

One thing that I haven't figured out exactly how to include is Ranges. These are really significant in for loops. If you just want to have a counting for loop in Scala you would write for(i <- 1 to 10). The 1 to 10 creates a range which is an iterable over exactly those values. They have a lot more power too. The question is, do they go in the chapter on collections or in the chapter on loops with the for? The chapter on collections is already going to have quite a bit in it and right now I was planning to cover only arrays and lists. Those are basically the most fundamental mutable and immutable collections respectively. The range almost seems out of place at that point and it opens up a whole big area of the fact that there are a lot of other types of iterables, sequences, etc. in Scala. That will have to get opened at some point though. The question is whether to do it with the other collections or wait until they are really needed with the for loop.

If anyone has suggestions on this, please post a comment. One thing I would point out is that higher order functions on ranges can be fun to play with as well. The for loop isn't really needed. To see this, just consider the following definition of factorial for positive numbers.

def fact(n:Int) = (1 to n).product

So the range isn't just for counting in a loop. That just happens to be the wa most people will use it by default.

Update on F ring

2010-08-02T20:24:00.000-07:00

So after watching the F ring simulation I described earlier go for the weekend, I made some changed and updates. While this forced me to stop the simulation and lose what I had done over the weekend, one of the changes was to use a longer time step because this is a sparse simulation with gravity. The result is that now it is doing an orbit in under 8 hours instead of 36. That factor of 4.5 is huge considering it was looking like this would require 2 years to get anything significant done. Now it should have nice results in 6 months and be in a very good spot by next summer when I will have the time to really go look at what is happening.

The early stuff is fascinating. In particular, I gave the moons inclination, something I had never done before, and they are giving it to the ring. Because gravity is a 1/r^2 force, proximity matters more than elevation. So the ring gets its maximum inclination near the point of closest approach and not when the moon is at maximum elevation.

One of the big questions is how the inclination will impact negative diffusion. It is possible that it could lead to more vertical displacement and less migration of semimajor axis. Only by going through the simulations will I know for certain. I expect that I will have some results to put on my main web site before classes start. Of course, when I do I will put a post here telling all about it.

The mother of all F ring simulations

2010-07-31T06:06:00.000-07:00

There was a paper published recently on new observations of the F ring. The F ring is a very dynamic narrow ring a bit outside of Saturn's main rings. The main reason it is so dynamic is that it has two moons that orbit near it, Prometheus and Pandora. I have done some of my own work on the F ring because it is a fun system to simulate. I started with simulations that included just Prometheus. Putting Prometheus on an eccentric orbit alone is challenging because it forces the simulation to use a fairly large cell size. The cell needs to have dimensions such that the full cell drifts past Prometheus in one orbit of the moon so that the perturbations on the two edges match and wrapping doesn't create a discontinuity.

If you only have Prometheus though, you create a ring that is perfectly periodic and the real F ring isn't. To break this, you need to include Pandora. The problem is, if you include Pandora you lose any chance to have a small cell. Prometheus and Pandora are not in a mean motion resonance so to have proper boundaries, the simulation has to be global. This means that it needs to go all the way around Saturn. A few years ago I spent some computer time doing a global F ring simulation with Prometheus and Pandora, both on eccentric orbits.

The movie shows an initially uniform ring getting kicks from the moons. The kicks from Prometheus are larger than those from Pandora because of size and proximity. It shows how collisions in the compression regions lead to negative diffusion and cause the ring material to move into a tight core. It also shows fairly complex structures forming.

While significant, this simulation has three significant limitations. First, the radial extent of the particles is too small. Second, the F ring is circular when in reality the ring is eccentric. Third, there is no self-gravity between the ring particles. I have tried at times to address different parts of this. In fact, I ran an eccentric ring simulation for a while. However, the guiding center coordinates we normally use do not handle this properly and I got an artificial precession of the rings relative to the moons. Now I am giving it another shot and trying to run what you might call the mother of all F ring simulations. First, I spread out the particle distribution a fair bit. It is now a Gaussian that covers roughly 100 km radially. Second, I'm using an extended form of the guiding center coordinates that Glen Stewart derived as they should handle the eccentric ring properly. Third, everything is self-gravitating. Even the moons are normal particles having normal gravity and collisions.

This simulation has 50 million particles in it. The down side of doing that with full self-gravity is that even though I am doing it across 12 machines and 96 cores, it is taking about 1.5 days to complete an orbit. At that rate, it will complete about two synodic periods in a year. From earlier work I know that I need 3-4 synodic periods before the system will get out of the transient state. Maybe I need to ask someone for some faster computers. :)

Ring Dynamics Work

2010-07-27T16:04:00.000-07:00

While the summer session is just about ended for my research students, there continue to be interesting results that they are documenting on the wiki. Cameron is doing timing results on the lock graph. He is comparing it to the older lock grid for some different simulations. The results aren't exactly what would have been predicted. He'll finish out the week looking at some other systems.

Crosby has gone back to looking at the silicate hiding simulations. He had looked at the A ring previously. Now he is looking at the B ring simulations. There are unexpected results here as well. In the A ring he found that the reflected light was only showing silicate with 25% of the amount of silicates present. So if 4% of the particles were silicate, only 1% of the light would be coming off silicate particles. This 25% was consistent across 4%, 2%, and 1% silicate fractions. The B ring simulations are confusing because it isn't a constant fraction. A lot more exploration is needed here. he'll also have to look at the C ring simulations that have been done.

Lastly, I continue to look at moonlet stability. On a suggestion from Matt Tiscareno I looked at stability without the background. This showed me that I had upped my time step too high based on stuff I did earlier this summer looking for optimal speed. However, there is still a story here. I found the break point in density for where a lattice of equal sized particles is stable at 130,000km. This is a higher density than what was found by Porco, et al. (2007) for a bunch of rubble on a single large core. I took the lowest density value for which I got a stable moonlet alone and dropped in into the background. The simulation hasn't gone all that far, but it is already apparent that the moonlet is being broken up by collisions. Here again there is a lot more work to do. In fact, it looks like this might be an area that Crosby uses for his senior thesis. It has the advantage that the simulations looking at stability in moonlets without background are fairly small simulations and he can run a bunch of them. He has done a little bit to document the experiments that he will look at running.

Design of ScalaVis

2010-07-21T15:35:00.001-07:00

I spent some time this weekend working on the design of ScalaVis. The goals of the project are to include all the capabilities currently in SwiftVis in the GUI and also enable scripting or interactive usage with the REPL. The SwiftVis design goals of a free, platform independent data analysis/exploration/plotting package with decent speed pointed nicely to Java. However, Java doesn't include an REPL or real scripting ability. Scala does. While Scala can call Java code seamlessly, it isn't possible to easily retrofit SwiftVis into scripting because so many of the settings are completely encapsulated and can only be accessed through the GUI.

The design I came up with leverages the functional nature of Scala and data-flow programming. There is a concept of Elements which are basically functional data transformers. You can script or work interactively with Elements. On top of that sits Builders. As the name implies, Builders are supposed to build elements. They will go into the GUI and have graphical representations and GUI components that enable altering settings.

I have also been working on making the GUI construction aspect easier. The Scala Swing library helps with this to a certain extent. However, I am trying to push it further so that there are more reusable pieces and people have to create fewer components on their own.

Abrupting Moonlets

2010-07-19T08:55:00.000-07:00

Lots of simulation and programming stuff going on here. Some I'll be showing tomorrow or so. Others I'll post about later today. The cool result of the morning though is that our moonlets keep getting busted up. Over the weekend I did a simulation where the moonlet was set to model a density of 0.5 g/cm^3 (particle internal density of 0.5/0.7 g/cm^3) with larger pieces in the lattice. It still got sheared out. So next up was to go back to the smaller particles with a higher density. I started a simulation with a lattice modeling 0.6 g/cm^3. When I came in this morning I loaded it up and while the moonlet is holding together better than before, it isn't going to make it. It is still falling apart.

This is very significant because those particles have an internal density of 0.85 g/cm^3. That is close to the density of solid ice, yet they aren't holding together against the impacts of the outside size distribution. Next up is modeling 0.7 g/cm^3 and a particle density of 1.0 g/cm^3. At that point though you pretty much have to say that internal strength is playing a role in holding these things together.

ScalaVis

2010-07-16T09:48:00.000-07:00

This year I have become really fond of the Scala programming language. It is a better Java than Java with functional elements that make it highly expressive. I expect that there will be a lot more posts on this blog related to Scala in the future. Also, for the last decade or so, I have been working on a data analysis, exploration, and plotting package to use with N-Body simulations called SwiftVis (page, Wiki). I am very fond of SwiftVis and use it for all of the data analysis on my ring simulations. It is also used by a number of other researchers and some of my former students.

The original design goals of SwiftVis included that it be free, multiplatform, have fairly good speed, and not require users to program. The first three requirements made Java an obvious choice for the development. The last requirement, while very beneficial can be a limitation if taken too far. SwiftVis is very flexible and easy to extend. However, the only way to interact with it is through the GUI. Many of the components in SwiftVis could be more useful than they currently are if they weren't locked into this one GUI.

While there are many things I like about Scala, one of the things I caught onto later, especially as it pertains to education, was the power offered by the fact that it has a REPL and scripting capabilities. It also has the ability to call Java code directly. Putting all of these things together I've been picturing in my head a new program that has all the power and extensibility of SwiftVis, but written in Scala in a way that also brings in serious programming interactivity. I'm also hoping to simplify the way in which GUI controls would be written.

I intend to keep the current data flow system that is in SwiftVis in this new work. One of the big questions is how to deal with the data. SwiftVis sends everything around as DataElements. A DataElement has an array of ints and an array of floating point numbers. Having the int is a bit of a pain in the code, takes memory, and in practice it doesn't add all that much to the code. On the other hand, there have been times when it might have been nice to have other types of data in the elements. My current thought is to start with just having double values. I'll have to do some memory testing to see if it is better to use a Vector in Scala or if I should create my own type that wraps an array to make it immutable. The answer to that depends on whether the Vector class will compile to primitives the way the array does.

At this point I have pretty much convinced myself that this is a project I would enjoy and that is worth my time. Now I just need to play with it some to get the design off the ground.

Numerical Significance of Coefficient of Restitution

2010-07-16T07:00:00.001-07:00

Long ago I learned the my simulation code didn't like using a fixed coefficient of restitution. It was fine with the Bridges et al. velocity dependent coefficient of restitution, but if I used a fixed value of 0.5 it would run much slower and potentially grind to a halt processing a huge number of collisions. This didn't bother me with rings because I consider Bridges et al. to be more realistic anyway. However, I started using a fixed value in my work with Josh and as such, I needed a way around this.

The actual problem, it turns out, is that at very low velocities, the Bridges et al. becomes conservative. So when particles go into a "rolling" state, they actually do little bounces and the size of the bounces stays fixed. Without this, the bounce size keeps decreasing and we get a Zenoish behavior where the bounce frequency increases over time. So the fix was to make it so that if the velocity is sufficiently small, the coefficient of restitution goes to 1.0. I made this change fairly early on this summer for particle collisions. However, I hadn't made it for the bounces off the surfaces in my work with Josh. I learned last night that was a bad idea.

In my setup simulation where I pack the spheres into the proper shape, I found it would get a lot slower toward the end of the simulation. That trend continued when I put in the marble and let it drop. Last night I decided I'd try altering the coefficient of restitution with the walls in the same way I had done with particle collisions to see if that helped. It worked wonderfully. Without the change the number of collision checks went up with every step and was getting way out of control. (I was seeing numbers over 300 million.) With the change the collision checking numbers actually went down a little bit and the simulation continues to run quickly instead of slowly grinding down.

Sometimes it is good to push a simulation code in different directions. It helps you understand their behavior better and can show you optimization possibilities that you hadn't known existed.

Density/Strength Requirements on Moonlets

2010-07-15T13:11:00.000-07:00

So as my last post indicated, one of my most recent moonlet simulations had the interesting result that the moonlet fell apart within an orbit. This wasn't at all expected and it was something I hadn't seen before so it begs the question of why it happened. My first work with moonlets couldn't have this happen because the moonlets were single large particles. Having so many small particles resting on a single large particle though is computationally intensive. As such, when I started doing higher resolution simulations I switched to making the moonlet out of a lattice of smaller particles. They are bigger than the background particles and have their internal density enhanced by 1/0.7 to account for the fact that such a lattice doesn't completely fill the space the moonlet would have.

This had been working fine in all of my earlier tests. So what changed? I lowered the density of the particles in the lattice moonlet. Earlier I had things set up to model a moonlet with a density of 0.8 g/cm^3. So the individual particles had a density of 0.8/0.7 g/cm^3. That makes them fairly high density and their gravity holds them together. For this most recent simulation, the lattice was made of smaller particles and it was set to model a moonlet with internal density of 0.5 g/cm^3. So the actual particles have a density of 0.5/0.7 g/cm^3.

I'm currently running another simulation with this lower density and a bigger moonlet. Stay tuned to hear if it falls apart. (Early indications are that it will.) Hopefully I'll know by tomorrow. If not, I'll definitely know by Monday. If it does fall apart, that will begin a search for what parameters are required to make it hold together.

The more interesting question is, what does this say about real moonlets? The simulation uses perfect, smooth spheres with no adhesion. So the moonlet has no internal strength. Only gravity is holding it together. What these simulations are indicating is that the bounds on what gravity can hold together might be lower than many people expect. Collisions might be more efficient at breaking things apart than had previously been expected. So are real moonlets higher density? Do they have real internal strength instead of being just rubble piles? What would either of these say about the formation scenarios for moonlets?

Update: The moonlet did indeed get broken up and start to shear out. Now I'm trying a moonlet using a lattice of larger particles. If that also gets destroyed then I will begin a search for the required internal density.

Moonlet Surprise

2010-07-15T06:41:00.001-07:00

So Crosby has been working on doing data analysis on the higher resolution moonlet simulations that I had done over the last two years or so. These simulations use smaller particles in the background and were intended to help answer the question of exactly what we are seeing with small propellers in the rings. He has made some movies that I will put up on the rings research page under the second moonlets paper. We have seen huge differences in what appears based on the size of the moonlet. Yesterday we got another surprise as well. I had started a new simulation that had a size distribution in the hopes that we could get a better feel for how that impacts things. I made some other changes to this particular simulation as well. I upped the surface density and lowered the internal particle density to try to better match what other people have been using. The result, the moonlet fell apart.

That last bit needs some explaining. For numerical reasons I stopped using a single large particle for my moonlet a while back. Instead, I use a lattice of spheres with an enhanced density so the total mass matches that of a single sphere. In my other simulations this has worked great and the lattice holds together. In this one, it got knocked to pieces in just one orbit. We haven't worked out all the implications of this, but here are a few possibilities.

The internal density of constituent parts of moonlets has to be high enough so this doesn't happen.
The moonlets can't be loose rubble piles. They have to have physical strength.
The constituent pieces of a moonlet have to be significantly larger than the top end of the surrounding size distribution.

Granted, it could be some combination of these. In this simulation, the moonlet was fairly small too so I need to do something with a larger moonlet without varying anything else and see if it gets broken up.

Lock Graph Implementation

2010-07-14T15:41:00.000-07:00

So I got the "lock graph" implemented today. Crosby has also found some cool things about moonlets. I'll have to write that up in more detail later. I also started a Wiki for my research students. I'm optimistic that might make my life easier when it comes to keeping track of what they are doing.

Constant Acceleration Population

2010-07-13T04:34:00.001-07:00

I couldn't sleep this morning. Woke up around 4am or so and just couldn't get my mind back to rest. That will make for a less than ideal day, but it had one significant positive. My brain was working on some useful ideas. The main one, and the one that finally pulled me out of bed to code it up, was to add a constant acceleration to my BasicPopulation. That sentence probably needs a bit of explanation.

My simulation code is rather modular. One of the more significant modules is an element called a population. The population keeps track of the bodies in the simulation and has logic in it to handle their movement, find collision times, process collisions, etc. I basically have two populations that I use. My ring simulations use what I call the GCPopulation. GC stands for guiding center. In this population, the particles don't move on straight lines. Instead, they follow guiding center motion which is a first order analytic solution to Hill's equations. This complicates collision finding, but has benefits that make it well worth while otherwise. Basically, the gravity of Saturn is implicit.

For general research purposes when I want to look at other types of systems I have created a "BasicPopulation". In this population particles travel on straight lines between collisions in the middle of a time step. I was using this for the simulations for Josh and I had a second force of constant acceleration in addition to the collision forcing.

This constant acceleration causes some issues numerically that are best resolved by taking small time steps. This is common in numerical integrations. The integration is more accurate if you take smaller time steps. The simulation also really grinds at the end when the particles are sitting right on top of one another in a close packed configuration. Part of the reason it grinds in this configuration is that the gravity force is applied as a kick at the beginning of the time step and all the particles are given a downward motion which then has to be canceled out by collisions propagating back up through them.

The thing about constant acceleration is that you really don't need a numerical integrator. There is a nice analytic solution to the motion, it is a parabola. So the idea was to create a population that uses that motion somewhat like the GCPopulation uses guiding center motion. When I turned this around in my head a bit (and didn't fall back asleep as a result) I realized that I didn't even need a new population. It's an easy addition to the BasicPopulation. How easy? Turns out to be one line. It was a little harder to make it so one other element of the simulation would work, but that wasn't too bad either. Now I'm testing it.

Why do I care? My hope is that at this will have a very helpful impact on the end of the simulation when all the particles are tight packed. Without the constant acceleration force the particles won't all be given a kick in the downward direction. Instead, they will follow a true parabola with a derivative of zero at apex. This should provide much nicer numerical behavior at that point and allow me to take larger time steps because I don't have to worry about numerical accuracy of the integration.

Now if I can just get that locking graph completed so I can drop a marble on the final configuration.

Two Argument Recursion

2010-07-12T18:45:00.000-07:00

So today Cameron Swords and I talked through a possible solution to the problem of the last post. The solution involves using the tree to build a graph of "lock nodes". These are nodes in the tree that we use as locks instead of having a grid of locks to tell us if a collision is safe. In theory this method should work quite well. It will be as dynamic and optimized as the tree and have little additional overhead. For simulations with a size distribution of a dynamic distribution of particle relative velocities, it should provide optimal locking to keep the simulation running nicely on multiple threads.

One little detail of this method that I felt was worth commenting on was the creation of this graph. The "lock nodes" need to have some basic properties. There should be one on the path between the root and any leaf. It could be the leaf. (In theory it could be the root, but that would suck because there would be no parallelism in the collisions.) We would also like to use nodes that are as far down the tree as possible without making the graph too dense. The edges in the graph connect nodes that are sufficiently close that it isn't safe to do collisions in both at the same time. So we want nodes that have a size on the order of the search distance for collision pairs. Identifying these nodes isn't that hard. It can be done with a nice recursive decent. Once we have them we would have to build the graph which could be done easily in code by doing a recursive decent for each of the lock nodes. Such an approach is easy to describe and would be O(n log n) with a coefficient that isn't huge so it wouldn't be the limiting factor in the simulation. However, there is a better way.

This better way, as the title of this post alludes to, is to do recursion over two arguments. In this way, we can identify the lock nodes and build the graph all in a single recursive call. However, that recursive call now recurses on two arguments and basically runs through pairs of nodes. The advantage is that it prevents it from doing work on the top potion of the tree multiple times and should provide something close to that absolute minimum work needed to identify all of the pairings needed for the graph.

This isn't the first time I have used this type of method. In fact, it is the fourth time and the third time in this particular simulation code. I first used the method for my implementation of a symplectic tree code that I have worked on with Hal Levison. In that code the interactions occur only between nodes on the same level of the tree. As such, the two argument recursion makes great sense. I had never seen it used before and still haven't, so for all I know, it hasn't been widely discovered as an approach for numerical work.

My second use was in the collision finding in my main simulation code when a tree is used for finding the collisions. More recently I updated gravity to use it as well. In the case of gravity, switching to this approach dropped the number of distance calculations and improved code performance by a factor of 2-3 times. Now it looks like I'll be using it a fourth time to find pairs of lock nodes that should have edges between them in the gravity/collision tree.

As a general method, what this approach does is to efficiently run through and identify pairs of nodes in a tree when there is a criteria that can eliminate subtrees from consideration. In my work, the criteria is a distance issue, but it could be other things. This could also be generalized to recursion over three or more arguments for finding triples, etc. What makes it efficient is that the recursion doesn't pass over the top level nodes doing the check for inclusion multiple times. Instead, it goes through them once for each argument that it is recursing on and then goes on down to other pairs where the check is more significant.

(Interested readers might wonder how one could make a single recursive call like this operate in parallel. If anyone requests a description of how we have found to do that in a way that leads to generally good load balancing, I'd be happy to post it at that time.)

Collision Dynamics and Granular Flows

2010-07-12T08:16:00.001-07:00

So my main field of research is numerical simulations of planetary rings. I keep a page on this work on my main site. Recently I've started working with Josh Colwell at the University of Central Florida on a slightly different project. Josh's project is intended to look at particle collisions to help develop our understanding of accretion in the early stages of planet formation. My role is to do some simulations to compare to the experiments.

Originally I was just going to do simulations of particles orbiting in heliocentric space. Another code was going to be used to do direct comparisons with the simulations. However, this summer I decided I could probably do some of that work with my code. I've been working on that and I have posted a few movies showing this work. This morning though I hit a snag that will take some creative thinking to get around. The problem came when I added a larger impactor body into the simulation to strike the pile of glass spheres that had piled up. Adding this larger impactor caused some problems for the parallel locking mechanism that the code uses. First, the code assumes a fairly 2-D distribution of particles. That's a rather safe assumption for rings. It isn't a very good one for these simulations. It also uses a uniform grid which gets really course when I introduce the large particle.

The code is using a kD-tree to efficiently find collisions. That structure is very dynamic. The nodes have good information on relative velocities and the sizes of particles in them. That makes it very good for non-uniform distributions and also for 3-D simulations. However, the locking mechanism doesn't use the tree. This is because locking needs to be very fast. Grids are O(1) with a small coefficient. Trees are O(log n) with a higher coefficient. We don't want the code that checks if collisions are safe to take more time than the code that actually processes the collisions. So the question is, how can we get around this? That will be my creative thinking exercise for the day.

First Post

2010-07-11T20:58:00.000-07:00

Welcome to the "Dynamics of Programming" blog. This is my first step into blogging. It was somewhat suggested by a former student of mine so I'm trying it out. The title of the blog deals with two of my significant interest, dynamics and programmings. I do research work on planetary dynamics through numerical simulations. I also have a strong interest in programming, programming languages, and teaching programming as my position is Associate Professor in the Department of Computer Science at Trinity University. While this blog will largely be about my personal musing and a place to collect some ideas, perhaps something will appear occasionally that other people find worth reading.