Ideas

Reflecting ON Reprofiling: FIRST try at Adult Teaching

For any other lecturers in the institution which I taught in, teaching adults is probably a usual thing that they need to do. For me, it was a totally new thing.

I am asked to train a small group on my colleagues to be able to do a bit of programming. It is part of the school’s initiative as well as a national drive to upgrade employees with digital skills. We called such upgrading training a reprofiling exercise.

What are the challenges that I thought I will face?

  • The course should be conducted with only 20% face-to-face time. 80% of the course should be curated and online.
  • My colleagues are also extremely busy people who many are possibly forced will struggle with time to take this course.
  • Of course, I never taught adults before. Yes, I always say that I treat my students as adults, the truth is some of the more controversial techniques that I use in teaching are meant for people without working experience.

Crisis

I like to see such challenges as a crisis. And I like to bring a Chinese perspective into this. This is because, the Chinese characters for the word “Crisis”, 危机, is made up of two very meaningful characters, danger and opportunity. I always feel that seeing opportunities in challenging moments is key to success.

Initial Strategy

What Matters Most

The 20% face-to-face times was extremely crucial to the success on whether my colleagues would be able to “get” programming. After all, programming had a bad name, urban myth knew it as a “you get it or you don’t” sort of subject.

Without the certainty of whether my colleagues are going to have the time to practice programming, I made all face-to-face sessions practice-oriented.

In the first session, we went through how to set up their learning and programming environment involving a couple of installation and creating a learning Lynda.com account.

I also just start programming right away, asking them to follow what I type, flashing out bits and pieces of programming knowledge along the way.

In essence, making sure that they leave the first session with an environment and knowledge of how they can start to programme, an extremely daunting task for first time programmers to learn on their own.

Motivation, Relevance and Just Enough

For all sessions, I start working on problems rather than explaining to them the concepts. This actually flips the way that I usually tackle my lessons, where I will explain concepts first, then tackle the problems.

The main reason was that I felt that there is no need for them to know every piece of concept. Important concepts will come naturally into our discussions when we worked through the problem. The rest can be considered a good to know.

The problems are also specially chosen among one of three themes to make programming more relevant to them:

  • Industry 4.0 (The participants are all engineer-trained)
  • Student result processing
  • Some Singapore-life related use cases (Eg. IPPT Score calculation)

Unlimited Self-evaluation Quizzes and Flexibility

I also crafted out a few self-evaluation quizzes for my colleagues which can be attempted unlimited times. Each answer they give comes with a personalised feedback on whether they are correct or where they might have gone wrong.

I may have given my usual students some bargaining power in terms of choosing their deadlines for assignment submission but to my colleagues, it was full flexibility so that they can work their study plans into their schedule. At the back, I was just encouraging them to submit before the study term begins, telling them that the consequence of submitting after is that they are going to feel more stress once their teaching load kicks in.

Andragogy

Sometimes I wish I had gone for the andragogy course organised by my institution earlier but hey, I’ve already did my best based on whatever I know and whatever ideas I can think of.

Understanding more about Andragogy now and reflecting on my first ever lesson delivery to adults, here are my takeaway points:

What worked really well: Learning Concepts from Problems

The idea of learning concepts along the way while working on a problem seems to work well with my colleagues. Once they have grasped the general concepts, the rest is all about searching for sample codes online to figure out how to do more advanced stuff.

Of course, there were also more stuff which I did, such as providing a set of mock questions and sample answers for the lab test. The lab test is also open book, rightfully so because that’s how most programmers do programming anyway, they code a bit, search for information on the Internet and then code some more.

What seemed lacking: Getting everyone to tap on each other’s knowledge

Robust discussions does not come naturally in my institution. With probably 400 over staff, it’s my 5th year with the institution but I still do not know everyone. One of the big thoughts is how best can I get everyone to talk and help out each other?

I’ve already set up the platform for them: there are both online and offline options for them to share their thoughts but there just seemed to be no incentive to do that, especially a good group of the class is possibly volunteered for the course rather than volunteers.

Or should some face-to-face time be devoted to pair work?

