Ed's Big Plans

Computing for Science and Awesome

Archive for the ‘Waterloo’ tag

Midsemester Snapshot

with 2 comments

Since I’m heading into Reading Week, I’ve decided that this is a good time to take a moment to reflect on the semester. So far, it’s been very rewarding.

It’s fitting then that I should tell the story starting with the break before this semester. During that break, I spent a few days figuring out whether or not I was happy working on the symmetrical protein evolution problem at the University of Waterloo. As it turned out, my brain had become so trained into thinking like a computer scientist, there was actually an added cognitive tax in order to communicate well with my biology and biochemistry advisors and labmates. It was clear that I would better serve in a role elsewhere. The friends I made at Waterloo are the good ones — they are exactly as capable, willing to help and academically diverse as I need them to be. I’m happy to say that we’ll be picking each others’ brains for a long time. The evolution problem is a very interesting one, and I’ve promised my former advisors that I would help whoever they find to take my place, as that person would inherit a pile of my source code, data and in-house briefings.

I am here now — returned to the University of Guelph. The graduate programs at the two universities differ in many ways — the one most significant to my brain is when graduate courses are taken. At Waterloo, the culture has it that one works on their thesis primarily at all times and takes an occasional course to fulfill degree requirements. At Guelph, the culture has instead that one amortizes all of their courses in the first semester so that if the course materials are even ostensibly useful during thesis work, that knowledge would be mentally installed and available.

(Of course, the cultural differences are likely influenced by the different disciplines too.)

So this semester, I’m taking Computer Security, Artificial Neural Networks and Image Processing. Computer Security has been mostly to do with number theory. I’ve retrained myself in matrix multiplication and inversion while learning fast exponentiation, modulus power, modulus inverse, multiplicative and additive groups, the totient function, sieves, the extended Euclidean algorithm and much more I’m sure. I’m happy that I’m continuing to save my notes digitally in triplicate so that I’ll have a backup when my soft meat brain starts to forget. The number theory amounts to nice security devices such as RSA encryption. There’s another half semester to go, so whether it will be equally math intensive — or more application intensive built upon what we’ve already learned — remains to be seen. Artificial Neural Networks is a nice course for me — it rounds out my repertoire of architectures and training algorithms seeing as I had only worked with the feed forward, recurrent and recursive (back propagation) cases during my Master’s work. Image Processing has been a curious class. We’ve been through one round of presentations and are heading into learning the math behind a number of transforms applicable to image processing. This class is very firmly grounded in the symbolic maths and algebra — each adjective, each concept is meticulously and correctly described mathematically. Consider the precise meaning of continuity below as an optional property of fuzzy inverses.

x0[0, 1], ε ∈ ]0, +∞[, η ∈ ]0, +∞[, x ∈ [0,1], |x – x0| < η → |¬(x) – ¬(x0)| < ε

Assertion: No matter how small the difference is between two x’s, there will always exist a value for the difference of their negations.

There have been many items to memorize in this course — luckily, the above mathematical statement isn’t one of them :P

I’ve chosen a thesis topic as well. As it turns out, I’ll be working in machine learning — but this time on something of an expert decision support system that replaces the human proof-reader during nucleotide sequencing. If I do things correctly, the system I build will be able (1) to anticipate when it will make a mistake, (2) to anticipate how the human would react to that mistake and (3) to replace the erroneous token with the repaired token that a human expert would choose. I’ll have to go into more details as I discover them for myself — but it looks to be fun — you’ll notice that step (1) is probably recursively applicable to steps (2) and (3) — this device should know when it will make a mistake about a mistake — how this plays out in the decision states of my system remains to be discovered :D

Matt says...

Sounds like you have a pretty cool semester going on. Notational question: I take it you’re using ]a, b[ to represent the interval from a to b excluding a and b? I'm accustomed to using round brackets for that, such that [0, 2) would mean 0 to 2 including 0 but not 2.

[This is the part where I look check Wikipedia while writing a comment.] Oh, huh, it turns out that the square brackets thing IS an alternative notation, apparently used in Europe. Good to know.

Eddie Ma says...

Yes — parentheses ( … ) are overloaded and could indicate an ordered pair — in reality, I think that we can resolve everything by making all tuples including ordered pairs use angle brackets ⟨ … ⟩ and keeping parentheses to indicate non-inclusive ranges. This of course raises the issue of many many people not knowing how to type angle brackets without resorting to < … > — and the whole process of finding non-overloaded notation happens all over again — no no, let’s end it here before it begins and try to grab the meaning from context :P

Written by Eddie Ma

February 19th, 2011 at 10:21 pm

Python Crash Course – Lesson 1

without comments

The first lecture of my Python Crash Course went really well! I ran it two evenings ago in the Dean’s Conference Room.

In gearing the very first lecture for absolute beginners, I had very little to cater to BIC (Bioinformatics Club) members. I however took the opportunity to discuss with them about the SOLVER group (more on that later); many of which seemed interested.

Overall there were roughly a dozen people that turned out, including Ariana, my TA partner from last term. There were about four iGEM members and six BIC members.

I also took the opportunity to poll for the kinds of things that students wanted to learn. Here are my findings.

  • Object Orientation is something everyone wants to know– especially the people coming in with a Javascript, PERL, C, C++ and Scheme background; I was surprised that the C++ people didn’t get exposure to thinking in objects earlier.
  • The beginners came in two groups. First, there are the ones who are happy to learn anything as long as it can be applied later.
  • The second group of beginners want to data crunch PDBs, SDFs, FASTAs, Nucleotides etc.

In week two, we’ll take care of object orientation and in week three, we’ll take care of everything anyone ever needs to know about input output in order to do data crunching. I have added a link in the navigation of this blog for the Python Crash Courseware which will eventually include all the PDFs, code modules and examples used in class.

Oh right, I don’t know if I’ll get around to it– but I am missing instructions for setting environment variables in Windows. Perhaps I will add it later when I have time.

(iGEM attendees were John Heil, Danielle Nash, Tiffany and Lina; BIC members included Fiona, James and about four others whose names I have forgotten.)

Edit: Direct link to Python Crash Courseware; Direct link to Week 1: A Mad Mad Introduction, PDF.

Written by Eddie Ma

January 9th, 2010 at 9:00 pm