Tuesday, 24 July 2012
VAK Learning Styles: An Argument Against and For
I am not sure how many people have heard of the VAK Learning Styles. The general gist is that people have a preferred learning style: Visual, Auditory, or Kinaesthetic. In theory, when somebody learns they will do better in their preferred style they will do better than if they had used one of the other styles.
When I first read of this, I felt that there was something not quite right with this theory. My worry was with the concept of pareidolia, which is the psychological phenomenon that causes us to see human faces in pieces of burnt toast. From an evolutionary standpoint this is very important. There is a low cost to of seeing a pattern that is not there, for example, thinking you saw a sabre-tooth tiger in some nearby bushes. Compare this to the high cost of not seeing a sabre-tooth tiger that is in the bushes. Thus humans are excellent pattern matchers and I am presuming that this stems from excellent visual skills.
My analogy being that I might prefer walking to running but I will get to my destination sooner if I run.
Saturday, 14 July 2012
Getting Data From Flash Files with Transform SWF (Part 2)
When we left in Part 1 we had figured out how to get the statistics when both sides were non-zero. Since we have eliminated all avenues in DefineTextField and there is nothing suitable in TextSettings, we will begin to explore DefineMorphShape. I begin this by outputting DefineMorphShape.toString(), which gives a very long result. I do, however, notice a mention of a start colour. I check for red and blue:
This produces the following output:
- red -> fillStyles=[MorphSolidFill: { start=Color: { red=92; green=49; blue=13; alpha=255}
- blue -> fillStyles=[MorphSolidFill: { start=Color: { red=18; green=77; blue=127; alpha=255}
I will now intersperse 'red' and 'blue' into the output of the previous method
private static void printDefineTextFieldsAndDefineMorphShape(final List<movietag> objects) {
for(MovieTag object : objects){
if (object instanceof DefineTextField) {
DefineTextField d = (DefineTextField) object;
String initialText = removeHtmlTags(d.getInitialText());
if (Character.isDigit(initialText.charAt(0))){
System.out.print(initialText + " ");
} else {
System.out.print("\n" + initialText + " ");
}
}
if (object instanceof DefineMorphShape){
DefineMorphShape dms = (DefineMorphShape)object;
MorphSolidFill fill = (MorphSolidFill)dms.getFillStyles().get(0);
String colour = "unknown";
if (fill.getEndColor().getBlue() == 13){
colour = "red";
}
if (fill.getEndColor().getBlue() == 127){
colour = "blue";
}
System.out.print(colour + "-");
}
This produces the following output:
Friday, 13 July 2012
Getting Data From Flash Files with Transform SWF (Part 1)
The mission that I chose to accept was to get the above statistics from a .swf file. The coloured blocks represent percentage of the total i.e. the blue block in shots is 33% of max length because that team had 1/3 of all shots. As the title gives away, I will be using Transform SWF from Flagstone Software - this seemed like the best option from what I found by searching Google/Stack Overflow.
Transform SWF provides a small cookbook of examples using the software. The most relevant of these seemed to be find the number of frames in a movie. The example calls a movie's getObjects() method and checks for instances of Showframe. I modified this to call getClass() on each object and place the Class in a Set. Then I printed this out so that I could see which classes I needed to learn about.
private static void printDifferentTypesOfClasses(final List<movietag> objects) {
Set<Class> classes = new HashSet<>();
for(MovieTag movieTag : objects){
classes.add(movieTag.getClass());
}
for (Class c: classes){
System.out.println(c);
}
}
This provides the following output:
Tuesday, 10 July 2012
Informal Problem Solving
One thing I enjoy reading is when problems are solved by common sense rather then brute force. One example is from the Sabermetric Research Blog in a post titled 'Why 10 runs equals 1 win'. The point to realise is that an extra run are added at random. It may come up when down one in the bottom of the ninth but, equally, it may come when up six in the ninth.
The only time the extra run matters is when a team lost by one or went to extra innings.
When a team lost by one the extra run brings them to extra innings where they have a 50% chance of winning. Since 22.5% of games are decided by one run, 11.3% of the time the extra run goes to the team that lost and that converts to an a win 5.6 of the time - or 0.56 wins.
9% of games go to extra innings. If you add a run to one of those teams then they win the game - but they would have won half of them anyway. So the extra run matters 4.5% of the time and that converts to 0.45 wins.
0.56 wins + 0.45wins = 1.01 wins (Remember your denominonsense).
A more recent example that I have seen of good critical thinking is from the book 'Fifty Challenging Problems in Probability with Solutions' by Frederick Mosteller. In question 6, Chuck-a-Luck, he poses the following question:
How would you approach it?
The only time the extra run matters is when a team lost by one or went to extra innings.
When a team lost by one the extra run brings them to extra innings where they have a 50% chance of winning. Since 22.5% of games are decided by one run, 11.3% of the time the extra run goes to the team that lost and that converts to an a win 5.6 of the time - or 0.56 wins.
9% of games go to extra innings. If you add a run to one of those teams then they win the game - but they would have won half of them anyway. So the extra run matters 4.5% of the time and that converts to 0.45 wins.
0.56 wins + 0.45wins = 1.01 wins (Remember your denominonsense).
A more recent example that I have seen of good critical thinking is from the book 'Fifty Challenging Problems in Probability with Solutions' by Frederick Mosteller. In question 6, Chuck-a-Luck, he poses the following question:
How would you approach it?
Labels:
50Problems,
Math
Leading Zeros (Updated)
Earlier this year I was helping a student with a decimal problem where he was struggling with the idea of dropping a trailing zero. I mentioned that after any decimal you could write an infinite number of zeros without changing the meaning of the number. I then blurted out that you could also add an infinite amount of zeros before any number greater than one* without changing the meaning of that number. I am not sure I had ever thought of this before. I call this lazy knowledge: you don't actually know it but it is so obvious that you will figure it out as soon as you bother to think about it.
* Obviously this can be applied to numbers less than -1 as well.
This realisation stood to me recently when I was trying to figure out the number of times a digit would have appeared between 0 and n. My first step was to calculate how many digits there are in total between 0 and 99: 10 * 1 + 90 * 2 = 190. That would mean that each digit appears 19 times. When I calculated this for a specific digit though I realised that it should be twenty. Each number appears 10 times in the unit column and ten times in the tens column - for two that would be the ten numbers from 20-29. I had forgotten the leading 0. 0-9 should have been 00-99 - or if I was working with a three-digit number 000-009.
Once I made this observation a pattern began to emerge:
* Obviously this can be applied to numbers less than -1 as well.
This realisation stood to me recently when I was trying to figure out the number of times a digit would have appeared between 0 and n. My first step was to calculate how many digits there are in total between 0 and 99: 10 * 1 + 90 * 2 = 190. That would mean that each digit appears 19 times. When I calculated this for a specific digit though I realised that it should be twenty. Each number appears 10 times in the unit column and ten times in the tens column - for two that would be the ten numbers from 20-29. I had forgotten the leading 0. 0-9 should have been 00-99 - or if I was working with a three-digit number 000-009.
Once I made this observation a pattern began to emerge:
Monday, 9 July 2012
Eating Null Pointer Exceptions and Having The Unabomber
One common cause of a NullPointerException is calling the equals method on a string. For example,word.equals("word");If word is null, an exception is thrown. A clever trick to avoid this is to reverse the order of the comparison by calling the following: "word".equals(word);Since the string literal "word" is guaranteed to exist, you will not generate an exception. | Second time I have used this clip. |
Labels:
English,
Programming
Friday, 6 July 2012
Basketball Facts
Went to a table quiz last night and missed out by one point. We were outdone by the following question: What is 12 in London, 10 in New York, and 40 in Rome? Our first thought was clothing but one of our team members was adamant that a 10 in London would be a 6 in New York. She was right and wrong: dresses and suits have a difference of four but clothing only has a difference of two. We went with shoe size after my suggestion of bishops received no love.
Anyway, since the event was for a basketball team, I did some prep work* on basketball and learned a few interesting facts.
* My favourite prep work story is from a volleyball quiz where a friend had found out that USA was both Olympic and World Champions. When the quiz master announced that the next question was a volleyball question, he presumptuously wrote down the answer. The question? Who are the European Volleyball Champions.
Anyway, since the event was for a basketball team, I did some prep work* on basketball and learned a few interesting facts.
* My favourite prep work story is from a volleyball quiz where a friend had found out that USA was both Olympic and World Champions. When the quiz master announced that the next question was a volleyball question, he presumptuously wrote down the answer. The question? Who are the European Volleyball Champions.
Labels:
Misc
Subscribe to:
Posts (Atom)