learning gtkmm

GTK+ is a graphics user interface (GUI) toolkit for C; since I prefer to work with C++ over C, I use its related C++ binding, known as GTK-- or gtkmm. From what I have learned so far, it's actually a very elegant solution to a dilemma that I faced this week: how to build a cross-platform program with a window interface.

The keyword here is "cross-platform". MFC is not an option here, because it's targeted to Windows. In addition, my impression with MFC has been rather... disappointing. It's hard to learn and very cryptic for a new C++ programmer like myself. My past experience with frameworks like .NET has shown me far more elegant ways of graphical programming.

There are just so many ways in which GTK+ is different from MFC... other than the elegance of its structure. For example, I can make windows that are very resizable without putting a lot of effort -- because GTK+ is based on a simple "bin/container" system (where you can drop "controls" or widgets into highly flexible boxes), rather than the absolute-positioning system (specifying precise X, Y, width and height of each control) that MFC uses.

Of course, there are many other options out there besides GTK+, e.g. Qt, but right now I want to focus on one of my options (chosen rather arbitrarily) and work on it. If GTK+ satisfies my needs, then I will most likely stick with it for a while; otherwise, I can just choose another framework to work on (preferably sooner to make code modification easier).

There are so many things that intrigue me about C++ that I can't write down all at once -- it's like discovering a whole new world. I'll try and keep things updated when possible.

a shift in focus

Several semesters of pure math and physics, and it's time for a (temporary) change. As I have already mentioned, my focus this summer is on C++ programming. What I probably forgot to mention is that I'm also taking some social science courses this semester, so I'll be treading on unfamiliar territory.

I don't know much about sociology, and a little about cognitive psychology. Nonetheless, those are the courses that I'll be taking the first half of summer. Without the experience, these two subjects will seem very new to me, which is a rather unusual feeling. I typically have at least a small idea of what goes on in my usual science classes, so I might not be used to this kind of feeling.

Recently, I took the first few classes of these two courses, and they went quite well so far. I find myself more interested in the psychology class than the sociology one, since the psychology class also had a lot of biology in it -- akin to the molecular & cellular biology that I just did last semester.

Interestingly, the instructors were rather young ones, which is something that I'm not typically used to (unless they are teaching assistants, but this isn't the case). The teaching methods are a little different for my psychology class, but I think I should be able to work with that. The instructor tends to use rather unusual approaches, and talks with a more "informal" tone.

So far it's only been about a week, so I can't tell how effective my instructors for the two classes are. I do hope they are helpful, considering these two classes will be harder than my average science classes.

reorientation

Phew, the spring semester just ended. It was definitely more work than I had anticipated, and with my usual disorganization, my daily and routine schedule was completely destroyed.

So now that I've "sort-of" settled in my new abode, it's time to start over and reconstruct the broken schedule I had for the past few weeks: turning my biological clock back by a few hours so as to resume what a normal person should have. Because of that, I would really appreciate the summer classes starting next week, since I tend to lose track of time when I have no deadlines.

A goal that I set myself for this summer is to learn C++, for real this time. There is actually a need to do so in order to work on a certain research project, so there is no excuse this time. I had avoided it for long enough, and now it's time to embrace it. I understand that it will be much harder to learn than Python or C#, but I expect it to be a fruitful effort, considering so many programs are written in C/C++ nowadays.

One of the tough decisions is to select the programming framework. I would really want to learn one for Unix, but so far my main focus must be MFC (i.e. Windows) because that's what the current program is written in. Perhaps if I'm ambitious, I could try rewriting it for Unix, or even better, for a more generalized interface so that it works on all platforms. That would be a difficult task though. Regardless, I hope I would at least accomplish the "learn C++" part.

rapid post

Since I haven't written anything for weeks, I decided to write one short post to keep it updated. I should be able to return to blogging after this finals week of exams.

That's one thing: finals this week. Secondly, and what follows, is that the spring semester is nearly over, and summer semester begin in less than two weeks. I do have classes during summer, but I think it will be much less exhausting than what I have done this semester.

There are so many things that I had wanted to do, only to be deprived of the time because of the overwhelming amount of homework (and that is precisely why I am glad my intro physics lab II is over: no more lab reports).

As stated, I should be able to resume blogging once I sort out a more, um, "regular" schedule with more free time.

pointers

Pointers are the one unique "data type" in C. Now that I'm slightly more acquainted with the language, I realized that C is all about pointers and memory management.

