Monthly Archives: October 2013

Writing

What is intelligence?

Leave a comment

What is intelligence?

This question is particularly relevant for people who want to create it (Artificial Intelligence). And it’s a hard question to answer, because “I’m intelligent” may be a true answer, but it’s not a useful answer.

For some, the summary is:

An agent’s ability to achieve goals in a wide range of environments.

(see interview: Marcus Hutter—Universal Artificial Intelligence)

This is not a bad answer, but it might be a little circular. It’s certainly vague, and does not guide us towards creating intelligence, nor even ranking it. Is an entity that can achieve goals quickly in some environments better or worse than an entity that can achieve goals slowly in a lot of environments? Also, do entities achieve the goals they set out to master, or do they achieve goals as an accident of existing? I’m not trying to belittle what Marcus Hutter is saying, far from it.

There’s a problem with theories that start with information, such as Kolmogorov complexity or Chaitin’s Omega; they assume that information can’t be created from nothing. I have a suspicion that this is false, and that this is related to life, to animate matter versus inanimate matter. Agents that operate by gathering information and learning seem to have this pernicious underlying theory that information is external. But what if agents generate information by their very existence?

Gendankenexperiments are often the best experiments. After all, Einstein did most of his work this way. So let’s posit two universes:

  • a universe with no life
  • a universe with life

Would they turn out the same? Absolutely not. Would they have the same amount of information in them? It seems that the first universe would have far more information in it than the second (the Mona Lisa, the Great Wall of China, and so on). So either I’m wrong, or the first universe, having life in it, generated information.

I agree that we can be modeled in some respects as agents: we get information, we evaluate it, we make decisions. But we also do more than our inputs. At this point, evolution seems like a safe bet, and we seem like we are more complicated than the single-cell forms of life from 1 billion years ago. We have more information now than the Earth had 1 billion years ago. There’s a feedback loop, then; we may take in information, but we also create it.

So a theory of intelligence has to also explain how information can be created. In fact, I’m going to posit that life creates information, and intelligence creates information deliberately, rather than emergently.

Which makes it tough for simple theories of agents and their utility functions. But it’s also awesome; life is not a zero-sum game.

In my opinion. Which I’ll attempt to turn into fact at some point.

Operating systems

Changing environment variables programmatically

Leave a comment

Some programs communicate through environment variables.

Windows

System Environment variables are stored in the registry, in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. REG_SZ entries are copied as-is, whereas REG_EXPAND_SZ entries are interpolated first against boot variables like SystemRoot.

Note that cmd.exe windows load environment variables when the window is created. Temporary changes can be made with the cmd.exe SET command, but I’m not sure how you’d access that from code.

Actually, it seems like cmd.exe is supposed to respect WM_SETTINGCHANGE messages. Should try that.

http://us.generation-nt.com/changing-environment-variables-programatically-help-57874242.html

Mac OS X

Environment variables can be set in environment.plist for GUI applications, or .profile or .bash_profile ior .bash_rc for Terminal programs running in the bash shell. Changes to one of these files are not reflected until a new terminal is opened, or the affected file is sourced into the existing environment (e.g. “source .bash_profile”). But I’m not sure how to do that programmatically. Note that “. .bash_profile” is a shortcut for “source .bash_profile” — the wonders of magic shortcuts in Unix.

  • ~/.MacOSX/environment.plist
  • ~/.bash_profile
  • ~/.profile

http://stackoverflow.com/questions/7501678/set-environment-variables-on-mac-os-x-lion

Linux

Environment variables for shells would be set in ~/.profile etc. Still need a way to set it programmatically. For LSB compliant systems, you can create a script in /etc/profile.d/ named the same as your program, and it will be run first. And I think /etc/profile is run before all programs.

http://stackoverflow.com/questions/3416638/set-environment-variables-in-c

http://stackoverflow.com/questions/2891972/how-to-programatically-set-a-permanent-environment-variable-in-linux

 

Revision control

Git tidbits

Leave a comment

There’s a new Git GUI on Windows: https://github.com/kaisellgren/Git-GUI. It uses libgit2 and .NET 4.5.

GitHub for Windows is also libgit2+.NET: https://github.com/blog/1127-github-for-windows, and interoperates with the GitHub site. However, since libgit2 isn’t yet feature-complete, GitHub for Windows also uses msysGit where necessary.

Since libgit2 has pluggable backends, people have used it to store Git repositories in databases: https://deveo.com/blog/2013/06/19/your-git-repository-in-a-database-pluggable-backends-in-libgit2/. Some existing backends include Memcached, MySQL, Redis and SQLite.

Revision control

Revision control – past, present and future

Leave a comment

I’d like to write a comprehensive book on revision control at some point. This is not even the start of that, but I’m going to record a few trends.

I’m going to cover the revision control systems that sprang to life as part of the BitKeeper debacle, because those are the most interesting ones to consider.

