There are several available libraries for communicating with the Wii nunchuk. I somehow found something lacking in all of them, so I wrote wiinunchuk.h for my projects. It is inspired by Tod E. Kurt. but my wiinunchuk.h boasts more powerful features and a more flexible API.

This library is free software and is licensed under the GPL v3.

Click here to Download wiinunchuk.h.

The code is relatively well commented on its own. The header provides the functions

• void nunchuk_setpowerpins()
• void nunchuk_init()
• int nunchuk_get_data()
• void nunchuk_calibrate_joy()
• inline unsigned int nunchuk_zbutton()
• inline unsigned int nunchuk_cbutton()
• inline int nunchuk_joy_x()
• inline int nunchuk_cjoy_x()
• inline int nunchuk_cjoy_y()
• inline uint16_t nunchuk_accelx()
• inline uint16_t nunchuk_accely()
• inline uint16_t nunchuk_accelz()
• inline int nunchuk_caccelx()
• inline int nunchuk_caccely()
• inline int nunchuk_caccelz()
• inline int nunchuk_joyangle()
• inline int nunchuk_rollangle()
• inline int nunchuk_pitchangle()
• void nunchuk_calibrate_accelxy()
• void nunchuk_calibrate_accelz().

Calibration

Although the header provides functions to pull raw data right from the nunchuck, in most typical applications it is useful to have the data from the nunchuck normalised so that certain reference points are defined to be zero. For example, the reading from the joystick potentiometer will range from about 24 to about 230 on both x and y axes. The normal reading when the joystick is centred is about 130 (it will be slightly different in for each axis). If you subtract the centre value from the instantaneous joystick readings, then it is zeroed at the centre and readings will be relative to the centre.

Reasonable default centre values are #defined near the top of the document:

#define DEFAULT_CENTRE_JOY_X 124
#define DEFAULT_CENTRE_JOY_Y 132
#define ACCEL_ZEROX 490
#define ACCEL_ZEROY 500
#define ACCEL_ZEROZ 525

These are loaded into program memory in void nunchuk_init(). If you need accuracy and plan to use the same nunchuk in all applications, it is worth your time to measure these for your nunchuk by spitting the rad nunchuk data to a serial terminal. For other cases, wiinunchuk.h provides functions

• void nunchuk_calibrate_joy()
• void nunchuk_calibrate_accelxy()
• void nunchuk_calibrate_accelz().

The function nunchuk_calibrate_joy() will take the instantaneous reading of the joystick values and record them as the zero value. The end user should be warned not to manipulate the joystick during the moment it is called. Usually, this is at the beginning of the sketch before the action starts.

void nunchuk_calibrate_joy()
	{
	joy_zerox = joy_x;
	joy_zeroy = joy_y;
	}

nunchuk_calibrate_accelxy() and nunchuk_calibrate_accelz() will record zero values for the accelerometer axes. This has to be done in two steps since the force of gravity will always affect at least one of the accelerometer axes. If the nunchuk is held upright, the xy calibration will be clean since gravity is pulling towards negative z. Then, with the nunchuk on its side or face so that gravity affects only x or y, the z accelerometer can be read to take the zero value using nunchuk_calibrate_accelz().

void nunchuk_calibrate_accelxy()
	{
	accel_zerox = nunchuk_accelx();
	accel_zeroy = nunchuk_accely();
	}

void nunchuk_calibrate_accelz()
	{
	accel_zeroz = nunchuk_accelz();
	}

Initialisation

nunchuk_setpowerpins() sets up the pins.

void nunchuk_setpowerpins()
	{
	#define pwrpin PORTC3
	#define gndpin PORTC2
	DDRC |= _BV(pwrpin) | _BV(gndpin);
	PORTC &= ~_BV(gndpin);
	PORTC |=  _BV(pwrpin);
	delay(100); // wait for things to stabilize
	}

The function assumes that the nuncuk is connected using a WiiChuk, or at least that you are using the same pin configuration. That is to say A2, A3, A4 and A5 are power (-), power (+), data and clock, respectively. Even though these are analog pins, this function treats A2 and A3 as digital pins and sets them high and ground to power the nunchuk with 5V. As I write that, I recall that the nunchuk spec calls for less than 5V, but WiiChuk users don’t have much choice. If you cut the connector on your nunchuck and are plugging in directly, I would try using the Arduino’s 3.3V power instead.

The nunchuk_init() function sets up communication with the nunchuk by establishing the i2c bus and handshaking. The way this is done should work for OEM Nintendo nunchuks and for the el-cheapo knock-offs.

void nunchuk_init()
	{
	Wire.begin();
	delay(1);
	Wire.beginTransmission(0x52);  // device address
	#if (ARDUINO >= 100)
		Wire.write((uint8_t)0xF0);  // 1st initialisation register
		Wire.write((uint8_t)0x55);  // 1st initialisation value
		Wire.endTransmission();
		delay(1);
		Wire.beginTransmission(0x52);
		Wire.write((uint8_t)0xFB);  // 2nd initialisation register
		Wire.write((uint8_t)0x00);  // 2nd initialisation value
	#else
		Wire.send((uint8_t)0xF0);   // 1st initialisation register
		Wire.send((uint8_t)0x55);   // 1st initialisation value
		Wire.endTransmission();
		delay(1);
		Wire.beginTransmission(0x52);
		Wire.send((uint8_t)0xFB);   // 2nd initialisation register
		Wire.send((uint8_t)0x00);   // 2nd initialisation value
	#endif
	Wire.endTransmission();
	delay(1);
	//
	// Set default calibration centres:
	//
	joy_zerox = DEFAULT_CENTRE_JOY_X;
	joy_zeroy = DEFAULT_CENTRE_JOY_Y;
	accel_zerox = ACCEL_ZEROX;
	accel_zeroy = ACCEL_ZEROY;
	accel_zeroz = ACCEL_ZEROZ;
	}