Then again, time is limited and I need them to be individually proficient for this fundamental course. However, I am glad that most of them isn’t too shy to approach me at all. The constant engagement and “love emails” I wrote to them paid off.

Man, it’s tough to change “deep-seated cultural issues” 😀 Asians are just really shy. I myself would probably bahave like that in a coding class too.

What could have been better: Getting them started

Part of what I did during the first session was that I got them started to install the required software on their laptops and start programming straight away, even if they don’t know a single thing about programming.

It didn’t work as well as I expected. I still find people who are not sure how to open what files to write codes and to run the codes. Others didn’t even successfully set up their laptops ready for development, even though I have packaged them nicely in zip files and gone through the steps in the face-to-face session.

I guessed I also assumed a lot about their technical capabilities to handle the computer and this is where my typical 18-year-old trumps them. For the next run, I’m going to write a step-by-step installation and coding guide. I probably want them to show me how they can write and run their programmes and they can be given a classroom participation score for this.

So, when do I start again?

Advertisements
Guide

Why Post-Increment has a higher precedence than Pre-Increment – An Empirical Explanation

This would be my very first technical post. I would like to give special thanks to my buddy, Joshua Na, for exploring this topic with me in details over Skype on a Friday afternoon! It seems that I didn’t get this right all along throughout my ten years of programming, not until now! I would also like to thank Sergey for pointing out a possible fundamental error in the first cut of my article. For now, I supposed this article is considered complete. Please feel free to discuss in the comments below.

The Empirical Approach

This article started off as an empirical approach, where I try out different codes and attempt to explain the output by spotting the pattern, which explains the title of this article. I’m not sure whether I got this right as I didn’t manage to look at the assembly.

Going beyond, there were many comments that flowed in regarding this and I read up a whole lot more, looking at many conflicting school of thoughts on this. I decided I should just try to understand it my own way based on whatever I have. Does it really matter to know the absolute truth? Or perhaps it’s better to know how to apply. 😛

What are pre-increments and post-increments operators?

In case you are not sure what those stuff are, in codes, they are the ++:

int x = 1;

//Pre increment - ++x
int y1 = ++x;

//Post increment - x++
int y2 = x++;

In a pre-increment (line 4), x will be incremented by one before y1 takes the value of (the new) x.

In a post-increment (line 7), y2 is going to take the value of x, after that, x gets incremented by one.

This looks very straight forward. It seems that in pre-increment, the ++ operator is evaluated first before the statement does while in post-increment, the statement gets evaluated first, before the post-increment operator.

The problem comes, when you try to refer to the Order of Precedence Table like this one:

Order of Precedence Table
Order of Precedence Table from http://en.cppreference.com/w/cpp/language/operator_precedence

 

Does Order of Precedence have anything to do with Order of Evaluation?

In many of the lectures that I sit through in the university, I remembered there seems to be such a table on order of precedence of operators shown to us when we talked about order of evaluation. Hence, if we were to follow the charts like the one above, and this is pretty much the same for Java, C++, C#, the post-increment is ranked higher than the pre-increment. This means that the post-increment is supposed to be evaluated first. To me, this doesn’t make any sense. In fact, I thought that the post-increment should be ranked all the way at the bottom as the increment only takes place after the statement is completed!

If you look through Stack Overflow and programming forums, you might find that quite a number of them will tell you that operator precedence has nothing to do with the order of evaluation. Well, that could be a reason for this strange phenomenon then. But that would have meant that those professors taught us the wrong stuff! What’s going on here?

Anyway, does the order of precedence have anything to do with the order of evaluation?

I would like to refer to some materials from two articles:

Order of precedence for operators defines how expressions are built from their source code representations.

From cppreference.com

Quoting from the example found in cppreference.com, the operator precedence will be able to tell us that f1() + f2() + f3() will be parsed as (f1() + f2()) + f3() due to the left-right associativity of the + operator. Note, this still does not explain which of the functions, f1, or f2 or f3, will get evaluated first.

The above example, or at least that’s how I like to interpret, says that operator precedence has no relationship with the order of evaluation.

