Archive for April, 2009

Math Club

My (regionally) high (they’re not high) AMC and AIME scores caught the attention of a group of students at Canadian Academy, where I took the tests. One of them contacted me a few weeks ago, and I’ve been joining them in their unofficial 3-hour meetings every Saturday since.

Actually, I will probably not be going anymore, as the Purple Comet! Math Meet contest was today, and it takes me nearly three hours just to get there and back. With summer break approaching, they are adjourning until next year.

But verily, what they did was great. Canadian Academy currently does not have an official math club, but they have been getting together every weekend, three hours at a time without an adult supervisor, for seven months. I think the persistence is admirable.

I put together a practice Purple Comet test for them last Saturday using problems from the AMCs and some that I made myself. Fortunately, they liked it. I’ve always wanted to help teach math in some way (and I respect and admire many, many AoPS users for doing just that). It’s a start. Maybe I’ll start my own club when I get back to the states?

Anyway, thanks for inviting me to join your club, guys!

Advertisements

Swimming Tips?

Pay attention to arms, hands, and fingertips. They lead. Try this with the butterfly.

Bending at the knees a little can help with propulsion and efficiency.

eh this is an old post that I obviously never finished but now that I am cleaning up, I don’t really want to delete. Posting anyway.

C++ Language Tutorial — Basics of C++: Structure of a Program

Initially, I looked at C++ Language Tutorial by Juan SouliƩ, but I found Thinking in C++ by Bruce Eckel recommended on the KDE development page, so I am going to read both.

At first glance, Eckel’s book looks like a really heavy read. If I may say so, it’s very… hard-core? Perhaps bleak? Okay, I may be biased toward pretty, colorful code blocks used in the C++ Language *Tutorial*, but really—Eckel’s first chapter is a slightly ominous, philosophical “Introduction to Objects.” The chapters are much more detailed than SouliĆ©’s tutorial (after all, it’s just that, a tutorial).

Hopefully, I’ll be able to pluck up some courage to read that chapter once I’ve learned a reasonable amount of syntax and structure. It seems like a great book, but it looks way too scary right now.

So getting started with the tutorial:

A basic C++ program as a model, copied from the site:

// my first program in C++

#include 
using namespace std;

int main () {
  cout << "Hello World!";
  return 0;
  }