Some other libraries do a more canonical sort of initialization that causes the data to be encrypted and is not compatible with 3rd party nunchucks. The function finishes off by loading the default zero values for the sensors into memory. They can hereon be changed directly or using the calibration functions discussed earlier.

Communication

We expect to get back six bytes of information:

The function nunchuk_get_data() requests and receives the six bytes data, reads it into a six element array nunchuk_buf.

int nunchuk_get_data()
	{
	int cnt=0;
	  // Request six bytes from the chuck.
	Wire.requestFrom (0x52, 6);
	while (Wire.available ())
		{
	  // receive byte as an integer
		#if (ARDUINO >= 100)
			nunchuk_buf[cnt] = Wire.read();
		#else
			nunchuk_buf[cnt] = Wire.receive();
		#endif
		cnt++;
		}
	//
	//Send read address, zero-byte.
	#if (ARDUINO >= 100)
		Wire.write((uint8_t)0x00);
	#else
		Wire.send((uint8_t)0x00);
	#endif

	if (cnt >= 5)
		{
		return 1;   // success
		}
	return 0; // failure
	}

Processing and output

The remaining functions deal with unpacking our six-byte data package, nunchuk_buf[] and presenting it in various useful forms. Since these functions are small and likely to be in a program loop, I cast them all as static inline functions to avoid emission of object code and have the code injected directly into the points of use in the Arduino sketches.

To start, we capture the C and Z buttons with nunchuk_cbutton() and nunchuk_zbutton(). The one-bit on/off values are stored in the last two bits of the sixth byte. We just bit shift an appropriate value and check the state of the last bit of that byte. The checking of the byte value is done using C’s inline ternary conditional operator (condition)? true : false;.

static inline unsigned int nunchuk_zbutton()
	{
	return ((nunchuk_buf[5] >> 0) & 1) ? 0 : 1;
	}

static inline unsigned int nunchuk_cbutton()
	{
	return ((nunchuk_buf[5] >> 1) & 1) ? 0 : 1;
	}

There isn’t much to be done about the raw x and y values, so we just return them with nunchuk_joy_x() and nunchuk_joy_x().

static inline int nunchuk_joy_x()
	{
	return (int) nunchuk_buf[0];
	}

static inline int nunchuk_joy_y()
	{
	return (int) nunchuk_buf[1];
	}

We also want the option of having the calibrated (zeroed and centre) joystick values which are returned with functions nunchuk_cjoy_x() and nunchuk_cjoy_x()

static inline int nunchuk_cjoy_x()
	{
	return (int)nunchuk_buf[0] - joy_zerox;
	}

static inline int nunchuk_cjoy_y()
	{
	return (int)nunchuk_buf[1] - joy_zeroy;
	}

The accelerometer readings are a more difficult matter because of the 10-bit values, the least significant two bits are stored in byte six, which is a mish-mash of data. So, take for example the function nunchuk_accelx().

static inline uint16_t nunchuk_accelx()
	{
	return (  0x0000 | ( nunchuk_buf[2] << 2 ) +
		( ( nunchuk_buf[5] & B00001100 ) >> 2 )  );
	}

First, 0x0000 | ( nunchuk_buf[2] << 2 ) takes a blank 16-bits (0x0000) and does a bitwise OR (|) with the 8-bit nunchuk_buf[2] which has been bit-shifted by 2 (<<2). The bitwise OR simply takes nunchuk_buff[2] and imprints it onto 0x0000 creating a 16-bit version of nunchuk_buf[2]. The bit-shift ensures that the last two bits are blank so we can add in the last two bits which are stored in nunchuk_buf[5]. So, to this we add ( nunchuk_buf[5] & B00001100 ) >> 2 ) which takes the pair of bits starting second from the left of nunchuk_buf[5] and zeros everything else. Then those two bits are shifted to the end to be added to the 16-bit copy of nunchuk_buf[2] which has the right-most two bits empty and waiting.

Rinse and repeat for the y and z accelerometer values.

static inline uint16_t nunchuk_accely()
	{
	return (  0x0000 ^ ( nunchuk_buf[3] << 2 ) +
		( ( nunchuk_buf[5] & B00110000 ) >> 4 )  );
	}

static inline uint16_t nunchuk_accelz()
	{
	return (  0x0000 ^ ( nunchuk_buf[4] << 2 ) +
		( ( nunchuk_buf[5] & B11000000 ) >> 6 )  );
	}

The sketch may optionally want the calibrated accelerometer values which are offered by the following three functions.

static inline int nunchuk_caccelx()
	{
		return (int)(nunchuk_accelx() - accel_zerox);
	}

static inline int nunchuk_caccely()
	{
		return (int)(nunchuk_accely() - accel_zeroy);
	}

static inline int nunchuk_caccelz()
	{
		return (int)(nunchuk_accelz() - accel_zeroz);
	}