The precedence and associativity of C operators affect the grouping and evaluation of operands in expressions. An operator’s precedence is meaningful only if other operators with higher or lower precedence are present. Expressions with higher-precedence operators are evaluated first.

From Precedence and Order of Evaluation, MSDN

The article from MSDN seems to suggest otherwise.

The Experiments

MSDN states that operator precedence is meaningful only if other operators with higher or lower precedence are present. This is perfectly understandable or otherwise, there will be nothing to compare with. Hence, for my experiments, I decided to put pre-increment and post-increment operators in an expression where the variable is used again in a single expression, something like this one:

i = ++i + i++;

I understand that from cppreference.com, said statements like the one above are considered undefined behaviours.

Nevertheless, I did try it, and the experiments produced deterministic results. In the next few paragraphs below, I would like to share my findings with you:

Experiment Group 1

Consider the following codes:

int x = 1;
int y = x++ + x;

The value of y is 3. The post-increment does not happen at the end of the statement (or at least that was how I thought I was taught in uni). What is happening here is this:

  1. x++ gets evaluated.
  2. The x in x++ (ie. the first x) retains the value of 1.
  3. The increment will take effect for the second x, making the value of the second x, 2.
  4. Hence, y = 1 + 2 = 3

The example above shows that x++ does not wait till the evaluation of the statement before the increment takes place. In fact, it probably got evaluated first, which is in coherence to the operator precedence table. All the post-increment operator was saying is that the original x attached to the post-increment operator will not be incremented.

I experimented with expressions that contain both x++ and ++x, and it seems that x++ will get computed first before ++x as per the chart.

Experiment Group 2

Consider the following codes:

int x = 1;
int y = x + x++;

Now that we know that the post-increment operator will get evaluated first, I expected that the value of y would be 3, going by the very same steps I listed above.

Actually, the answer is no! The value of this y is 2.

Let’s consider another set of codes:

int x = 1;
int y = x + x++ + x;

In the above codes, the value of y is 4. How does that happen? This is my theory:

  1. x++ gets evaluated.
  2. The x in x++ (ie. the second x) retains the value of 1.
  3. The increment will take effect for all x that exist to the right of x++, making the value of the third x, 2. The first x however, because it is on the left side of the equation, will not be incremented.
  4. Hence, y = 1 + 1 + 2 = 4

I tried out with many more examples, using all four pre and post increments and decrements operators. The results seems consistent with my thinking.

As to exactly why this is so, I’m not sure. It might have been something to do with the memory stack or the way codes are compiled that it seems impossible to apply the increments towards the left. Anyway, this is definitely cleaner if there are a lot of increments and decrements that are found within the same statement.

Results of the Experimentation

I think I will refuse to give an actual answer on whether operator precedence equates to evaluation precedence. I probably can’t answer that based on the conflict material that the Internet had to present.

 

 

BIG DISCLAIMER FIRST: The next statement would be a personal opinion on how I understand and how I would like to see this whole situation as. I would like to interpret these findings as a yes, the operator precedence does affect evaluation precedence. Even if not directly, then indirectly somehow.

 

And based on the results of my experimentations, it also appears that pre-increments and post-increments have very deterministic rules as well, at least on the two systems that I am using:

  1. Post-increments will be evaluated first. The variable with the post-increment operator will retain its value. The same variable found to the right in the very same expression will be incremented as well.
  2. Pre-increments will be evaluated next. The variable with the pre-increment operator will be incremented. The same variable found to the right in the very same expression will be incremented as well.
  3. When multiple post-increments or pre-increments are found in the same equation, evaluation will take place from the left to the right.
  4. And yes, there is probably nothing wrong with the Order of Precedence table. It just is what it is.

Final Words

I hope you find this article useful. If you have any feedback or any other views on how it should work, please leave me a comment. I would love to hear more from you. 🙂

However, especially for those who are more confused after reading all these, perhaps a better solution is for us to stop writing complicated codes. I’m sure we can achieve the same computation across several statements rather than mixing variables undergoing increments with the same variables in a single expression. Pretty sure it will not make any difference to the performance of the application. Let’s keep it simple shall we?