ToddHa's WebLog : Python

Subtle mistakes are often the worst

toddha — Wed, 16 Apr 2008 11:08:32 GMT

A few weeks ago, I noticed that some of my installs on my laptop started failing. I thought it was odd, but most of the things I install are pre-beta, so I figured that they hadn't yet started to support Windows Server 2008. Some things, out of beta, like Windows Live Writer, don't support 2k8 at all, so my laptop is set up to dual boot between 2k8 and Vista. Strangely enough, the installs were often failing during the very beginning of the setup process. One such install that failed was the Silverlight 2 Beta 1 SDK.

[Un?]Fortunately, it was the first of many installers to actually give me good information and tell me that it couldn't write the installation log to the temp directory. I had plenty of hard drive space, so I took a look at what my environment variables were for TEMP and TMP so I could look at the permissions of that folder.

What I saw (and isn't pictured), is that my user variables were set to:

TEMP=%USERPROFILE%\AppData\Local\Temp;C:\Progra~1\Python25
TMP=%USERPROFILE%\AppData\Local\Temp

Aha! The problem is so obvious now. A few weeks ago I installed Python. Python doesn't add itself to your path, so if you want to have access to it from anywhere, you need to add the Python install directory to your PATH variable. Apparently, I had tried doing this.

Unfortunately, the UI you are presented with could use some ... tweaking. Notice that there are two sets of New, Edit, and Delete buttons, all with different hot keys. If you expect Alt+E to be Edit, you're correct. However, you're incorrect if you think it will edit the item that is selected and focused. When I hit Alt+E, it always edits the selected User variable, regardless of what is focused.

It's a pretty poor UI, but fortunately it's one that most mainstream users won't need to see very often, if ever. And all others (like me) should take more time in editing their environment variables to make sure they are correct!

Assumptions are the mother of all (part 2).

toddha — Thu, 26 Apr 2007 04:33:31 GMT

In my own time, I've been learning Objective-C for fun. I'm not sure why, perhaps I didn't feel I spent enough time in front of a computer. But I digress.

One of the interesting things I've learned is that the following code works.

Note that I assume we have a class named ArbitraryObject, and that it has a method that takes no parameters entitled foo.

Objective-C

ArbitraryObject * obj; obj = nil; [obj foo];

Interesting, this code doesn't crash. In comparison, the following languages all crash when you try to do the equivalent.

ArbitraryObject obj = null; obj.foo();

This is the easy one. We get a NullReferenceException thrown.

Java

ArbitraryObject obj = null; obj.foo();

This is another easy one. We get a NullPointerException thrown.

Python

obj = None obj.foo()

Since we don't have to type what obj is, we get an AttributeError talking about how the NoneType object doesn't have an attribute of foo. Not exactly the same as before, but close enough.

C++

ArbitraryObject * obj = 0; obj->foo();

Note that this isn't the entire code required to get the program to crash (and I'm not sure what spurred me to prove to myself that it wouldn't work). The MS VC++ compiler was optimizing my defects away in different ways. I had to add an instance variable to the ArbitraryObject class, assign it in the constructor, and have foo return the variable. Then in the calling code I printf'd it. But I'm ignoring this for simplicity.

But regardless, it's an access violation error.

What we've proved is that Objective-C works very differently from how other programming languages work. There are some pros and cons of this, depending on your perspective. It's just important to know how things work.

A couple notes :

I use nil, null, 0, and None interchangeably.
I'm assuming the compiler hasn't optimized your (possibly intentional) errors away.
I really have nothing against any programming language or technology, so please don't assume that I'm some [arbitrary technology/programming langauge] basher or fanboy (even though Objective-C is primarily an Apple language, and Apple is a competitor to Microsoft). This is just another example of where you might think things work one way, and work a different way completely.
I find this particular example fascinating.

Performance

Comparing Objective-C performance to C#, Java, and Python isn't really fair as they all have to be translated into machine language at runtime.

However the C++ comparison is fair. What I'm assuming is happening in Objective-C (without diving into PPC assembly) is that there's a check before each function call that says, "Hey, if this address is nil then jump over this block of code that sets up for and executes the function call." So assumedly you have a some extra instructions every time you make a function call. Not a big deal, especially these days where we have a bazillion clock cycles per second, but definitely something that you need to think about if you're trying to squeeze every cycle out of the processor.

Program Flow

This is the main root problems I would assume. I'm going to use C# to flesh out the code, but you can easily translate it to Objective-C. More on this after the code.

Let's go back to our example code and flesh it out a bit in order to prove a point.

public class ArrayWrapper { private static int [] array = new int[] { 1, 2, 3, 4 }; private static int index = 10; public static SetIndex(int index) { ArrayWrapper.index = index; } public int GetIndexedValue() { // note that this crashes if index is the default value return ArrayWrapper.array[ArrayWrapper.index]; } } public class ArbitraryObject { // we don't have to define an empty constructor, but will anyways! public ArbitraryObject() { } public void foo() { ArrayWrapper.SetIndex(2); }}

And now for the driver code function.

public void DriverFunction(ArbitraryObject obj) { obj.foo(); // here we have assumed that obj.foo() did it's job and set the // index of the ArrayWrapper to a valid value Console.WriteLine(ArrayWrapper.GetIndexedValue().ToString()); }

Ok, so this seems like a really stupid example, but it's point is to show that you're assuming that the ArbitraryObject class worked in order for the rest of the function to work.

Let's run some tests. These are based on whether or not obj.foo( ) worked. I'm not going to translate this to Objective-C, but you can easily see what happens.

C# Tests
Valid instance of Arbitrary Object : Wrote out "3" to the console.
Null reference : NullReference exception at line xxxx.

Objective-C Tests
Valid instance of Arbitrary Object : Wrote out "3" to the console.
Null reference : Out of bounds error.

Ok, so we still get an error in Objective-C. And it's relatively easy to debug what's happening. But if the user gets this, the app will have crashed. And they'll get upset. Arguably, they'd get upset in C# too.

But what if the default index was valid? Like 0? We wouldn't crash, but we'd get incorrect results. Which is a LOT harder to debug. But doesn't crash for the user. Maybe it affects the final results that they're looking it for. Maybe it doesn't.

My point to all this is that this introduces a lot of subtleties to debugging something that you have to think about when writing or debugging the code. I'm not saying that it's bad at all. Sometimes you don't care about if the line fails or not -- and you don't have to write a bunch of function calls prefixed with if (reference != null).

Another reason to not make assumptions about the way things work (especially in new programming languages). :)

Assumptions are the mother of all.

toddha — Wed, 07 Feb 2007 23:44:00 GMT

While working on one of my side projects at work, I encounted something interesting with the % sign. The code that I'm going to talk about has nothing to do with any upcoming products -- it's simply a side project I'm working on in my free time that uses WCF and WPF (which are 2 major features of the .NET Framework 3.0). That being said, I've (hopefully) abstracted away everything project specific.

The problem I encountered came from doing some basic math in C# code. Simply, I construct an equation and evaluate what the answer should be by going from left to right (ignoring operator precedence). So when I came up with some final result, I wanted to double check that I was correct. But since I don't keep track of every equation or answer, I had to write a quick tool to trace through it. I'm a big fan of Python for prototyping because I've spent a lot of time in it and understand it well. So I copied over my C# code, made some slight modifications to save the intermediate data and then parse and print the data at the end, and ran it.

My final answer in Python didn't match that from the one calculated in C# (note that C++ returns the same as C#). The algorithm looked correct, but the final results didn't match.

Eventually, I found my problem. Take the following simple equation as an example:

-13 % 6 = ?

C# evaluates this to -1. Python, on the other hand, evaluates to 5. Um...what? Which one is correct?

Well, it depends on your point of view. Technically they're both correct. Just one method takes it one step further than the other.

-13 + 6 = -7

-7 + 6 = -1 (C# answer)

-1 + 6 = 5 (Python answer)

Hm. At first I thought that the in Python the answer will always be in the set {0, 1, 2, .... n-1 }, and the C# answer will always be in the set {0, ±1, ±2, .... ±(n-1) }. To check this, I ran another simple equation through Python and C#.

8 % -3 = ?

8 + -3 = 5

5 + -3 = 2 (C# answer)

2 + -3 = -1 (Python answer)

Theory crushed. Python and C# follow the same basic principle rule of all the answer being in the set {0, ±1, ±2, ... ±(n-1) }. But why does Python always take it further than the C# ?

So I looked up the community definition of modulo.

It turns out that the % sign has no strict definition. Python keeps the same sign as the divisor. C# keeps the same sign as the dividend.

What you should take away : don't always assume that operators will work the same in different languages.

Extra credit :

Windows Live Search and Google both provide basic calculator functions in their search. For example, searching for the term "2 + 2" in WLS and Google both give 4. But what about "-13 % 6"? Why do / don't they give the same answer?

Answer