The final three functions are concerned with angle. I include them because some people have a rather serious trigonometry allergy. The vector magnitudes which compliment these angles, I’ll leave to the Pythagorean wizardry of whom ever may need them.

You’ll note the use of the atan2() function. This is exactly like vanilla atan(), except that it keeps track of which quadrant we are in by the signs of the opposite and adjacent lengths, and also handles vectors one the axes gracefully.

static inline int nunchuk_joyangle()
	{
	double theta;
	theta = atan2( nunchuk_cjoy_y(), nunchuk_cjoy_x() );
	while (theta < 0) theta += 2*M_PI;
	return (int)(theta * 180/M_PI);
	}

The little while-loop in here makes sure that we get a positive angle by rotating angles into their positive equivalent.

A little trick to get the orientation of the nunchuk from the accelerometers is to sniff out the gravity vector. If the accelerometer is properly zeroed, and all other external forces are negligible (i.e., gravity is the only significant fore on the numchuk), then the ratios of the accelerometer readings will give the roll and pitch of the nunchuk.

Roll (nunchuk_rollangle()) is the angle created by tipping an upright nunchuk to the left or right as viewed from behind. More precisely, with the z-axis pointing up from the joystick, the y-axis point out of the c-button and the x-axis pointing from the right side, roll is the angle created between the z-axis and the nunchuk when it is rotated about the y-axis.

static inline int nunchuk_rollangle()
	{
	return (int) (  atan2( (double) nunchuk_caccelx(),
		(double) nunchuk_caccelz() ) * 180 / M_PI  );
	}

Then by the same definitions, pitch is the angle created between the nunchuk and the z-axis when the nunchuk is rotated about the x-axis and ‘tipped’ forward or backward.

static inline int nunchuk_pitchangle()
	{
	return (int) (  atan2( (double) nunchuk_caccely(),
		(double)nunchuk_caccelz() ) * 180 / M_PI  );
	}

If you haven’t already, click here to Download wiinunchuk.h.

I hope you find this useful. Please feel free to post links to your projects or ask questions. Enjoy!

Do something about it: www.stopspying.ca or www.openmedia.ca

About two months ago I bought a Solomon SL-30 from a1parts.com, the online store for A1 Electronics here in Toronto. I chose that station after a lot of research, despite not being familiar with the name. This review is not based on a series of cleverly designed test, but just my day-to-day use of the station for soldering connectors, wires and even a little PCB work.

I had been shopping around for a while when I decided to try the Solomon SL-30. I knew I wanted temperature control, a comfortable pen, easily to find tips and a good build quality. I had considered the Weller WESD51D, the Hakko FX-888 and the Edsyn 951SX SX-500D.

Summary

I’m really very happy with the station overall. I feel like I got good value for my money, and I got just about everything I wanted in a soldering station.

Pros

• Temperature setting and readout, very nice, especially for the price.
• Solid quality — a heavy unit with solid feeling construction. The temperature knob feels smooth and strong. I feel like this may be something that will be in my workshop for a lot of years.
• Tip and iron replacement seem readily available, even if the iron is swapped to Elenco brand. However, apparently Solomon has been around for a lot of years and is one of the biggest manufacturers in the world (according to Glen from A1).
• Really nice holder for the iron. I’m not a big fan of the wire coil ones, and because space is an issue for me, I also don’t want one of the huge ones that hold the iron and sponge (or brass) separate from the unit.
• Silicone coated wire on the iron, not that I can imagine ever burning my iron with itself.

Cons

I can really only think of one con:

• I really wanted a thin pencil-like iron with a super flexible (spaghetti-like) cord, but this one feels like most any cheap plug-in iron. In fact, it feels just fine in my hand, I just like the look of the smaller ones. The cord is a little stiff at first too. The silicone grip does occasionally slide down on my pen, but I just push it back up. I’m nitpicking really.

Deciding on the Solomon

The price of most other offerings, relative to the feature set really made the decision for me. Less than $100.00 got me a temperature controlled soldering station with a digital readout of both current temperature and set temperature.

I read a lot of reviews saying that the Weller had a cheap knob that broke, and basically that people who had owned Wellers from 40+ years back aren’t happy with the quality of the modern Weller products. Solomon seems to come out with new products, but the quality (from what I hear) is consistent. I was really tempted to get a Hakko, and I probably will some day, but there was just nothing for this price that could compete with the SL-30.

A serious consideration was the Elenco line of soldering stations, some of which seem identical to the Solomon offerings. The price of Elenco stations is a little less online, but shipping costs make it preferable for me to just buy it locally from A1 Electronics.

Impressions out of the box

A scanned image of the instruction booklet that came in the box with the SL-30. The reverse side seems to contain the same instructions in several languages.

Aside form the fact that the box looks like marketing material for a discount Chinese dish detergent, my first impressions were very good. Out of the box, the weight and build quality felt good, and everything was straight forward to set up.

Afterthoughts

It really just does what you expect. There’s not much more to say. The tips are very nice for the price, but the handle feels somewhat cheap. I’m going to be very picky on this point, however, because I really did want a station with a thin pencil-like handle and a very flexible cord. The Solomon is a little disappointing in that light, but there is really nothing to complain out. It is comfortable to use, even for hours at a time.

If anything ever happened and I had trouble getting Solomon parts, I believe that I can buy an Elenco replacement iron and tips (~$20.00 total) and it should be a drop-in replacement for the Solomon iron.

