Every user query is a puzzle

The user didn’t really mean to give you a level 5 puzzle to solve. But that’s what it is. Every time the user asks you to help him solve a software related problem, he’s giving you a puzzle.

Sometimes, it’s a level 1 puzzle, where you don’t even need to fire up your code editor to glance through the code to answer, or give more than a few seconds to think through. Sometimes, you have to really push for lots of hints, like clarifying the user’s query, ask for screenshots (even if sometimes they aren’t enough…), and dig through code archives.

I got a level 1.5-ish puzzle lately… The user said he couldn’t use the delete button. I fired up the application, selected a record, and indeed the delete button was disabled. On a whim, I double-clicked. The details of the selected record came up, and the delete button was enabled.

I have never seen or used that particular section of the application before. The user on the other hand, was supposed to be familiar with the application. Perhaps I’m more willing to try out typing randomly or aimlessly clicking the mouse on an application screen. I certainly typed enough asdf’s…

So, have you encountered any high level puzzles? Share in the comments.

Polymercation aka Polymath Programmer Publication

I’m feeling restless. There’s a bunch of stuff I want to share and somehow they don’t make it here to the blog. There’s so much I want to learn, and I have the usual excuses of too little time, little motivation, little interest…

I find myself talking and writing and thinking more about software than actually coding. Much of the software work I do nowadays are quite simple… after I’ve done the heavyweight thinking that is. I think and scribble on paper a lot.

Truth be told, I feel like I’m stagnating. Which isn’t too bad if it’s restricted to only coding. I kind of miss the feeling of learning something because I’m interested and excited about it, and just because I’m learning something new.

I want to do something about it.

Newspaper printing machine
[image by Gabriela Schaufelberger]

I’m starting a newsletter. I know, I know, the last time I started a newsletter, it didn’t quite work out. The topics seem to overlap very much with the blog topics, and I felt the blog format worked better. I can easily include images and videos on the blog.

This time round, I’m treating it more like an informal lesson plan to myself. Hopefully, it’s also useful to you too.

The schedule will be about once a month. Maybe twice a month, if there’s a lot of material to cover. But 3 times a month is the maximum. I didn’t keep to the once-a-fortnight schedule the last time, so there’s no reason to believe I have the fortitude to come up with 3 newsletters in a month…

I still want to include stuff from both the arts and the sciences. Actually I’ll be covering a lot of ground. I plan to also touch on marketing, sales, and other business-related stuff (I got interested because I wanted to know more about how my employer operates). I may not write about those topics, but I can certainly provide links to people who wrote great articles on them. Psychology-related articles too, since I’m fascinated by human behaviour.

My blog seems to be stretching to cover a lot of topics, even if they circle around mathematics and programming. Am I setting myself up for failure by creating a newsletter that’s even broader in scope? I don’t know.

Right now, I have 2 main goals. Be curious, and to make the world a better place. With the rise of technology, and its usefulness to our lives, I believe a programmer can do much more to help.

I don’t know how as a programmer I can contribute to making the world a better place. Making better user interfaces? Creating better software so there’s less toxic emissions?

But I do know that curiosity plays a part. It’s not about “I can learn to do X when I need to do X, not before”. It’s about cultivating the habit of being curious. The moment I stop being curious, then I stop learning, and I stop trying to make a difference.

I quote:

Creative work only seems like a magic trick to people who don’t understand that it’s ultimately still work. – Merlin Mann

If you haven’t figured it out, programming is creative work. So I’m working harder on getting better at it. I’m just approaching it from all kinds of angles.

Medicine? Those machines and reports and medical records? Someone has to write software for them. Space shuttles, trajectory calculations and fuel usage? Someone has to write software for them. Traffic simulations, city modelling and urban planning. Someone has to write software for them.

I’d rather that someone be you. Sure, I may not know much about you, but if you’re reading my blog, then you probably care about your education (not necessarily in an academic setting) and the world at large. Ok, back to the newsletter thing.

The original newsletter was named P3, as a shortening of Polymath Programmer Publication. For some reason, I really want to actually publish something. A blog doesn’t quite fill that urge. A newsletter sounds very fun. Anyway, “Polymath Programmer Publication” is too long, and P3 doesn’t quite have a characteristic distinction.

Following my portmanteau of Polymath Programmer into Polymer, you now have Polymercation, a newsletter for Polymers. The newsletter will contain content that’s separate from the blog content, a mishmash of tidbits and thought-provokers. And I want to do this together with you, because it’s as much an informal lesson for you as it is for me. The sign up form is on my blog (so if you’re reading this in a feed reader, please visit my blog).