Monotone never really existed

Monotone was the template that both Mercurial and Git copied. However, monotone always followed a very purist model, and was dreadfully slow for many years. It caught up in speed somewhat, but has very few users.

Development is sparse, only a few commits in the past 6 months, and mostly bug fixes or translations.

Bazaar is dead

There have been no significant public changes to Bazaar in the past year. It’s been declining for years, and insiders admit that the focus changed from “Bazaar as a decent general-purpose version control system” to “ensuring that Bazaar worked well for package management in the Ubuntu project”.

There’s been some polite exchanges saying that many Bazaar architectural directions were superior to Git, but I have to disagree. The architecture of Bazaar informed the implementation, and the implementation is second-rate compared to Git or Mercurial. That said, some of the things Bazaar attempted were good ideas, and maybe those ideas can be transplanted somewhere else.

By “no changes”, I mean that there have been virtually no commits to Bazaar itself since mid 2012. There have been 7 commits in the past 30 days, 144 commits in the past year, and almost none of those are commits that will get released.

Some relevant links

Mercurial is slowing down

While Mercurial is doing far better than Bazaar, it’s growth seems to have been slowing down markedly. It has some big advantages, though: since it’s written in Python, the Windows client is as good as the Mac or Linux client. It has local revision numbers, which are far easier to deal with cognitively than hashes. Since it’s written in Python, it can be scripted in Python very reliably. It arguably has very clean and comprehensive documentation.

But it’s written in Python. It has a relatively weak branching model (so weak that cloning was the branching model pushed for many years, and cloning is not good for merging or comparing history). It doesn’t do rebase very well. And it’s getting new users at a far slower rate than Git, the emerging leader. And the rate of development of Mercurial itself is about half that of Git for the past 12 months. It’s of course moderately hard to compare a Python project to a C project.

Still, Mercurial isn’t dying. It’s perhaps more accurate to say that it’s reached its level. Fortunately, it’s fairly easy to go between Mercurial and Git. I predict that Mercurial will eventually completely lose to Git, largely because of the decision to use revlog approach instead of a blob approach. Blobs are more bookkeeping for moderate projects, but give more flexibility for large projects with lots of history.

One brilliant idea that was problematic in execution was Mercurial extensions. It’s super-easy to extend Mercurial with an extension. But then, you have a custom Mercurial install that you need to replicate to others if you need them to use your extension. Why not put extensions in repositories? Hmm, I should implement that change and push it upstream.

Git

Git is taking over the world, although that might be due in large part to Github. While Subversion still seems to be the dominant open-source revision control system, most of that is inertia. Few new projects are choosing Subversion, and none are choosing CVS.

There are alternate implementations of Git. Github itself uses a Ruby version, and uses libgit2 for Github for Windows.

I need to analyse Git’s status more accurately, I’m an admitted partisan.

Git weaknesses

  • no partial repository support (although you can permanently drop old history)
  • falls down on gigantic repositories (10+ GB repository not pleasant)
  • no good way to use multiple repositories together (git submodule is sub-par)
  • no human-understandable version number

Some references:

Veracity is a dark horse

SourceGear switched direction several years back and is trying to be a player in distributed revision control with Veracity. I read a lot of the book that was released, but I haven’t yet used Veracity. It hasn’t made much of a dent in the landscape yet, but since it’s very polished, it could get a lot of enterprise customers.

The impressive part is that it’s an open-source project, which is a big step for a company to take, but probably an essential one in order to compete with Git. So, since it’s open-source, it might survive SourceGear; not that SourceGear is in any immediate danger, but it is a project that’s being run by a commercial company, and those tend to live and die with the company.

Build systems

Nix, a purely functional package manager

Leave a comment

http://nixos.org/nix/

There’s a lot to like about Nix, including that packages are content-named, and that dependencies are tracked. There’s some crazy parts, like the fact that runtime dependencies are determined by scanning binaries for the content-names of Nix packages, but since a long content name is pretty much a unique thing, it sounds scary but is actually quite safe.

It also makes building very safe, if you have everything as packages.

One negative is that this only supports Unix-like systems (Linux, Mac OS X, FreeBSD). A lesser negative is that it introduces yet another language, the Nix expression language.

The NixOS Linux distribution is built around Nix, and Hydra is a Nix-based continuous build system.

Writing

Wolfram Problem Generator

Leave a comment

I’m not a Wolfram|Alpha Pro subscriber, but I might become one to play with this

Wolfram Problem Generator

This is a tutor disguised as a problem generator. It’s just for math, and simple branches of math, at the moment. There are 6 groups listed: Arithmetic, Number Theory, Algebra, Calculus, Linear Algebra and Statistics, and it’s all pretty basic portions of those groups.

The point of this? You get custom-generated problems, and it gives you applicable hints if you get stuck at any step (the tutor part).

What the world needs, of course, is something like this for programming.