Overall…

I’m very happy with the unit, and I feel like I’m going to use it for a long time. I’m eventually going to replace it with a very expensive one, but that will be years down the road. And based on the build quality, I definitely feel that years down the road when I do replace it, I will be replacing a fully functioning Solomon.

The two options are to modify the source file tfreq.c to read the new input, which could be difficult for someone inexperienced with C. As a quick solution, I wrote a quick awk script to make a .vel file from a CPMD TRAJECTORY file.

The following script should would with cubic geometry (just a guess). It doesn’t read anything from the GEOMETRY file and I leave it to the user to make any necessary conversions. I need someone to test it, and I’ll post the results here.

BEGIN {
	nat=###     # Number of Atoms.
	dt=###       # Duration (in fs) of teach time step.
	}

{
	# For each atom:
	for (i=0; i<=nat; i++) {
		# Read the time step out of the first column:
		ts=$1
		# If this is the first row of a time step, print the time:
		if (i==0) printf " %10d %16.10f\n", ts, ts*dt
		# Now print the volocity out of the TRAJECTORY file:
		printf "%16.12f  %16.12f  %16.12f\n", $5, $6, $7
		# Get a new line:
		getline
	}
}

Save this code as CPMD2vel.awk and define nat (the number of atoms) and dt (the time step size)

Run this with code: awk -f CPMD2vel.awk TRAJECTORY > output.vel

This will create a .vel file (output.vel, or the name you wish), which can be used with tfreq.

ESPRESSO’s .vel file format is very simple:

timestep time(in fs)
vx1 vy1 vz1
vx2 vy2 vz2
vx3 vy3 vz3
...

With the format:

integer float
float float float
float float float
...
integer float
float float float
float float float

For example:

1 0.123456
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
2 0.123456
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
3 0.123456
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
1.2345E01 1.2345E01 1.2345E01
...


Candidates supporting open-Internet by party. Taken from openmedia.ca

In this day in age, I can’t believe that there is a politician stupid enough to support metered Internet billing.

In case you don’t already know, the big Internet Service Providers (ISPs) in Canada want to start billing Internet usage by the byte. Anyone with a smart phone is familiar with this system. For anyone who lives on the Internet, as most twenty-somethings and younger tend to do these days, this could easily become prohibitively expensive.

The good folks over at openmedia.ca have been fighting the good fight. I’ve been helping them as much as I can by signing petitions, sending emails to politicians, etc. I’d encourage the reader to do the same. I’m actually really surprised by how big of an impact openmedia.ca has had.

The telecommunications industry in this country is already behind much of the world in terms of the quality of service. I have many friends in Europe who absolutely pity our situation. (Although I’m quick to remind many of them about three-strikes.) Metered billing would be another major step backward from Canada’s already embarrassing position.

I simply can’t begin to comprehend the stupidity. It’s bad for private citizens, especially in the lower and middle class brackets, and it’s also bad for business.

We not only share our lives over the Internet, but also our talents and passions. Show me an independent band that doesn’t have some mp3s (or FLAC, better yet). Emerging authors are self publishing on the Internet. Visual artists (painters, photographers, etc) are selling their prints on the Internet. Limiting ones access to this content not only hurts the artists, but all of us whose lives are improved by it.

As for business, let’s rime off a few: Google, Netflix, iTunes, Amazon, YouTube, Ebay, Facebook, Steam, Indigo, iStockPhoto and maybe several thousand others I’m missing. Not only do companies like these make money by selling physical goods online, but also digital products such as mp3s, movies, digital images and software. All things that will be taxed by the cost of downloading the files. And let’s not forget that we like to look at plenty of high resolution images of products before we buy them.

Well, I guess none of the companies mentioned in the last paragraph are doing enough to fund the Conservatives, because they seem dead set on screwing us all over. I’d love to know how much money they’re selling us out for.

I’m so disappointed with my choices for this election. I’m actually thinking of voting Green party, just to shake things up. I can’t believe how badly our system is broken.

I’ve avoided doing a manual install of TeX Live 2010 because I’ve imagined as being such a pain in the ass. But to my surprise, it was pretty simple. The hardest part was tricking Ubuntu’s package manager into knowing that TeX Live is installed without pulling the crappy copy off of the repos.

To start, just download the small gzip from here. Unpack it and change directory into it in a terminal.
sudo apt-get install perl-tk
which you’ll need for the installer GUI. Now, run the installer:
sudo ./install-tl --gui

Once your in the installer, go through the list of options. If you don’t know what they do, you probably don’t need to bother with it. The main one to look out for are A4 vs. Letter paper. I didn’t generate the simlinks, but you’ll have to edit your PATH variable later. Hit the install button and go make yourself a sandwich. You’ll be a while.

At the end of the install, you’ll get the following message

Add /usr/local/texlive/2010/texmf/doc/man to MANPATH.
Add /usr/local/texlive/2010/texmf/doc/info to INFOPATH.
Most importantly, add /usr/local/texlive/2010/bin/x86-linux
to your PATH for current and future sessions.

Note, you’ll get a message which reflects your architecture. (x86_64, for example.)

So, to add those directories to the paths, you’ll want to edit your bashrc:
gedit ~/.bashrc
In my case, I added the following lines:

export PATH=$PATH:/usr/local/texlive/2010/bin/i386-linux
export MANPATH=$MANPATH:/usr/local/texlive/2010/texmf/doc/man
export INFOPATH=$INFOPATH:/usr/local/texlive/2010/texmf/doc/info

Now, install a few more packages:
sudo apt-get install tex-common texinfo lmodern perl-tk
Be sure to restart the terminal (or source ~/.bashrc) before you try using anything.

Now, if you try to bring anything from the repositories that depends on TeX Live, apt is going to pull over Ubuntu’s crappy copy. To avoid this, I created a meta package which checks off all of the TeX Live packages but doesn’t install anything.

I got the following from schlasim’s ubuntu blog. First, paste and execute the following lines one at a time:

sudo apt-get install equivs
mkdir /tmp/tl-equivs && cd /tmp/tl-equivs
equivs-control texlive-local

Now, edit the file texlive-local (gedit texlive-local), which was just created by the equivs-control program. Paste in the following lines:

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: texlive-local
Version: 2010-1~1
Maintainer: you
Provides: biblatex, biblatex-dw, cm-super, cm-super-minimal, context, dvipng,
 feynmf, fragmaster, lacheck, latex-beamer, latex-cjk-all, latex-cjk-chinese,
 latex-cjk-chinese-arphic-bkai00mp, latex-cjk-chinese-arphic-bsmi00lp,
 latex-cjk-chinese-arphic-gbsn00lp, latex-cjk-chinese-arphic-gkai00mp,
 latex-cjk-common, latex-cjk-japanese, latex-cjk-japanese-wadalab,
 latex-cjk-korean, latex-cjk-thai, latex-cjk-xcjk, latexmk, latex-sanskrit,
 latex-xcolor, lcdf-typetools, lmodern, luatex, musixlyr, musixtex, pgf,
 preview-latex-style, prosper, ps2eps, psutils, purifyeps, t1utils, tex4ht,
 tex4ht-common, tex-gyre, texlive, texlive-base, texlive-base-bin,
 texlive-base-bin-doc, texlive-bibtex-extra, texlive-binaries, texlive-common,
 texlive-doc-base, texlive-doc-bg, texlive-doc-cs+sk, texlive-doc-de,
 texlive-doc-el, texlive-doc-en, texlive-doc-es, texlive-doc-fi,
 texlive-doc-fr, texlive-doc-it, texlive-doc-ja, texlive-doc-ko,
 texlive-doc-mn, texlive-doc-nl, texlive-doc-pl, texlive-doc-pt,
 texlive-doc-ru, texlive-doc-si, texlive-doc-th, texlive-doc-tr,
 texlive-doc-uk, texlive-doc-vi, texlive-doc-zh, texlive-extra-utils,
 texlive-fonts-extra, texlive-fonts-extra-doc, texlive-fonts-recommended,
 texlive-fonts-recommended-doc, texlive-font-utils, texlive-formats-extra,
 texlive-games, texlive-generic-extra, texlive-generic-recommended,
 texlive-humanities, texlive-humanities-doc, texlive-lang-african,
 texlive-lang-all, texlive-lang-arab, texlive-lang-arabic,
 texlive-lang-armenian, texlive-lang-croatian, texlive-lang-cyrillic,
 texlive-lang-czechslovak, texlive-lang-danish, texlive-lang-dutch,
 texlive-lang-finnish, texlive-lang-french, texlive-lang-german,
 texlive-lang-greek, texlive-lang-hebrew, texlive-lang-hungarian,
 texlive-lang-indic, texlive-lang-italian, texlive-lang-latin,
 texlive-lang-latvian, texlive-lang-lithuanian, texlive-lang-manju,
 texlive-lang-mongolian, texlive-lang-norwegian, texlive-lang-other,
 texlive-lang-polish, texlive-lang-portuguese, texlive-lang-spanish,
 texlive-lang-swedish, texlive-lang-tibetan, texlive-lang-ukenglish,
 texlive-lang-vietnamese, texlive-latex3, texlive-latex-base,
 texlive-latex-base-doc, texlive-latex-extra, texlive-latex-extra-doc,
 texlive-latex-recommended, texlive-latex-recommended-doc, texlive-luatex,
 texlive-math-extra, texlive-metapost, texlive-metapost-doc, texlive-music,
 texlive-omega, texlive-pictures, texlive-pictures-doc, texlive-plain-extra,
 texlive-pstricks, texlive-pstricks-doc, texlive-publishers,
 texlive-publishers-doc, texlive-science, texlive-science-doc, texlive-xetex,
 texpower, texpower-manual, thailatex, tipa, ttf-freefont, ttf-gfs-artemisia,
 ttf-gfs-baskerville, ttf-gfs-bodoni-classic, ttf-gfs-didot,
 ttf-gfs-didot-classic, ttf-gfs-gazis, ttf-gfs-neohellenic, ttf-gfs-olga,
 ttf-gfs-porson, ttf-gfs-solomos, ttf-gfs-theokritos, ttf-sil-gentium, xindy,
 xindy-rules
Architecture: all
Description: My local installation of TeX Live 2010.
 A full "vanilla" TeX Live 2010

http://tug.org/texlive/debian#vanilla

Now, finish off by executing the last two lines:

equivs-build texlive-local
sudo dpkg -i texlive-local_2010-1~1_all.deb

You should now be able to maintain your own TeX Live installation. You can update or install packages as you see fit, and you don’t have to deal with out of date packages causing you frustration.