You know the making the world a better place part? I have a problem. I can’t do it alone. I need your help. If you know anything that can help expand my education, let me know. In return, I’ll source for material to help you in your life, on your education, on your goals. Fair?

This will be an exciting journey.

Dissecting Trigonometric Particles part 2 – Axis functions

This is a continuation of the explanation behind Trigonometric Particles. Read up on part 1 if you haven’t done so.

Actually, there isn’t a clever coding construct I used to implement the axis functions. I just created a function that does a combination of polynomials and trigonometry functions. It looks something like this:

float function AxisFunction(float t, float p0, float p1, float p2, float p3, float p4, float p5, float p6)
{
	float result = 0.0;
	result += p0 + p1*t + p2*t*t + p3*t*t*t;
	result += p4*sin(t) + p5*cos(t) + p6*tan(t);

	return result;
}

The variable t is the time elapsed. The first part of the function is basically a cubic polynomial. The second part is a sum of the 3 standard trigonometric functions. Basically, I’m just passing in parameters which are the coefficients of the respective terms.

To simulate a sphere, since I can’t quite summon the mental energy to switch between my preferred Y-axis-pointing-skywards and the more widely known Z-axis-pointing-skywards coordinate system, I’ll just use the more famous version to illustrate. So the axes are:
x = r * sin(theta) * cos(phi)
y = r * sin(theta) * sin(phi)
z = r * cos(theta)

To calculate the X, Y, Z coordinates, I just use different combinations of AxisFunction(). So
x = AxisFunction(t, 0,0,0,0, r,0,0) * AxisFunction(t/2, 0,0,0,0, 0,1,0)
y = AxisFunction(t, 0,0,0,0, r,0,0) * AxisFunction(t/2, 0,0,0,0, 1,0,0)
z = AxisFunction(t, 0,0,0,0, 0,r,0)

I’m passing t/2 for a different-valued phi. I can’t remember the exact multiple of t I used… so I’m just using t/2 as an example. For the sphere simulation, I was playing around with t to get the particles to swirl and end roughly near the top of the sphere. Took me a while to figure out the right magic number…

To simulate a cylinder, just set polar coordinates on X and Y, then use Z as the height.
x = AxisFunction(t, 0,0,0,0, 0,r,0)
y = AxisFunction(t, 0,0,0,0, r,0,0)
z = AxisFunction(t, 0,H,0,0, 0,0,0)
where H corresponds to the speed value you want the particles to “climb” the cylinder. Again, much time taken to figure out the right magic number…

As for the tornado simulation, notice that it’s similar to that of a cylinder, and the particles circle with a wider radius as they climb the cylinder. So the radius is now a function of the height.

Actually, we just need the radius to increase as t increases, not necessarily as a function of height. So we apply a linear function to r.
x = AF(t, 0,0,0,0, 0, r * AF(t, 0,L,0,0, 0,0,0), 0)
y = AF(t, 0,0,0,0, r * AF(t, 0,L,0,0, 0,0,0), 0,0)
z = AF(t, 0,H,0,0, 0,0,0)
where L is some magic number such that the radius increases in a reasonable manner proportionate to the time elapsed (and effectively proportionate to the height).

I have a confession to make. When I first introduced Trigonometric Particles, I said I used a W axis as well as composite functions. Well I truly remembered having a W axis, and I think I used it as such:
x = W * AF(…)
or maybe
x = AF( … W, …)

But I’m not using W in my explanations above. Hmm… somehow while writing the explanations, the W axis wasn’t required.

As for composite functions, a short description. H is a composite function when
H(x) = F(G(x))
meaning you calculate G(x) first, then calculate function F using G(x). That’s what we’re doing when we passed in one form of AxisFunction() to another AxisFunction() as a parameter.

Well, my memory being foggy, I seem to recall having both W axis and the use of composite functions. It appears one can simulate the results with one or the other. Oh well, no one’s perfect…

And the last simulation pattern, the sun’s surface? I think I used a pure polynomial. Quadratic, I think…

Jerk jumping assignments are bad

Do you deal with incrementing values of a cyclic nature? For example, angular values used in sine functions? Then be careful when you reach the cycle’s end.

Back when I was doing an OpenGL class project in university, there was this Ferris wheel simulation. The Ferris wheel was going to keep turning, and there’s a variable keeping track of the angle of rotation.

