Safer Integer Types (part III)

A few days ago (again at the time of writing, but since I accumulate and schedule posts for a weekly release, that may already mean a few months ago) a friend was a bit nonplussed by the fact that an expression such as:

int x;
unsigned int y;

if (x+y<0)
 {
  ...
 }

was simply never true. At first, you’re thinking “how can this be?” because you’re trying to find values of x and y that, summed together, are obviously negative. That is, without counting on the surprising integer promotion/integral conversion system of C and C++.

Let us see what’s going on exactly.

Cutting Corners

Cutting corners is generally thought of as a bad thing. It generally is, I agree. But in some occasions, optimally cutting corners is the right thing to do. I can show you what I mean. Using the Logo programming language (precisely the KTurtle implementation), I devised the following experiment. Consider the following image:

Two circles drawn with KTurtle

Not Loosing the Perspective

My first true computer, a TI 99/4a (which I talk about also in a previous entry), had 16 or 48 KB of RAM, depending whether or not you had one of the memory expansion cartridges, and that limited quantity of memory severely curbed the complexity of the programs one could write on the machine. However, the limited complexity of the programs, the relative crudeness of the development environment (a BASIC shell) and the slow execution speeds weren’t very obvious to me back then. They were somewhat mitigated by the novelty of the computer itself as a machine, and by the perpetual intense excitement of discovery. The arduous design of programs to save memory, fit more graphics or more code, or even getting our programs to work at all was less about constraints than challenge.

The same kind of constraints—or challenge—followed me over the years as I moved on to different computers. Despite their being more powerful, both faster and sporting more memory, the challenge remained there because while the computers got better, so did I at programming. I kept asking more out of the machine, writing increasingly complex programs needing either more memory or more speed, often both. That meant better algorithms, better data structures, and better implementations¹.

The Fizzbuzz problem

You are given the following assignment:

You are to write a program that must fulfill these simple requirements:

For the numbers from 1 to 100,

• If the number is a multiple of 3, print fizz instead of the number.
• If the number is a multiple of 5, print buzz instead of the number.
• If the number is a multiple of 15, print fizzbuzz instead of the number.
• Otherwise, print the number itself.
• Each output should be followed by a new line.

Can you code that and get it right in less than one minute? In less than two? How many retries will be necessary? Open your favorite editor for your favorite programming language. Ready? Set? Go!

Calibrating your LCD for Better Results

When you’re designing interfaces or adjusting your color photos, you must be able to rely on your computer screen for color accuracy. As you may know, I am an amateur photographer and, consequently, I often post-process my pictures to make them actually presentable. However, I would never do such a thing on my Dell laptop because the matte LCD screen is… well, let’s say not up to the task. Red ends up somewhat salmony, so I really can’t use it to do any kind of decent photo processing. My old Vaio, on the other hand, with its glossy display renders stunningly deep and vibrant colors.

But just how much can you trust your display? Can you adjust it without buying the rather expensive color calibration gizmos yet have decent results? In this week’s post, I present my techniques (meaning: tricks) to calibrate LCD (most also apply to CRT) screens.

Different problems aren’t always different

Magic Squares are much less frequent than latin squares in computer science (on which we may come back in the future), but they have a number of (fun) applications.

Historically, magic squares are tied to numerology, alchemy and other esoteric sytems. However, as you may already know, I’m not interested in pseudoscience except to debunk it, so this post isn’t about using magic squares turtles to predict the level of the river running behind your house.

Albrech Dürer's Melancholia I

What the Happy Hacking Keyboard should have been

The Quest for the Perfect Hacking Keyboard is indeed an eternal one. Over the years, I had great many keyboards and most of them went the way of the dodo. Recently, despite not having other Apple products, I tried the (wired) thin Apple aluminum keyboard. As I prefer very thin keyboard over thick ones, and laptop-style keys to the big M Type keys; it was a very good match. However, after a while, I got unnerved by the extra, useless keypad. In short, the keyboard is too long: as I am right handed, it’s always somehow in the way of the mouse so I started looking for a better keyboard. Again.

So I got the Apple aluminium keyboard, wireless version.

Suggested Reading: The Myths of Innovation

Scott Berkun — The Myths of Innovation — O’Reilly, 2007, 178 pp. ISBN 978-0-596-52705-1

(buy at Amazon.com)

In this book, Berkun debunks the myths surrounding the new, the innovation, the invention that will change the world, surrounding the inventor, lonely and strange, superman or genius. In ten chapters, he systematically demolishes a series of myths, starting by the myth of epiphany, that is, how an innovation is “revealed” to its inventor. He explains how and why such epiphanies do not exist, and, if they exist, how they cannot be anything but the final step of long, tedious work.

Your Automatisms Betray You

Yesterday someone dropped on the IRC channel where my fellow programmers, computer enthusiasts, and I hang out to get help to find a bug. He uses one of the paste sites (like pastebin.ca, pastebin.com, or rafb.net), pastes his piece of offending code, and so we get a look at the code. Of course, I go over the short program, notice a mistake in the scanf but it took me a full two minutes to notice the loop:

for (c=0; c++; cwe don’t read what’s actually written, but what we think is written, unless we pay the utmost attention to the code—what we should be doing anyway, but do not always. Usually, you zero in on that kind of bug rapidly, as you guide your search from the bug’s symptoms which leads you to defect’s approximate location. If you’re like me—write a little, test a lot—you find those bugs right away most of the times. However, even if you zero in rapidly, you still get a coarse-grained location: module, class, function.

Music to Code to

If you’re anything like me, you like to create a musical bubble to isolate you from your surroundings and being able to concentrate on what you actually have to do. To do so, I have amassed a rather long list of dub, trance, techno mixes. Some are 90 minutes long, and are very well crafted. People who think that techno is always the same (boom-tss-boom-tss) are clearly missing something.

I have bought numerous CDs over the years, but it turns out that there are a lot of (legal, DRM-free) free podcasts out there, and while they’re not all easy to find, they’re easy to share. Here are the few I d/l recently:

The Zoolook Project has several podcasts of ambient, trance, hard techno, etc., mixes. Amongst which I like:

• Révélations
• Somptuaire

There’s also the T.O.U.C.H. Samadhi website that offers both streaming and pod casts. A bit wierder, maybe. I like:

• SOT: Alpha Site
• DJ NOD live at tetragrammatrance 2

Other personnal favorites include the DJ LNG mixes found at DJ LNG (aka Romalong)‘s page. Especially Random Regularity.

Happy hacking, then!