I usually go to sleep listening to gnaural or watching old TV shows on the computer beside my bed (which my wife just loves). Rather than have it running all night, I’d rather have my computer sleep after a certain time.

For some reason, the last time I tried to write a script to suspend my computer (a few years ago), it was a serious pain in the ass. Now, thanks to pm-utils, it’s pretty easy. The command pm-suspend must be run as root, but aside from that it pretty much does what it says on the tin.

To use the script, copy and paste it into a text file (preferably called sleeptimer). Then, change the permissions on the file to make it executable. From the command line, you can do this with chmod u+x sleeptimer. From the command line, ./sleeptimer N – will sleep the computer in N minutes, where N is some positive integer. The script will go through a count down for each fifteen minutes and gives a warning at 10, 5 and then 1 minute before it sleeps.

Please forgive the crudity. I didn’t really write it for general public usage, but I’m posting it in response to a request.

#!/bin/bash
#
# sleeptimer.sh
#
# Author: Timothy A.V. Teatro <tim@timteatro.net>
# Date  : Jan 11, 2011
#
# Description: A rather unsophisticated little script that I wrote for
#    myself. Since I usually fall asleep listening to gnaural or watching
#    a movie on my computer beside my bed, I wanted something to suspend
#    my computer rather than using shutdown.
#
# Usage : sudo ./sleeptimer <integer>
#    where <integer> is the number of minutes before the computer is suspended
#
#    This script is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#####################################################

#
# Must be run as root, so check id at the door.
#
if [ "$(id -u)" != "0" ]; then
	echo Must be run as root.
	exit 1
fi

min=$1 # Keep the first argument on the command line here
elapsed=0 

#
# Check to be sure argument is a number...
#
if [ $min -eq $min 2> /dev/null ]; then
	#
	# ... and if it is, then decide what to do with it
	#
	# If it's less than 15 minutes, we want to count down to 10, 5 and
	# then 1 minute for feedback to the user.
	#
	if [ $min -lt 15 ]; then
		echo Sleeping in $min minutes [`date`]
		while [ $elapsed -le $min ]; do
			sleep 1m
			elapsed=$((elapsed+1))
			if [ $((min-elapsed)) -eq 10 ]; then
				echo Sleeping in 10 min.
			elif [ $((min-elapsed)) -eq 5 ]; then
				echo Sleeping in 5 min.
			elif [ $((min-elapsed)) -eq 1 ]; then
				echo Sleeping in less than 1 min.
			fi
		done
	else # If it's more, we'll count down in 15 minute intervals.
		#
		# Get the remainder of $min/15 and sleep that down.
		#
		remainder=`expr $min % 15`
		sleep ${remainder}m
		elapsed=$((elapsed+remainder))
		#
		# Now that the time remaining is a factor of 15, we'll sleep
		# in 15 minute incriments until the last 15 minutes of the
		# timer.
		#
		while [ $elapsed -lt $((min-15)) ]; do
			sleep 15m
			elapsed=$((elapsed+15))
			echo Sleeping in $((min-elapsed)) minutes. [`date`]
		done
		sleep 5m
		echo Sleeping in 10 minutes
		sleep 5m
		echo Sleeping in 5 minutes
		sleep 4m
		echo Sleeping in less than a minute.
		sleep 1m
	fi
	#
	# We've done our counting, now suspend.
	#
	echo "!!! NOW SUSPENDING YOUR MACHINE !!!"
	pm-suspend
	exit 0
else
	echo $min is not an integer. Please specify the number of minutes before sleep.
	exit 2
fi

As usual, I strongly encourage my students to use Maple Classic. The java interface of normal Maple may be flashy an appealing to the ignorant or those unfortunate enough to get used to it, but most real world work in Maple is done with Maple classic.

For a function , the quadratic approximation about a point is given by

In Maple, this can be implemented as:

> restart;
> f:=ln(x)/sqrt(x); # Define a function
> a:=1; # The point about which we'll expand
> Q:=subs(x=a, f) + subs(x=a, diff(f, x))*(x-a) + subs(x=a, diff(f, x, x))*(x-a)^2/2;
> plot([f, Q], x=-5..5, y=-5..5);


Now try playing around with the above code. Change the values of a and f(x).

What'ca gonna do when they come for you?

The sliding scale between performance and coding simplicity has led to a spectrum of languages over the years. In the world of scientific computing, the two major languages are of course C and FORTRAN. Both of these are compiled, low level and high performance languages. Generally, one rarely considers an executed language for scientific grunt-work since interpreted languages tend to be drastically slower. In recent years, computers have become fast enough for a compromise, but still, most interpreted languages fall short of the task.

Python is different. On its own, it’s still too slow for general scientific application. However, its ability to easily interface with bits of binary code make it attractively extensible for scientific and numerical applications.

Numpy, a package of scientific computing tools for Python, extends Python’s data structures with a multidimensional array object, various derived objects and an assortment of routines for fast operations on arrays. As long as your problem can be cast into numpy’s array objects, operations can be carried out with speeds to rival a pure C implementation.

SciPy and matplotlib further extend numpy + Python to give functionality similar to Matlab making Python an excellent free and open-source alternative. Python has the added advantage of being a popular and complete programming language.

The aim of this article is to demonstrate how numpy can be used to dramatically increase the efficiency of the simple task of integrating the two dimensional diffusion equation. There will also be an example of advanced visualization with matplotlib, creating an animated image map to visualize the solution. The code in this article is nowhere near as elegant as it could be, but it is intentionally plain for the beginners eye.