Even though a float or double can take in large values, there’s still the possibility that it would overflow if unchecked. So most of us (the students) just keep the variable to within the [0, 2*PI) range.

The thing was, some students jerk jump the assignment as follows:

if (rot > 2*PI)
{
	rot = 0.0;
}

Well, there’s nothing wrong with getting it back to square zero, isn’t it?

Ahh, but PI is an irrational number, and couple that with the sometimes inexact representation of floating point variables, it means the variable rot is probably never exactly 2*PI. This means (rot – 2*PI) is greater than zero. And the students just smashed that difference to pieces.

It also meant their Ferris wheels would appear jerky. The Ferris wheels would rotate until 2*PI was exceeded, and then snap back to when they’re at zero rotation. Depending on how much their increments were (which affected the speed of rotation), the jerky movements could be more pronounced.

The smoother solution is to subtract a full cycle value:

if (rot > 2*PI)
{
	rot -= 2*PI;
}

There’s a caveat. It assumes the incremental value is less than 2*PI. That’s a safe assumption. It’s not like you’d do something like this, right?

rot += (2*PI + 0.5);
if (rot > 2*PI)
{
	rot -= 2*PI;
}

Right?!?!

This reminds me of sinks and diverging values in chaos theory… f(x)=x^2 tends to zero if x<1, but goes to infinity if x>1.

Anyway, be careful of assignments when you reach boundaries. Because jerk jumping assignments are bad.

How to prorate in discrete blocks

Recently, I had the occasion to contemplate prorating logic. Alright, fine, I was tasked with implementing some business logic which required prorating, but in discrete blocks. Let me explain.

Suppose you’re providing a service, and you charge in minutes. Say as a promotion, you give away 600 minutes for free per month, on condition that the customer stay with you for a certain number of months. The customer backs out on that condition on the 17th of his first month, so the customer has to pay for the rest of the free minutes of that month (there are 31 days for that month). BUT, and here’s the kicker, the price must be calculated based on blocks of 6 minutes.

So you have to prorate the remaining minutes, and it has to be in multiples of 6.

Ok, that wasn’t much of a challenge. I thought I’d just write down how to do it anyway. Here’s the C# code.

int num = (31 - 17), den = 31, block = 6, total = 600;
int prorated = 0;
prorated = (int)(Math.Round(((double)num / den) / block * total, 0)) * block;
Console.WriteLine(prorated);

The only things to note are the casts to int and double. And that the example was quite contrived.

Dissecting Trigonometric Particles part 1 – Particle system

Last week, I introduced a particle effects demo named Trigonometric Particles. Today, I’m going to explain the mechanics behind making it work. But first…

What is a particle system?

I’m sure you can find many articles on the definition. A particle system is basically a collection of particles, and controls the particles through some logic you defined. Uh, so what’s a particle?

Think of smoke. Imagine it being comprised of thousands of small bits of carbon matter. Which it is, in a manner of speaking. And there you have it, each small bit of carbon matter is a particle.

Particles and particle systems are commonly used to simulate smoke, fire, water, explosions. Anywhere when there are large numbers of particles (for lack of a better word…) behaving in a certain way, and you need a system to control them. You could directly manipulate them in the program, but the logic won’t be portable to other programs. “You need smoke in another program? Here, use this particle systems class.”

The class representing a particle I used in Trigonometric Particles had a 3D position with X-, Y- and Z-axes (in terms of functions of time), colour (red, green, blue), and life (length of display or existence). Some particle systems have particle velocities, gravities and probably concepts I won’t even think of. The one I’m using has few components, but the axis functions are complex.

What happens is, for every frame of animation, you update each particle with the correct calculations. Say, one particle was here, then at the next frame, it should be there, according to the simulation logic. And you iterate through the entire list of particles, updating each component as needed (such as decreasing the life counter).

Usually, you don’t update the positional component directly. You update the velocity, and let the velocity influence the position instead. There could also be a global gravity (or local to the particle), which influences the velocity, which in turn influences the position.

So the order of updating probably goes like this: you update the position based on the current velocity. Then you update the current velocity based on the gravity component. Then you update the gravity component based on the logic you require. This happens in one frame of update. As you can imagine, that’s a lot of updates to stick your hand into in a program. It might be easier to pull the standard updating logic into a class.

I understand that this long method of indirect updating creates a smoother particle simulation. Say you’re simulating a waterfall and drops of water are initially splashing to the right. As each water droplet is influenced by gravity (downwards), its velocity starts shifting downwards. But it’s still moving fairly fast towards the right. But on each subsequent update, it moves faster towards the ground, hence simulating the gravitational effect.