All text after two slash signs (//) are comments. Block comments can be inserted between /* and */.

Lines beginning with a hash sign (#) are directives for the preprocessor. In this example, #include tells the preprocessor to include the iostream file, which is the basic input-output library in C++ (which defines cout).

“All the elements of the standard C++ library are declared within what is called a namespace… with the name std.” We call it with using namespace std, and it is frequently used in C++ programs that use the standard library.

int main () is the beginning of the definition of the main function, which is where all C++ programs start their execution. Other functions may be defined elsewhere and anywhere, but the main function will be executed first (thus is essential to every C++ program). The parentheses can optionally enclose a list of parameters. The body of the function is enclosed in a pair of braces.

A statement is an expression that can produce an effect. cout << "Hello World!"; outputs the string of characters Hello World! into the standard output (e.g., the screen). All expression statements are terminated by a semicolon.

The return statement in this example is followed by a return code of 0, which generally indicates a successful execution of the program. C++ console programs are usually ended in this way.

With the exception of lines of preprocessor directives (they are not statements), whitespace is insignificant. Semicolons are important.

Dive Into Python — Chapter 2. Your First Python Program

I’ve been working my tail off for the past two months to finish some schoolwork by a March deadline. It was my fault, but how I hate it! I still have a July deadline that is about to eat me, but you don’t care about that. :)

Because of the helpful distractions, I haven’t been able to do much else, including learning how to program (let alone doing the SPOJ exercises I promised myself to do). Now that I have a little more time, I am going to blog about what I learn from the various online textbooks on Python, C++, and Lisp that I am using. I am reading Dive Into Python by Mark Pilgrim.

Hopefully, this will force me to organize my thoughts more effectively and give me something to review later. So this is the first such entry.

Chapter 1 discusses installing Python on the various OSes… which, for me, was nothing harder than sudo aptitude install python on Ubuntu GNU/Linux.

2.1. Diving In

This first section gives a complete (short) Python program for me to chew on:

def buildConnectionString(params):
    """Build a connection string from a dictionary of parameters.

    Returns string."""
    return ";".join(["%s=%s" % (k, v) for k, v in params.items()])

if __name__ == "__main__":
    myParams = {"server":"mpilgrim", \
                "database":"master", \
                "uid":"sa", \
                "pwd":"secret" \
                }
    print buildConnectionString(myParams)

2.2. Declaring Functions

Functions are declared using def:

def functionName(arg1, arg2)

The example provided uses CamelCase. I think C uses the same convention, though Lisp uses hyphens.

All functions return a value (its datatype is unspecified), even if it’s None, Python’s null value. Variables as well are not explicitly typed. This is in contrast to C++ and other statically typed languages like Java.

2.3. Documenting Functions

The doc string is defined using triple quotes. The example given:

def buildConnectionString(params):
    """Build a connection string from a dictionary of parameters.

    Returns string."""

The doc string, if present, must be the first thing defined in a function, and it is an attribute of the function.

2.4. Everything Is an Object

A function is an object. We can import a chunk of code as a module with the import command and access its functions, classes, or attributes with module.function. From there we can call a function’s doc string with module.function.__doc__.

Import search paths are defined in sys.path, so we can import the sys module and append our own paths with sys.path.append('/my/new/path').

This [fact that everything is an object] is so important that I’m going to repeat it in case you missed it the first few times: everything in Python is an object. Strings are objects. Lists are objects. Functions are objects. Even modules are objects.

For now, I’ll just take his word for it.

2.5. Indenting Code

Code blocks are defined by their indentation. It does not matter how much they are indented as long as it is consistent. I think four spaces is the norm.

I don’t know why some people hate it. I love the absence of braces! Here is an example given in the book:

def fib(n):
    print 'n =', n
    if n > 1:
        return n * fib(n - 1)
    else:
        print 'end of the line'
        return 1

Braces are for computers, not for human eyes. This also forces people to organize their code (and in the same way), so reading others’ code isn’t a pain.

2.6. Testing Modules

This section is a tip on using the __name__ attribute to help test modules. If we import a module, __name__ is the module’s filename without the directory path or its file extension. However, if it is run as a standalone program, __name__ holds a special value of __main__.

Thus, we can use an if statement like

if __name__ == "__main__"

to design a test suite that will only run when the module is run as a standalone program and not as an imported module as part of a larger program. This can help with debugging.

Back Pain

I have had chronic back pain for almost ten years. It’s not severe, but lately it’s been bothering me so much that I can’t sit still for more than 10 minutes at a time. That, and a throbbing headache.

My mom took me to a doctor. After a two-hour wait and a few X-rays, he stretched my legs, tapped a few tendons, and pressed on some vertebrae to test for neurological problems or stress fractures. To my relief, he found none and explained that back pain was common among growing kids whose bones grow too fast for other organs to keep pace. The result is tight muscles and stretched nerves, both of which can cause pain.

I learned that my hamstring is too tight, which apparently is why my back curves forward so much when I sit; it’s actually normal! The doctor also explained that many swimmers suffer from back pain and told me to slow down. (My coach is currently pushing me hard to beat my record, which isn’t that great anyway.)

But when he pressed on my shoulders—OUCH. My headache is due to tight shoulders. I should stretch and rest up a bit. Maybe I should relax my head in the water when I swim.

Surprisingly, my back isn’t twisted like it used to be back in grade school. Whew. Anyway, no surgery for me. :)

Learning Common Lisp

Many online sources say that Lisp is a “programmable programming language.” Defining my own macros, being creative, and all that sounded a lot like the Art of Problem Solving spirit. So I decided to learn it. I’m reading Practical Common Lisp by Peter Seibel. The examples make things clear. I can’t say much else because I’m still a novice.

From “If programming languages were cars…”:

Lisp: looks like a car, but with enough tweaking you can turn it into a pretty effective airplane or submarine.

[from Paul Tanimoto:]

Lisp: At first it doesn’t seem to be a car at all, but now and then you spot a few people driving it around. After a point you decide to learn more about it and you realize it’s actually a car that can make more cars. You tell your friends, but they all laugh and say these cars look way too weird. You still keep one in your garage, hoping one day they will take over the streets.

And from Paul Graham, author of On Lisp, another ostensibly good book:

Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.

For good measure, other entries from “If programming languages were cars…”:

Python is a great beginner’s car; you can drive it without a license. Unless you want to drive really fast or on really treacherous terrain, you may never need another car.

C++ is a souped-up version of the C racing car with dozens of extra features that only breaks down every 250 miles, but when it does, nobody can figure out what went wrong.

I hope I’m getting somewhere with all this.