The two-dimensional diffusion equation

We consider the partial differential equation

or more compactly, on the domain of the unit square (x,y between zero and one). This is the diffusion equation which models diffusive processes such as heat and chemical concentration.

We approximate by the discrete function , where , and . Applying finite (forward) difference approximations to the derivatives, then we obtain the partial difference equation

or

(1)  

A word on stability

The stability of the scheme requires that the following condition is met:

If we set the time interval at the highest value allowed by the condition, we will still see some noise in the solution. Reducing the time-step size can improve this.

Initial conditions, boundary values and characteristics of the solution

Equation (1) is a blueprint for integrating the solution forward in time, calculating the solution at each time-step based on the solution at the previous time-step. Since a previous time-step is required for each subsequent step, the initial conditions (i.e., ) must be given. Additionally, the derivatives in the Laplacian require boundary conditions.

For the example in this article, we will choose the initial conditions to be a ring centred at (0.5, 0.5), defined by

We will also choose the boundary conditions to be zero, in agreement with the initial conditions.

The solution given these conditions is illustrated in Fig. 1

Fig. 1: An illustration of the time evolution of diffusion (A) when t=0 (showing the initial conditions), (B) when m=5, (C) when m=200 and (D) when m=500.

Coding the problem in Python

Plain Python

I’d hope the reader is somewhat familiar with Python; but if not, it should be easy enough to follow along. Feel free to post questions, although I’d imagine that Google is good enough to answer most.

To integrate Eq. (1) through time, we set up a loop,

for m in range(1, timesteps+1):
	print "Computing u for m =", m
	evolve_ts(u, ui)

where m is our time index and timesteps holds the number of time-steps to calculate (say, 500). We have to define some function evolve_ts(u, ui), which will calculate u from ui.

Using plain Python syntax, the function evolve_ts should look something like this:

def evolve_ts(u, ui):
	global nx, ny
	"""
	This function uses two plain Python loops to
	evaluate the derivatives in the Laplacian, and
	calculates u[i,j] based on ui[i,j].
	"""
	for i in range(1,nx-1):
		for j in range(1,ny-1):
			uxx = ( ui[i+1,j] - 2*ui[i,j] + ui[i-1, j] )/dx2
			uyy = ( ui[i,j+1] - 2*ui[i,j] + ui[i, j-1] )/dy2
			u[i,j] = ui[i,j]+dt*a*(uxx+uyy)

where nx and ny contain the number of elements of u in the x- and y-direction (i.e., nx=1/dx where dx=). Although Python indexes from 0, we want the loops to start at index 1 and end at index nx-1 or ny-1 (as the case may be). This is because we wish to leave the boundary values at zero, as defined by our boundary conditions.

Here is a listing of a fully functional Python script which implements the above code. Copy and paste it into a document and execute it (you may have to chmod u+x to execute it under Linux/UNIX)

#!/usr/bin/env python
"""
A program which uses an explicit finite difference
scheme to solve the diffusion equation with fixed
boundary values and a given initial value for the
density.

Two steps of the solution are stored: the current
solution, u, and the previous step, ui. At each time-
step, u is calculated from ui. u is moved to ui at the
end of each time-step to move forward in time.

"""
import scipy as sp
import time

# Declare some variables:

dx=0.01        # Interval size in x-direction.
dy=0.01        # Interval size in y-direction.
a=0.5          # Diffusion constant.
timesteps=500  # Number of time-steps to evolve system.

nx = int(1/dx)
ny = int(1/dy)

dx2=dx**2 # To save CPU cycles, we'll compute Delta x^2
dy2=dy**2 # and Delta y^2 only once and store them.

# For stability, this is the largest interval possible
# for the size of the time-step:
dt = dx2*dy2/( 2*a*(dx2+dy2) )

# Start u and ui off as zero matrices:
ui = sp.zeros([nx,ny])
u = sp.zeros([nx,ny])

# Now, set the initial conditions (ui).
for i in range(nx):
	for j in range(ny):
		if ( ( (i*dx-0.5)**2+(j*dy-0.5)**2 <= 0.1)
			& ((i*dx-0.5)**2+(j*dy-0.5)**2>=.05) ):
				ui[i,j] = 1

def evolve_ts(u, ui):
	global nx, ny
	"""
	This function uses two plain Python loops to
	evaluate the derivatives in the Laplacian, and
	calculates u[i,j] based on ui[i,j].
	"""
	for i in range(1,nx-1):
		for j in range(1,ny-1):
			uxx = ( ui[i+1,j] - 2*ui[i,j] + ui[i-1, j] )/dx2
			uyy = ( ui[i,j+1] - 2*ui[i,j] + ui[i, j-1] )/dy2
			u[i,j] = ui[i,j]+dt*a*(uxx+uyy)

# Now, start the time evolution calculation...
tstart = time.time()
for m in range(1, timesteps+1):
	evolve_ts(u, ui)
	print "Computing u for m =", m
tfinish = time.time()

print "Done."
print "Total time: ", tfinish-tstart, "s"
print "Average time per time-step using numpy: ", ( tfinish - tstart )/timesteps, "s."

Executing the above code on my office workstation for 500 time-steps with dx=dy=0.01 takes about 88 seconds, averaging 0.1758s per time-step. Considering a compiled C-code implementation would execute all 500 time-steps in less than two-tenths of a second, the Python performance is pretty dismal.