In my case, I’m directly manipulating the position because I don’t need that kind of smoothness. It’s taken care of by the axis functions. I’ll explain more in another article.

Oh, and the life counter? It’s usually 1, and goes down to 0. It’s like an alpha setting, usually used when rendering the particle. So at 1, it’s displayed at full strength. As it winds down to 0, the particle is rendered at greater and greater transparency, till you finally can’t see it. Depending on your logic, you might “revive” the particle by giving it full strength and starting over, or just let it “die”.

Speaking of alpha values, here’s the bitmap I used for rendering my particles.
Particle texture
I blew it up from 32 by 32 pixels to 128 by 128 pixels so you can see it better. I think I used my Bryce renderer to generate this (yes, I know it’s weird using a full 3D graphics renderer to generate a small bitmap for a particle effects demo… but it’s the only tool I have to generate it! Anyway…). It starts as a white square, then I applied Gaussian filters to it so a circular white blob is in the center fading to black at the edges.

You can do this with Paint.NET as well (I didn’t have it back then). Version 3.36 allows you to use the Gradient tool. Just use the radial gradient.

In my demo, I mapped this bitmap as a texture to my particles. I set the bitmap to the specified colour of the particle, and use the “height map” value of the bitmap as an alpha value. So if the particle is red, then it’s rendered like the bitmap texture, but in red, fading gradually to transparency towards the edges.

Then I used the life counter to further augment the alpha value. So at full life, the centre of the bitmap is rendered at zero transparency (full opaqueness). As the life counter goes down, the bitmap is rendered at the transparency inversely proportional to the life counter. Just look at the point in my video where I said to fade the top of the tornado. This was what I was doing. Other times, I just rendered all particles at full strength. Just download my demo and play with it already!

The bitmap texture is in black and white because its purpose is to give shape to the rendered output, which is a circular blob fading at the edges. Colour is provided by the particle’s properties. And it’s small in size, because my particles are small.

This also means that your particle system can use some other form of rendering the particles. For example, you could use a different texture, such as wispy puffs, which you could bunch together and animate and they could look like moving clouds.

Or you could render full 3D models using the positional information of the particles. Rendering textured mapped quadrilaterals is faster than rendering 3D models, which is a big deal because there are a lot of particles. But depending on your situation (maybe you need less particles), and targeted computer speed, 3D models may be more suitable.

And that’s all I have to say for now. You want to ask about or add information to my particular brand of particle systems (used in my demo), or about particle systems in general? Post it in a comment below or email me.

If a bull charges at them, they will run

It’s a natural reaction. When people see an angry animal charging towards them, they run. Very fast.

Charging elephant
[image by RollingEarth]

So why do programmers think setting user interface controls that are enabled to display as disabled, is acceptable?

When users see a greyed out text box, what do they think? It’s disabled. There’s an application I’m maintaining where the text boxes are all greyed out, the same colour as the background (it’s a Windows program).

“Oh I can’t enter anything,” complains the user.
“Really? Have you tried typing something in the text box?” I ask.
“I can’t type anything, I tell you!”
“Ok, let me check…”

*some time later after checking*

“Hi, I’ve checked. You can still type stuff into the text box. It’s just greyed out. And you can save the information too. I’ve also modified the program to make it easier to see.”

Yes, users are so convinced of the obvious that they don’t even bother to check if the text boxes are actually disabled. Is it the fault of users? Is it the fault of the programmer? I feel both are at fault, but the programmer more so. Wrong display of enabled and disabled controls is too simple an error to make.

The scene described above actually happened during my work. It’s not about educating the users that they can actually type in the text box, because it’s a design flaw. It’s the fact that they didn’t even bother to try that I’m concerned with. It makes debugging user queries very challenging…

Sometimes, the obvious blinds us, to the point where we react to something that seems obvious to us, but is not the actual thing. There are now things and events we can have time to think through before reacting. I believe we have evolved more than our hunter/gatherer roots.

Of course, if there’s a raging bull charging at you, don’t stop to ask questions. Just run.

Trigonometric Particles

So I dredged up a relic program from some folder that’s been unopened for ages. I was like, “I wrote that?” I was playing with the program, and thought “Hey, why don’t I make a video?”. So here’s “Trigonometric Particles” video:


Trigonometric Particles from Vincent Tan on Vimeo.

