Holding off on evaluating variables

There is a difference between performing a calculation and solving a problem.

I’ve been considering the equation of a circle, x^2 + y^2 = r^2. Except, you see, that’s not the entire thing. There’s a bit that we’ve dropped because it’s  zeroes (and therefore doesn’t affect our equation):

(x-h)^2 + (y-k)^2 = r^2.

This equation contains the full information–everything that is necessary to draw and position a circle on a cartesian graph. You see, the and k move the circle around the graph. When the circle is on the origin, they are both zero and often dropped from the formula. When figuring something quickly with a circle, the shortened form is more than adequate. However, without them, part of the story is lost.

Similarly, if we have the task of working a problem it is tempting to perform the arithmetic along the way. If we resist, however, at the end we produce a general solution that may be used for other similar problems.

Programming can work the same way. We may write a program to perform a calculation. This would involve lots of hardcoding, many assumptions making it analogous to our “arithmetic along the way”.

Alternatively, try leaving the variables in, or not doing the arithmetic along the way, and preserve the information in the equation which would otherwise be lost.

Naive Programming

I think that may always be the case, especially when the resulting program is a function of what I’m asked to do! I was instead considering how, give experience in mathematical reasoning and programming, one writes increasingly concise code.

Because of the intense usefulness of Maths in programming, I cannot grok my fellow students’ disapproval of the subject. One of the major ways my code has grown less naive is in the borrowing of mathematical concepts.

Naive:

// print the sum of numbers x through y.
int sum(int x, int y) {
  int s = 0;
  for (int i = x; i <= y; i++)
    s += i;

  return s;
}

Insightful:

// print the sum of numbers x through y.
int sum(int x, int y) {
  return y*(y+1)/2 - x*(x+1)/2; 
}

I cannot remember a time when a working insightful function has been worse then the naive equivalent. Even in my contrived example above the naive_sum() has inputs which would yield undefined output such as the case where y <= x while the insightful_sum() would degrade more gracefully.

In the naive style, we’d have to add conditionals to validate inputs that the maths would accept, meaning increased line count, reduced legibility, increased chance of errors, and increased nativity. The only advantage I can see to the naive style is the reduction in mathematically cluttered code.

Active Directory / Python / Linux

My custom “mldap” module, which interfaces with Windows 2003 Active Directory via Python LDAP is growing again! I’ve started objectifying the code and integrating more with my Aims module.

I’m 90% on a piece that does userAccountControl bits. My next goal is to create a User object that I can use to create / modify / synchronize Active Directory / AIMS users. I don’t write anything AIMS yet, it’s a read only, but if that needs to change it can.

Cool beans.

PHP!?

Crikey, I loath PHP. I almost hated it due to an oversight in modifying this site’s scripts.

return “$root/$blog_id”;

The above does, in fact, work. It was getting butchered elsewhere.

Every thumbnailed image in WordPress assumed that I was the only user and knew nothing of the dynamic paths. I’ve since re-written the thumbnail script (cropper.php) to convert /path/ to blog_ids for proper operation and should polish off the results and put them back upstream (if possible).