Enhanced by numpy

Luckily, we can make a small change to the above code to boost the perfomance close to that of pure C.

Assuming you’ve run the above Python code, replace the definition of evolve_ts with the following:

def evolve_ts(u, ui):
	"""
	This function uses a numpy expression to
	evaluate the derivatives in the Laplacian, and
	calculates u[i,j] based on ui[i,j].
	"""
	u[1:-1, 1:-1] = ui[1:-1, 1:-1] + a*dt*( (ui[2:, 1:-1] - 2*ui[1:-1, 1:-1] + ui[:-2, 1:-1])/dx2 + (ui[1:-1, 2:] - 2*ui[1:-1, 1:-1] + ui[1:-1, :-2])/dy2 )

In this version of evolve_ts, the loops for x and y have been replaced by a numpy expression. The benefits here are two-fold: (1) the syntax is leaner, replacing five lines of code with only one (albeit a larger one) and (2) numpy executes the expression using C. Hence, the performance of the code is drastically increased. On my computer, the numpy expression takes less than a quarter-second to execute (compare plain Python at 88s) with an average of 4.70094E-4s per time-step: nearly 400-times faster than the plain Python code.

The trick with the numpy expressions is the way numpy iterates through the slices. To understand exactly what the above statement does, you can use the official (tentative) numpy tutorial, starting with the section on slicing.

Using matplotlib to visualize

Fig 2. An example of the output from the matplotlib visualization, with white edges trimmed off for web presentation.

Matplotlib can be very simple and easy to use. In this particular case, I wanted to do something quite advanced: create an animated, real-time density map (Fig. 2) of the solution as it is calculated.

The following code uses the numpy enhanced update_ts function, and pops up a windows which renders the solution in real time, as it’s calculated. The performance is low, due to the rendering. Some details of the code are briefly explained in the comments; but I’ll generally leave it to the user to figure out what things do. I didn’t intend this example to be instructive but merely a showpiece for what can be done with relatively little code.

#!/usr/bin/env python
"""
Author: Timothy A.V. Teatro <http://www.timteatro.net>
Date  : Oct 25, 2010
Lisence: Creative Commons BY-SA
(http://creativecommons.org/licenses/by-sa/2.0/)

Description:
	A program which uses an explicit finite difference
	scheme to solve the diffusion equation with fixed
	boundary values and a given initial value for the
	density u(x,y,t). This version uses a numpy
	expression which is evaluated in C, so the
	computation time is greatly reduced over plain
	Python code.

	This version also uses matplotlib to create an
	animation of the time evolution of the density.
"""
import scipy as sp
import matplotlib
matplotlib.use('GTKAgg') # Change this as desired.
import gobject
from pylab import *
# Declare some variables:

dx=0.01        # Interval size in x-direction.
dy=0.01        # Interval size in y-direction.
a=0.5          # Diffusion constant.
timesteps=500  # Number of time-steps to evolve system.

nx = int(1/dx)
ny = int(1/dy)

dx2=dx**2 # To save CPU cycles, we'll compute Delta x^2
dy2=dy**2 # and Delta y^2 only once and store them.

# For stability, this is the largest interval possible
# for the size of the time-step:
dt = dx2*dy2/( 2*a*(dx2+dy2) )

# Start u and ui off as zero matrices:
ui = sp.zeros([nx,ny])
u = sp.zeros([nx,ny])

# Now, set the initial conditions (ui).
for i in range(nx):
	for j in range(ny):
		if ( ( (i*dx-0.5)**2+(j*dy-0.5)**2 <= 0.1)
			& ((i*dx-0.5)**2+(j*dy-0.5)**2>=.05) ):
				ui[i,j] = 1

def evolve_ts(u, ui):
	"""
	This function uses a numpy expression to
	evaluate the derivatives in the Laplacian, and
	calculates u[i,j] based on ui[i,j].
	"""
	u[1:-1, 1:-1] = ui[1:-1, 1:-1] + a*dt*( (ui[2:, 1:-1] - 2*ui[1:-1, 1:-1] + ui[:-2, 1:-1])/dx2 + (ui[1:-1, 2:] - 2*ui[1:-1, 1:-1] + ui[1:-1, :-2])/dy2 )

def updatefig(*args):
	global u, ui, m
	im.set_array(ui)
	manager.canvas.draw()
	# Uncomment the next two lines to save images as png
	# filename='diffusion_ts'+str(m)+'.png'
	# fig.savefig(filename)
	u[1:-1, 1:-1] = ui[1:-1, 1:-1] + a*dt*(
		(ui[2:, 1:-1] - 2*ui[1:-1, 1:-1] + ui[:-2, 1:-1])/dx2
		+ (ui[1:-1, 2:] - 2*ui[1:-1, 1:-1] + ui[1:-1, :-2])/dy2 )
	ui = sp.copy(u)
	m+=1
	print "Computing and rendering u for m =", m
	if m >= timesteps:
		return False
	return True

fig = plt.figure(1)
img = subplot(111)
im = img.imshow( ui, cmap=cm.hot, interpolation='nearest', origin='lower')
manager = get_current_fig_manager()

m=1
fig.colorbar( im ) # Show the colorbar along the side

# once idle, call updatefig until it returns false.
gobject.idle_add(updatefig)
show()