Special thanks to Ben for letting me use one of his songs “Bobsleigh” as the background music. He’s awesome. I love the quick tempo, which matches the non-stop streaming of particles.

The program uses OpenGL for 3D rendering, and I used the SDL library to help. Basically, I visualised each axis as a function. So the X axis is say, a sine function. With some creativity, I can form cylinders, cones and spheres with the 3 axes.

I submitted the program to NeHe Productions, an OpenGL site related to game programming. The submission is placed under P of the download section. I learnt a lot from the site such as general 3D skills and OpenGL tricks.

You can download the program here too (216 KB). The website address and email address in the zip file are no longer in use. It’s been 5 years since… or was it 6 years?

I’ll talk more about the mechanics soon. And yeah, I lost the source code (darn it!), so I’ll be speaking from memory. For now, just enjoy the video. If you’re hardcore, you can try dissecting the mechanics yourself. Hint: There’s an additional W axis. Hint: Composite functions are involved. Post your findings in the comments, and we’ll see how you did.

Brain dead

I can’t think. I can’t focus. My thoughts are scattered, flying around of their own volition, out of my reach, out of my control.

I believe this is what people call “burnt out”.

For the past couple of months, I’ve been coding for, or working on, a few projects. I was either the sole developer, or a major contributor to the project. Their deadlines had been either back-to-back or overlapping. And this unhealthy schedule stays for the next couple of months.

I may be a Polymer, but I am only one.

There had been a few instances in the past where projects bunch up together. It was tough, but I weathered through. This time, it took its toll on me. I’ve never been out of the Zone for so long.

All my usual remedies failed. Reading. Hanging out with friends. Listening to upbeat music while working (but I already do that on a regular basis). Tea. Playing video games. Exercise. Coffee (mocha. I can’t withstand the strength of “normal” coffee…). Going for walks.

I was about to attempt unfettered hedonistic pleasures when I remembered I could take a break. Ok, it was more like “Take a day off!”, “Stop working!” and “Fight for Freedom!”. Ok, maybe not the last one…

I heeded those subtle hints, and took a day off here, a day off there. The Chinese New Year, which was just over, lengthened a weekend. So many people were taking days off too. Hint: don’t take the same days off as the other people if you can help it. Take those days when they’re back in office. This way, you get more done because you don’t get interrupted.

Stop interrupting me!

This episode was seriously difficult to recover from.

It came back, surprising me with its arrival. My coding groove. There were no announcements, no hints. One day I was down in the slumps, the next I was able to think cogently for a few hours straight. That gave me enough time to sift through the requirements, because much of programming isn’t really writing the code. It’s thinking.

I’m still feeling terrible, but at least I’m able to get the projects moving faster now. All the tricks for getting my energy back failed abysmally. In the end, my mind and body provided the best solution.

It was time. I just needed to rest. Sometimes, the fastest way is to stop.

You can start in the middle of a loop

I’ve always been quite free with the limits of my loops. When I first learned the do-while, for and while loops, the start and end points weren’t fixated in my mind. Let me explain.

The usual start and end points are 0 and the number of iterations required minus one (yes, I’m in zero-index C territory). The professor was very persistent in ensuring we know how many iterations there were (I was a freshman in university). I thought it’s obvious, but apparently it’s a common error to miscount.

Just as important, you shouldn’t be fixated on the number of iterations in a loop too. Say you need to iterate for each month in a year. That’s 12 iterations. For the first 8 months, you need to do one thing, and for the other 4 months, you need to do something else. This is not recommended:

int i = 0;
for (i=1; i<=12; ++i)
{
	if (i<=8)
	{
		// do A
	}
	else
	{
		// do B
	}
}

It's confusing to read if tasks A and B are complex. Better to just:

int i = 0;
for (i=1; i<=8; ++i)
{
	// do A
}

for (i=9; i<=12; ++i)
{
	// do B
}

The tasks are now clearly defined and the code is easier to read. With the current hardware, I think the absence of 1 if-else or the presence of a 2nd for loop won't make much of a speed issue, so it's not really for optimisation purposes either.

Another common code chunk I encounter is the do-the-first-one-differently loop. There's a list you need to iterate through, but for the first one, you have to do something extra or different.

Here's an idea. Why don't you do that first iteration by itself, and start the loop on the second iteration?

There is no restriction you have to start a loop with the first or last item, or with 0 or (list.Count - 1). Loop where it makes sense. I hereby give thee permission to start in the middle of a loop.