What makes pointers and memory management so useful is that they allow dynamic objects to exist during run-time. This dynamic behavior is absolutely essential because most of the time we don't know how much data we will get from user.

Take an input string, for example. This is trivial in higher level languages like Python, but a real difficulty in C. Normally, C has to know what length an array of characters (a so-called "string") has to be in order to input them from standard input, but if I can allocate memory dynamically, I can set this size to any size I want, and expand it if necessary.

Pointers, aside from being a useful tool for passing parameters by reference, are intimately related to memory management, because pointers is the way in which memory is addressed.

One might wonder, where are these features in other higher level languages? Most of them would be either hidden ("unrecommended") or non-existent. Why so? If pointers are that flexible, then why don't we have them in higher languages?

The hard part about pointers and memory management is that you have to know how to use them, and to use them correctly. Messing around with them lead to things like the so-called "memory leaks". I consider the name a bit misleading... It's not like memory is vanishing or anything, but rather, the program is "hogging" memory even though it no longer needs it.

That's the problem with manual memory management: it's useful, but it can be also dangerous. It's "dangerous" because it can literally cause unexpected side-effects to one's own program. It's not just a matter of "memory leaks": other and more dangerous issues include unintentionally editing the data where you shouldn't, or trying to read data from the wrong place.

Either case, if the program decides to overwrite its own data but at the wrong place, the error may go unnoticed. If it attempts to read or write to memory that doesn't belong to the program, the operating system will refuse and cause the so-called 'segfaults'.

"With power comes responsibility" describes the situation quite well here. The direct manipulation of memory allows C to perform tasks efficiently, if used well; on the other hand, if it's not used well, it can lead to all sorts of unexpected errors, which may be either obvious or, even worse, subtle.

catching up

It's April, and it still felt as if I was in the middle of the semester.

As "expected", the list of things that I should/must do is growing at a much larger rate than previously, and this means free time will be a lot harder.

What I recently noticed is that whenever I'm reading or studying, I prefer to do it in a "free" mood rather than being forced upon, because I can explore things and understand things more deeply, rather than the "surface" understanding that I get from studies and revisions.

And this is why I often take longer doing math and physics homework - I need to understand it, because rushing over a problem, just like glossing over a book, is not helpful. It's a lot easier to forget if one only has a surface understanding of the subject.

But when time is scarce like during these periods, I often don't have the time to slowly work on things... and this would only affect my understanding of the material.

I don't think I can "catch up" my studying after semester, because by then I'd have little incentive to do so.

Perhaps this also explains why I don't seem to understand my modern physics class as much as my classical dynamics class. They are different in that the modern physics class is just an introductory class - things are often presented briefly, and I have to know a whole sleuth of equations that seemingly have no origin (I'm quite certain that most of the derivations would be too complicated for this level); in the classical dynamics class, there is a more in-depth perspective of things, with derivations and stuff, which makes it more interesting to understand.

My mind works on linking things together, and when new things are added, it always takes a while to chew over them. On the other hand, if it's just an improvement or generalization over something I learned previously, it's a lot easier to grasp.

And perhaps I should attend to my homework now.

the eccentric derivative

When I first studied ordinary, single-variable derivatives, they were relatively simple and the rules weren't so confusing. In fact, many of them belonged to the "common sense" group. Take, for example:
dy/dx = (dy/du)(du/dx)
If you treat "d(...)" as an operator and as a single entity, and manipulate derivatives as if they are actual fractions, then the chain rule appears to be "obvious".

I can't quite say the same thing for partial derivatives, however. Some partial derivative rules are just... strange:
dy/dx = -(∂z/∂x)/(∂z/∂y), if z(x, y) = 0.
The surprising part of this equation is the negative sign. While I can derive the equation itself without issues, it appears, at least to me, quite surprising that partial derivatives don't behave the way total derivatives do. Now I realize that the distinction is indeed necessary, and this difference in behavior and rules is one reason.

Take for example:
dy/dx = 1/(dx/dy)
This is always true, but it isn't true if I replaced it with partial derivatives. Instead, the inverse becomes a "sort-of" matrix inverse, and things are more complicated. Put simply, there is a way to invert partial derivatives, but the formula is far more complicated than what is shown above for total derivatives.

There is often a common trend in math: as things become more complicated, involving "higher-order" entities, some of the simple rules that originally applied would breakdown, replaced by more general, but complicated rules. One might call this unruly, but I would consider this "elegant" for most cases. E.g. Stoke's theorem is more complicated but far more general than the single-variable fundamental theorem of calculus.

It's time like these that remind me why I love math in the first place.