Taste is one of the most interesting sensations, because there are so many different flavors and possibilities, which seem to stem from just four basic building blocks: sweet, sour, bitter, and salty. I find it amazing that such variety is possible simply with these four flavors in different amounts.
One common misconception about the tongue is that each flavor sensation is limited to a certain part of the tongue. To the contrary, the myth seems to have sprung up since the sensations are typically more powerful in those areas. Either the tongue sensors in those areas are more developed/sensitive, or there are simply more of them.
A great example of the complexity of flavor is champagne. While made mostly like wine, the primary difference is that many different wines are combined to make a more interesting flavor, and the yeast and and fermentation byproducts are removed, which makes the flavor sweeter. What is so fascinating about this is that there are teams of taste-testers dedicated to ensuring that the new batch of champagne has the exact same flavor as the old one. Why is this necessary? Each crop of grapes will naturally have ever-so-slight variances in flavor, and this is something only such world-class taste-testers would notice!
One pro tip for tasting anything liquid, particularly wine - smell it first with both your mouth and nose open. This imprints the scent and part of the taste (since smell is apparently 70% of the taste anyway) so that when you actually taste it, you get more out of it. In addition, while tasting it, swirl it around and savor it, rather than swallowing immediately. Keeping your nose open here helps as well. Most people tend to unconsciously close their nasal cavity when drinking - it's a reflex designed to prevent you from inhaling instead of imbibing. Just suppress the reflex long enough to get more out of the taste, but only before you swallow. When you swallow, this reflex is a very good thing!
I imagine these tips might also help for solid foods, but are probably not as effective, especially when it comes to drier foods like bread. Scent is transmitted via microscopic particles and/or vapors, and vapor is produced more readily by liquids, especially at higher temperatures. Higher temperature simply means more movement in the atoms and thus a greater chance of particles vaporizing.
Why then does a bakery smell so good, if dry foods don't produce as many particles? An increase in heat causes motion in the air. Heat wants to move and rise up, and this includes air from the oven. As the bread bakes, yeast in the bread produces gas, causing the dough to rise. Some of this gas will escape the bread, and since it is very hot, it will act just like any other hot gas and try to escape the oven, building up pressure if it cannot do so. When it does escape, wind will then carry this hot air, which then brings the smell of baking bread along with it.
Another fascinating mystery in the realm of taste is the compound known simply as miracle berry (literally, as the molecule causing the effect is known as miraculin). Apparently, it changes the flavor of oranges and other citrus fruits when eaten beforehand, making them sweet instead of sour. I've never tried it, but I imagine it would be quite interesting and stimulating. One also wonders at its effect on other foods!
Now, taste gets really interesting when you combine two flavors together, even if you are not experiencing them at the same time. The effect is much stronger in that case, however. For instance, if you take a bite of something, then after you've swallowed that, take a bite of something else, the taste from the first food is still imprinted in your memory. Some of the liquids or particles from that food may still be on your tongue, as well. Either way, upon tasting the second food, you experience both the flavor of the new food, the flavor of the first food, and most importantly, the difference between the flavors. This is what really makes things interesting, as you'll see more of in a minute.
In this case, you've experienced what I like to call a one-way flavor delta. Delta is the Greek character that looks like a triangle, and is used in mathematics to represent change or transition; more specifically, the amount of change. In this case, you have now tasted both flavors at the same time, though a lesser amount of one than the other. Due to this discrepancy (tasting less of the first flavor), this is only a one-way delta, meaning you experience the difference between the flavors in one direction. You taste more of the second flavor, so you can tell more about how that flavor differs from the first, but not vice versa. The first flavor is now all but gone, though for a brief moment both of the tastes were there. After a couple more bites of the second food, the first flavor is wiped out completely, and the taste of the second food becomes far less interesting.
Taste the foods in reverse, and you will understand why I call it a one-way flavor delta. The difference between food A and food B is not the same thing as the difference between food B and food A. You have to experience this personally to know what I'm talking about, but I'm certain that any good taste tester would agree with me here. The second flavor is always stronger (unless you try them both at once) and this creates a discrepancy in which your taste buds must tell you more about one flavor than they can about the other, causing this one-way difference.
When you have two different foods at the same time, that is when things get really magical. Not only are you now tasting flavor A and flavor B at the same time (in roughly equal amounts), but you are also tasting what I call a two-directional delta. You can now taste the complete difference between both flavors, and this is one of those cases where the sum of the parts is greater than the whole. That's why a sandwich tastes so much better than just eating the individual things one at a time, even though the parts are all the same. The average sandwich has (I would estimate) about 10 different flavors in it, so this means you are actually tasting ten flavors as well as C(10,2) two-way flavor deltas! That's an incredible combination of 55 flavors and flavor deltas at once. I bet you never knew that 5 plus 5 on a sandwich equals 55! (Heh, actually if you write '5' on the crust of both pieces of bread and look at it sideways like the spine of a book, 5 plus 5 DOES equal 55!)
For those mathematically-inclined folks, C(n,k) is a combination of n items taken k at a time; in this case we have 10 distinct flavors taken 2 at a time, giving us 45 flavor delta combinations (plus the ten individual flavors themselves for a total of 55). A combination is very similar to a permutation, except order does not matter, similar to a hand of cards, but unlike a race where the racers finish in a certain order.
Tuesday, August 14, 2012
Tuesday, August 7, 2012
Good Code
No one appreciates good coding, because only coders understand what coding is to begin with. For anyone else, if the thing works then you only did your job - that doesn't make you a good coder. Well, it does, but to anyone who doesn't understand it, computer code that works the first time is just normal, not great. If anything, it only reflects badly on the quality of the testing that was done.
On the other hand, bugs are high visibility and high priority, unlike coding. Only when it's broken do people seem entirely willing to acknowledge that code actually does exist. If you fix a lot of bugs in a few hours (despite it being far simpler than the actual coding, in most cases) then people understand that you've done a great deal of work. Coding nearly always goes unnoticed and unappreciated. If the code works fine, then it's just ignored, like it doesn't even exist.
On the other hand, bugs are high visibility and high priority, unlike coding. Only when it's broken do people seem entirely willing to acknowledge that code actually does exist. If you fix a lot of bugs in a few hours (despite it being far simpler than the actual coding, in most cases) then people understand that you've done a great deal of work. Coding nearly always goes unnoticed and unappreciated. If the code works fine, then it's just ignored, like it doesn't even exist.
To get some perspective, apply the same argument to writing in general. Writing software is in many respects very similar to writing prose or poetry. Programming languages have nearly the same semantics and syntax as spoken languages, it's just that their purposes are quite different.
Computers never use programming languages to communicate with us; it's only us communicating to them the instructions that we want performed, the order we want them performed in, and the logic that holds the rules together and the system in place.
With writing, absolutely no one expects you to get the first draft right. What makes you a great writer is being as good at revising (or better) than you are at writing.
The same applies to coding, only the underlying purpose gives the revisions a different purpose as well. In both cases, you are revising in order to make the written medium (words, code) better. Better writing is hard to define, since writing is a little more of an art form than computer programming. Better code, by contrast, is well defined - if it doesn't work, it's not good code. I will now go through some of the differences between good writing and good code, and how the writing systems themselves differ.
Prose writing is more about the context than the actual words, though being a good wordsmith certainly earns you extra points. The context is normally the story elements (plot) which includes character development, something that takes a good deal of time to do outside of the actual writing. The characters must be alive in your head and have their own motives, goals, aspirations, and personality, before you can plug them into the time frame and particular circumstances of your actual story and have it come out sounding realistic. In the case of non-fiction, the context is your particular topic or subject, and the structure of your argument or points. You remember this from high school English class: the first sentence of each paragraph should be the theme or thesis of that paragraph, followed by support, evidence, and further argument about that same point. The first paragraph is normally an introduction and the last is normally a conclusion, with at least three body paragraphs between them.
Poetry, on the other hand, is all about word selection, diction, and imagery. Poetic devices, such as rhyme, alliteration, meter, and various other tools, are of paramount importance. The actual message is usually only a result of the deeper themes and moods created by the specific words and their connotations. I find that rhyme is often a quite underestimated tool, not used as often as you might think in poetry. It can be used to emphasize - the words involved in the rhyme are usually the focal point of the entire phrase or sentence. Thus, it is also important to choose which words are going to rhyme, and as such, this often requires some grammatical flexibility to rearrange the parts of the sentence in a way that doesn't sound archaic or confusing.
Lastly, computer code is like neither. The entire purpose of computer code is logic - that is both its foundation and its end. The building blocks are simply logical constructs, such as a loop that executes a portion of the code over and over (to avoid having to write many instructions that do mostly the same thing). Most logic boils down to conditions - if this, do that, or if this other condition is true, do this other thing. If this condition is false, skip this part of the code. This logic tells computers how, when, and what to do, in a way that bears no interpretation (heh, at least not the kind you're probably thinking!) Here is where we get into the revision.
At this point, I'd like to mention one minor historical anecdote: the first computer bug actually was a bug! A moth had been electrocuted while chewing on some circuitry in one of the first mainframe (room-sized) computers, and was causing a short in the circuitry. What then constituted the 'software' was actually hardware, in the form of vacuum tubes and switches. The switches would be set to input the instructions, and the computer would run through whatever instructions had been set in these switches. A programmer's job back then would have been to manually go to each switch and move it to the right setting, according to a long (and probably quite boring) sheet of numbers. This bug probably took a while to find, as the chances of a programmer losing his focus and mis-setting even a single switch were quite high!
Revising computer code is simple, yet not straightforward. This is because most often, you don't know what specifically is wrong with the code and how the problem is being caused. If you had, you wouldn't have written the wrong code in the first place! The first step is called 'debugging' which means going through the code, one instruction at a time, and watching the computer perform it, then examining the current state of the computer and the resulting output at that point. Once the problem is seen, the instruction last executed is most likely to be the one causing the problem. Now that this is known, it is normally a simple matter to determine where the error in the logic lies, and rewrite the code accordingly. Therefore, until programmers can code perfectly, we are stuck with bugs for the time being.
Now, the existence of bugs is no reason to knock computers themselves! The great thing about computers is that they are seldom at fault for the problems we face. It is normally operator error, either on the programming side or the user side. If the programming is wrong, we call it buggy or glitchy. If the user is wrong, it is known as a PEBKAC (problem exists between keyboard and chair). Computers execute their instructions correctly 99.9 % of the time. Whether those instructions are right or wrong is a different matter. Readers more interested in the subject of computers writing their own instructions should have a look into aspect-oriented programming. It is the newest programming paradigm, a step up from object-oriented (warning for the non-techies: highly advanced technical terms may cause head to explode). See my other post for more information about the different programming paradigms.
Computers never use programming languages to communicate with us; it's only us communicating to them the instructions that we want performed, the order we want them performed in, and the logic that holds the rules together and the system in place.
With writing, absolutely no one expects you to get the first draft right. What makes you a great writer is being as good at revising (or better) than you are at writing.
The same applies to coding, only the underlying purpose gives the revisions a different purpose as well. In both cases, you are revising in order to make the written medium (words, code) better. Better writing is hard to define, since writing is a little more of an art form than computer programming. Better code, by contrast, is well defined - if it doesn't work, it's not good code. I will now go through some of the differences between good writing and good code, and how the writing systems themselves differ.
Prose writing is more about the context than the actual words, though being a good wordsmith certainly earns you extra points. The context is normally the story elements (plot) which includes character development, something that takes a good deal of time to do outside of the actual writing. The characters must be alive in your head and have their own motives, goals, aspirations, and personality, before you can plug them into the time frame and particular circumstances of your actual story and have it come out sounding realistic. In the case of non-fiction, the context is your particular topic or subject, and the structure of your argument or points. You remember this from high school English class: the first sentence of each paragraph should be the theme or thesis of that paragraph, followed by support, evidence, and further argument about that same point. The first paragraph is normally an introduction and the last is normally a conclusion, with at least three body paragraphs between them.
Poetry, on the other hand, is all about word selection, diction, and imagery. Poetic devices, such as rhyme, alliteration, meter, and various other tools, are of paramount importance. The actual message is usually only a result of the deeper themes and moods created by the specific words and their connotations. I find that rhyme is often a quite underestimated tool, not used as often as you might think in poetry. It can be used to emphasize - the words involved in the rhyme are usually the focal point of the entire phrase or sentence. Thus, it is also important to choose which words are going to rhyme, and as such, this often requires some grammatical flexibility to rearrange the parts of the sentence in a way that doesn't sound archaic or confusing.
Lastly, computer code is like neither. The entire purpose of computer code is logic - that is both its foundation and its end. The building blocks are simply logical constructs, such as a loop that executes a portion of the code over and over (to avoid having to write many instructions that do mostly the same thing). Most logic boils down to conditions - if this, do that, or if this other condition is true, do this other thing. If this condition is false, skip this part of the code. This logic tells computers how, when, and what to do, in a way that bears no interpretation (heh, at least not the kind you're probably thinking!) Here is where we get into the revision.
At this point, I'd like to mention one minor historical anecdote: the first computer bug actually was a bug! A moth had been electrocuted while chewing on some circuitry in one of the first mainframe (room-sized) computers, and was causing a short in the circuitry. What then constituted the 'software' was actually hardware, in the form of vacuum tubes and switches. The switches would be set to input the instructions, and the computer would run through whatever instructions had been set in these switches. A programmer's job back then would have been to manually go to each switch and move it to the right setting, according to a long (and probably quite boring) sheet of numbers. This bug probably took a while to find, as the chances of a programmer losing his focus and mis-setting even a single switch were quite high!
Revising computer code is simple, yet not straightforward. This is because most often, you don't know what specifically is wrong with the code and how the problem is being caused. If you had, you wouldn't have written the wrong code in the first place! The first step is called 'debugging' which means going through the code, one instruction at a time, and watching the computer perform it, then examining the current state of the computer and the resulting output at that point. Once the problem is seen, the instruction last executed is most likely to be the one causing the problem. Now that this is known, it is normally a simple matter to determine where the error in the logic lies, and rewrite the code accordingly. Therefore, until programmers can code perfectly, we are stuck with bugs for the time being.
Now, the existence of bugs is no reason to knock computers themselves! The great thing about computers is that they are seldom at fault for the problems we face. It is normally operator error, either on the programming side or the user side. If the programming is wrong, we call it buggy or glitchy. If the user is wrong, it is known as a PEBKAC (problem exists between keyboard and chair). Computers execute their instructions correctly 99.9 % of the time. Whether those instructions are right or wrong is a different matter. Readers more interested in the subject of computers writing their own instructions should have a look into aspect-oriented programming. It is the newest programming paradigm, a step up from object-oriented (warning for the non-techies: highly advanced technical terms may cause head to explode). See my other post for more information about the different programming paradigms.
Tuesday, July 31, 2012
Wanted: Schrodinger's Cat, Dead AND Alive
I've always been fascinated with the idea of Schrodinger's Cat. For those who don't know what that is, I'll elaborate:
Picture a cat. In a sealed box. A box with an odd-looking machine inside. This machine will randomly dispense poisonous gas, which would instantly kill the cat. Well, not quite randomly. There's a nifty little gadget called a Geiger counter hooked up to the gas chamber. A Geiger counter is a device that detects certain particles passing through it - particles so tiny or volatile they can pass through matter; X-rays, for instance. The idea is that when the box is opened, the cat will be either dead or alive.
However, the interesting bit is that before the box is opened, the cat is said to be both dead and alive. This is because, due to the random nature of the machine, we cannot determine for sure whether the cat is dead or alive without opening the box. But ah - whoops! If we open the box, we may well change the state of the cat, and therefore, still be none the wiser about whether the cat was actually dead or alive before we opened the box.
It can be likened to the Heisenberg Uncertainty Principle, one of the most interesting facets of modern physics and/or science in general. It states that no quantity can be fully measured to perfect accuracy - not only because we have no method of recording a measurement of infinite precision, but also because the act of measuring itself, on such a microscopic scale, changes the quantity being measured.
Insert random Heisenberg joke here:
Heisenberg is out for a drive and is going quite fast, when a cop pulls him over.
"Do you have any idea how fast you were going?" the cop asks him.
Heisenberg replies, "I might have, but blast you, you just had to go and measure it!"
Another conundrum that provides great food for thought is quantum physics. Without going into much detail, the idea is that small packets of matter (the smallest known, in fact) called quanta, are constantly going in and out of existence. This changing state is governed solely by probability, and the act of observing a quanta forces it to collapse into one of its probable states. In other words, until you look directly at something, it may or may not be where you think it is. It's probably reasonably close - but its exact shape and details of its existence (such as viscosity, temperature, and structure - things all determined by its atoms and hence, its subatomic quanta) are not set in stone until you actually observe it. When observed, each particle must collapse into one of the possible states, according to the probability of each.
This probability is identical to, say, rolling a six-sided die. Half of the time, the numbers 4 through 6 will be rolled. One third of the time, the numbers 1 or 2 would be rolled. Lastly, 3 is only rolled one sixth of the time. If these three outcomes have the same probability as the appearance of different states of a certain quantum particle, then one state will occur three times more often as the others - the state that appears half of the time (rolling 4, 5, or 6). The second state, rolling 1 or 2, occurs twice as often as the third state (rolling a 3). So each time you view this quantum particle, you've just rolled the six-sided die, and the particle you see (its location and properties) are determined by rules of probability, much like those discussed here.
Picture a cat. In a sealed box. A box with an odd-looking machine inside. This machine will randomly dispense poisonous gas, which would instantly kill the cat. Well, not quite randomly. There's a nifty little gadget called a Geiger counter hooked up to the gas chamber. A Geiger counter is a device that detects certain particles passing through it - particles so tiny or volatile they can pass through matter; X-rays, for instance. The idea is that when the box is opened, the cat will be either dead or alive.
However, the interesting bit is that before the box is opened, the cat is said to be both dead and alive. This is because, due to the random nature of the machine, we cannot determine for sure whether the cat is dead or alive without opening the box. But ah - whoops! If we open the box, we may well change the state of the cat, and therefore, still be none the wiser about whether the cat was actually dead or alive before we opened the box.
It can be likened to the Heisenberg Uncertainty Principle, one of the most interesting facets of modern physics and/or science in general. It states that no quantity can be fully measured to perfect accuracy - not only because we have no method of recording a measurement of infinite precision, but also because the act of measuring itself, on such a microscopic scale, changes the quantity being measured.
Insert random Heisenberg joke here:
Heisenberg is out for a drive and is going quite fast, when a cop pulls him over.
"Do you have any idea how fast you were going?" the cop asks him.
Heisenberg replies, "I might have, but blast you, you just had to go and measure it!"
Another conundrum that provides great food for thought is quantum physics. Without going into much detail, the idea is that small packets of matter (the smallest known, in fact) called quanta, are constantly going in and out of existence. This changing state is governed solely by probability, and the act of observing a quanta forces it to collapse into one of its probable states. In other words, until you look directly at something, it may or may not be where you think it is. It's probably reasonably close - but its exact shape and details of its existence (such as viscosity, temperature, and structure - things all determined by its atoms and hence, its subatomic quanta) are not set in stone until you actually observe it. When observed, each particle must collapse into one of the possible states, according to the probability of each.
This probability is identical to, say, rolling a six-sided die. Half of the time, the numbers 4 through 6 will be rolled. One third of the time, the numbers 1 or 2 would be rolled. Lastly, 3 is only rolled one sixth of the time. If these three outcomes have the same probability as the appearance of different states of a certain quantum particle, then one state will occur three times more often as the others - the state that appears half of the time (rolling 4, 5, or 6). The second state, rolling 1 or 2, occurs twice as often as the third state (rolling a 3). So each time you view this quantum particle, you've just rolled the six-sided die, and the particle you see (its location and properties) are determined by rules of probability, much like those discussed here.
Tuesday, July 24, 2012
Premeditated Toxicity
One of the most fascinating paradoxes I've ever come across is that of the poison gambit. For lack of a more standard name, I've chosen that one. Or, if you like, premeditated toxicity. Or perhaps better yet, "Who Wants To Die A Millionaire?"
It's a sort of contest. You will win a million dollars (or pounds or the currency of your choice) if you can simply intend to drink a toxic substance - a poison guaranteed to take your life. Note carefully the specific phrasing used - you don't have to actually drink it. You only have to intend to drink it. The contest might therefore involve some sort of waiver for legal purposes saying that you agree to drink the poison and that if you do, the host company cannot be held liable for the consequences of your own intent and actions based on that intent. The exact details of this are unimportant.
The paradox is, can you intend to drink the poison, collect the money, and then later change your mind and not drink it, thus living on and being able to enjoy your reward? It's a very interesting thought experiment into free will. I believe I've resolved the paradox.
The answer is this: NO. You cannot actually intend to drink the poison, then later, decide not to. If you did this, your intention to drink the poison to begin with would not be valid, and your winnings would be forfeit. On a positive note, you wouldn't have to drink the poison and could continue on happily with your life (one million dollars poorer, nevertheless). Assuming there was a lie detector or that the contest had some other way to verify your real intent, you would be completely unable to "cheat the system" and lie about your intent to drink the poison.
However! It is actually possible to intend to drink the poison, claim the reward, and later, not drink the poison and live on to celebrate it. Yes it is! And this does not contradict what I have said in the previous paragraph. There is a subtle difference. It's true you can't actually decide on your own to not drink the poison, later. To claim the reward, you have to truly intend to drink the poison, and with every fiber of your being, know that you are going to drink it and die from it. However, there are two ways to get out of it - one improbable, and one reliable but dependent on the rules of the contest.
First, the unlikely way: something unforeseen has to happen, something you could not have predicted and that you had no hope of stumbling into. This event must somehow change your mind about whether you wanted to drink the poison or not. For instance, perhaps after going through a divorce, you felt alone and became severely depressed. You thought you could at least give your kids a better future by providing well for them, though you wouldn't live to see it. Then, after the contest is over, but before you drink the poison, along comes a stunning, single woman into your life and you fall in love and are no longer depressed, and you actually don't want to die anymore. You find a reason to keep on living. This would not break the rules of the contest, and your finding love would be a triple bonus: you now have the promise of a happy relationship, a lot of money, and a bright future with no obligation to actually drink the poison. You were sincere in your intent, because you had no idea such a great event would happen to you and so drastically change your outlook on life.
The other method is the cheap shot. This may not be possible depending on the specific rules of the contest, but let's assume that you are not told the specific date on which you must actually drink the poison. When you intend to drink the poison, you must fully and completely agree to drink the poison at some point in your future, barring any event that kills you in another manner. In which case, the winnings would not be forfeit - remember, you only need to intend to drink the poison - the actual drinking is merely an extremely likely consequence of your intent to drink it.
Have you already spotted the loophole in your mind's eye? You can intend to drink the poison, claim your winnings, and then indefinitely postpone the actual drinking of it. You fully intend to drink it, but since the actual date was not specified, you simply intend on drinking it so near the end of your life that its fatal result means almost nothing. Then again, if you wait long enough, you may actually die unexpectedly before you even had a chance to drink the poison. Either way, you're practically scot free. The only real caveat is that you do have to truly intend to drink the poison at some later date!
This loophole makes an interesting question of intent - how do you define an intention? Is it immutable as first conceived in your mind, or are intentions a malleable substance that can be formed and shaped on a whim? Food for thought, or at least for another post.
It's a sort of contest. You will win a million dollars (or pounds or the currency of your choice) if you can simply intend to drink a toxic substance - a poison guaranteed to take your life. Note carefully the specific phrasing used - you don't have to actually drink it. You only have to intend to drink it. The contest might therefore involve some sort of waiver for legal purposes saying that you agree to drink the poison and that if you do, the host company cannot be held liable for the consequences of your own intent and actions based on that intent. The exact details of this are unimportant.
The paradox is, can you intend to drink the poison, collect the money, and then later change your mind and not drink it, thus living on and being able to enjoy your reward? It's a very interesting thought experiment into free will. I believe I've resolved the paradox.
The answer is this: NO. You cannot actually intend to drink the poison, then later, decide not to. If you did this, your intention to drink the poison to begin with would not be valid, and your winnings would be forfeit. On a positive note, you wouldn't have to drink the poison and could continue on happily with your life (one million dollars poorer, nevertheless). Assuming there was a lie detector or that the contest had some other way to verify your real intent, you would be completely unable to "cheat the system" and lie about your intent to drink the poison.
However! It is actually possible to intend to drink the poison, claim the reward, and later, not drink the poison and live on to celebrate it. Yes it is! And this does not contradict what I have said in the previous paragraph. There is a subtle difference. It's true you can't actually decide on your own to not drink the poison, later. To claim the reward, you have to truly intend to drink the poison, and with every fiber of your being, know that you are going to drink it and die from it. However, there are two ways to get out of it - one improbable, and one reliable but dependent on the rules of the contest.
First, the unlikely way: something unforeseen has to happen, something you could not have predicted and that you had no hope of stumbling into. This event must somehow change your mind about whether you wanted to drink the poison or not. For instance, perhaps after going through a divorce, you felt alone and became severely depressed. You thought you could at least give your kids a better future by providing well for them, though you wouldn't live to see it. Then, after the contest is over, but before you drink the poison, along comes a stunning, single woman into your life and you fall in love and are no longer depressed, and you actually don't want to die anymore. You find a reason to keep on living. This would not break the rules of the contest, and your finding love would be a triple bonus: you now have the promise of a happy relationship, a lot of money, and a bright future with no obligation to actually drink the poison. You were sincere in your intent, because you had no idea such a great event would happen to you and so drastically change your outlook on life.
The other method is the cheap shot. This may not be possible depending on the specific rules of the contest, but let's assume that you are not told the specific date on which you must actually drink the poison. When you intend to drink the poison, you must fully and completely agree to drink the poison at some point in your future, barring any event that kills you in another manner. In which case, the winnings would not be forfeit - remember, you only need to intend to drink the poison - the actual drinking is merely an extremely likely consequence of your intent to drink it.
Have you already spotted the loophole in your mind's eye? You can intend to drink the poison, claim your winnings, and then indefinitely postpone the actual drinking of it. You fully intend to drink it, but since the actual date was not specified, you simply intend on drinking it so near the end of your life that its fatal result means almost nothing. Then again, if you wait long enough, you may actually die unexpectedly before you even had a chance to drink the poison. Either way, you're practically scot free. The only real caveat is that you do have to truly intend to drink the poison at some later date!
This loophole makes an interesting question of intent - how do you define an intention? Is it immutable as first conceived in your mind, or are intentions a malleable substance that can be formed and shaped on a whim? Food for thought, or at least for another post.
Tuesday, July 17, 2012
There Was A Stink Here
A strange smell enters your nose. At first it seems pleasant, but at some point it hits you that the smell doesn't normally belong there. You then recognize that it's most likely an air freshener, and your brain supplies the needed context; namely, that there was a stink here. This knowledge makes the air freshener somewhat less effective, doesn't it? Moreover, I think that air fresheners are mostly ineffective, and I will gladly explain why.
All air fresheners smell pleasant, and yet most of the time when you smell them, the scent actually comes off as annoying, or at least less-than-pleasant. Why is this the case? Doesn't a pleasant smell always smell pleasant? In fact, no. The connotation that comes with the smell indicates that something else likely happened to make the air freshener necessary.
Moreover, when would you choose an air freshener over fresh air? Only on a summer's day when it's too hot to open the windows, or a winter's day when it's too cold to do the same. Depending on where you live, these may vary in frequency. Either way, there will be some days where the air freshener just smells out of place, even if it wasn't there to cover up a stench.
In many cases the air freshener cannot even completely cover the previous odor. This is arguably worse than not using any air freshener at all. The rank smell mingles with the more pleasant aroma, creating a confusing and irritating environment. So either the air freshener couldn't fully eliminate the other scent (and therefore, pointless), or the other scent was already gone, and the air freshener only serves as an ironic reminder of the incident (again, pointless). It's ironic because the pleasant smell hints at something unpleasant. In either case, we see that the use of the air freshener, at least as a remedy, was completely futile.
Also there is something to be said about the oils. If given a choice, I'd prefer fresh air over freshened-air any time. Most air fresheners use oils which either drift down to the floor, or float around. Either kind introduces particles into the environment (albeit, pleasant-smelling ones) that would not have been there otherwise - at least, certainly not in the quantity dispersed. This may even have some negative health effects, but I've not researched the subject. I simply know that when I inhale directly from a thick fog of such particles, the effect is not exactly stimulating, but rather, cough- and sneeze-inducing.
Don't get me wrong; I'm all for the use of air fresheners. However, I don't kid myself into thinking that they are effective. At the very least, all they do is kick your olfactory into gear and remind you that "there was a stink here."
All air fresheners smell pleasant, and yet most of the time when you smell them, the scent actually comes off as annoying, or at least less-than-pleasant. Why is this the case? Doesn't a pleasant smell always smell pleasant? In fact, no. The connotation that comes with the smell indicates that something else likely happened to make the air freshener necessary.
Moreover, when would you choose an air freshener over fresh air? Only on a summer's day when it's too hot to open the windows, or a winter's day when it's too cold to do the same. Depending on where you live, these may vary in frequency. Either way, there will be some days where the air freshener just smells out of place, even if it wasn't there to cover up a stench.
In many cases the air freshener cannot even completely cover the previous odor. This is arguably worse than not using any air freshener at all. The rank smell mingles with the more pleasant aroma, creating a confusing and irritating environment. So either the air freshener couldn't fully eliminate the other scent (and therefore, pointless), or the other scent was already gone, and the air freshener only serves as an ironic reminder of the incident (again, pointless). It's ironic because the pleasant smell hints at something unpleasant. In either case, we see that the use of the air freshener, at least as a remedy, was completely futile.
Also there is something to be said about the oils. If given a choice, I'd prefer fresh air over freshened-air any time. Most air fresheners use oils which either drift down to the floor, or float around. Either kind introduces particles into the environment (albeit, pleasant-smelling ones) that would not have been there otherwise - at least, certainly not in the quantity dispersed. This may even have some negative health effects, but I've not researched the subject. I simply know that when I inhale directly from a thick fog of such particles, the effect is not exactly stimulating, but rather, cough- and sneeze-inducing.
Don't get me wrong; I'm all for the use of air fresheners. However, I don't kid myself into thinking that they are effective. At the very least, all they do is kick your olfactory into gear and remind you that "there was a stink here."
Tuesday, July 10, 2012
Music For Nerds
In a similar vein as the "For Dummies" series, this post resides in the highly underdeveloped genre known as "For Nerds." The topic today is music! I am no expert at music, but I have my fair share of qualifications, particularly for someone who never majored in it, or otherwise, studied it intensely. I have played trumpet for over 10 years, piano for about 2 years, and dabbled in guitar until my cheapo First Act guitar broke (which wasn't very long). I also compose music, primarily solo piano and electronic. For those who are curious, I do my mixes in FL Studio Producer Edition (FL = FruityLoops), and my piano stuff in Finale. This was all self-taught during high school and college, but I've done little in that area since my career in software development officially began. As far as music theory, for seven out of eight of my college semesters, my roommate was a music education major. I absorbed no small amount of musical knowledge this way, second-hand.
Added to that, my own studies (going through all the lessons on musictheory.net in one night) provided a somewhat unstable basis for learning the actual theory. I compose primarily by ear, which may not be the best way, but it works for me. All that aside, I'd like to share some simple tricks for just about anyone. If you're a nerd like me, you will hopefully find these tricks a bit easier to remember than the old-school methods. The three tricks are how to quickly read a key signature, how to quickly read a time signature, and how to quickly read bass clef. A fourth tip is the simplest explanation I could muster for the idea of concert pitch, something that confused me to no end until recently.
Overview
Here is an overview of how to read music, what all the clef symbols and notes mean, and some of the other basic symbols on the notes.
Pitch and Clefs
Pitch is determined by the "height" of the note on the staff, and further, the staff's clef and location relative to other clefs. The higher the dot on the note, the higher the pitch. Don't look at the stems because they can point up or down, so that may be confusing (the stem is the line emerging from the dot).
For instance, on a piano score, you will see the treble clef, connected by a long vertical bar on the left side to the bass clef. The notes at the top of the treble clef are highest, and the notes at the bottom of the bass clef are lowest. The treble clef looks like a cursive letter S with a big dot at one end, but the important part is that the curl in the middle ends on the note line for G. The bass clef looks like a backwards C with two small dots to the upper right. The main shape also curls into a larger dot in the middle, a dot which would be the note F. Thus, these two clefs are often nicknamed G-clef and F-clef. Looking at their dots is one quick way to identify those particular notes.
The other clefs are actually even easier to read, because there is only one, and its position on the staff tells you where middle C is. It looks like a double thick bar on the left, with a curly bracket thing on the right (the entire thing looks like the letter B). The bracket has a sharp point going left, and this sharp point will always be on a line. That line is always middle C. Thus, this is the C-clef and is used mostly for vocal parts, except where hymns are concerned, since hymns normally have the same 4 voices (alto, tenor, baritone, and bass) and are written all on one page, using only the treble and bass clefs. When a single vocal part (say, for opera) is written on its own page, then the C clef is normally used to indicate which voice part it is.
Rhythm
The rhythm is largely determined by the type of dot in each note. The single 'beat' - the most basic unit in music - is normally the quarter-note, shown as a filled dot. Half notes and whole notes are unfilled dots. A half note is the one with the stem, and it gets two beats, while the whole note has no stem, and gets four beats. In common time or any time signature with a number 4 on the bottom, there are four beats in each measure. The small vertical lines in the staff divide the measures for easy reading.
If a note's stem has a tail on it, then it is an eighth note (if there is a tail, the dot will always be filled). A double tail indicates an even shorter note, the sixteenth. A triple tail indicates a thirdy-second note, and so on. Generally, the number used tells you what fraction of a measure the note represents, at least for common time. Thus, a thirty-second note is so fast, you could fit 32 of them into a single measure!
If two notes with a tail (eighths or shorter) are next to each other, the tails are connected, forming bars instead. Similarly, if four such notes are found together, all four tails are connected into one long bar. If the tails were double tails (for sixteenth notes) then there will be double bars instead.
A note with a smaller dot just to its right is a tricky one. You can think of this type of note or rhythm as working overtime - it gets time and a half! A dotted quarter note gets a quarter of the beat, plus half of that same value. Half of a quarter is an eighth, so a dotted quarter gets a quarter beat plus another eighth beat. It makes a lot more sense when you hear it, but the simplest way to think of it is two separate notes tied together. It sounds the same - a tie is the curvy line connecting two adjacent notes of the same pitch. Ties are normally used to connect notes across measures, since it's usually cleaner to combine them if they are in the same measure.
A slur is just a tie between notes of different pitches. This indicates that the second note isn't as distinct as the first, giving a blurred or slurred sound between them.
Finally, the accidentals - the things that make music look the most confusing! They are certainly the trickiest part since they occur when there is a modulation (when the notes or key at that spot don't match the overall key of the song). There are only three different symbols - one looking like a lowercase letter B, one that is the pound sign or hash (#) and a third that looks like a box with lines extending from two of its corners (almost like the hash with six of its 'arms' cut off). The first is the flat, causing the note to its right to go down one half-step. The second is the sharp, which does the opposite - the note it modifies goes up a half-step. Finally, the most strange looking one is the natural - it means the note is neither sharp nor flat, and assumes its normal pitch for that location in the staff. There are also double flats and double sharps, but I think that's getting a bit advanced for this post.
Quick Read Tips
Time Signature
Now, here is the quick-read tip for the time signature. In case you can't find the time signature, it is usually on the very left side of each staff, just to the right of the clef symbol. It is two small numbers, one on top of the other, both wedged inside the lines of the staff. Sometimes (if the time signature changes during the song) you may also see a time signature just before a double bar.
The top number tells you the length of each measure. If it says 4, there are four beats between each of the small vertical lines dividing the measures. If it says 8, there are eight beats instead. However, the beat is defined by the bottom number, which tells you what note is considered a single beat.
I still haven't gotten to the actual trick yet. I find that examples work best - let's say you want to understand how 3/4 time relates to 6/8 time. The two are actually very similar!
Think of it in terms of math (because that's what musical rhythm boils down to). Reduce fractions, and 6/8 actually equals 3/4. What does that tell you? The ratio between the measure length and the beat is the same! And what does that tell you? Well, for one, you can conduct 6/8 in much the same way as 3/4, waving your arms in a triangle-like shape. Second, you can tell that 6/8 is 3/4 times 2/2 which means everything is doubled. Where in 3/4 you only have three quarter-notes per measure, in 6/8 you have six eighth notes. Hey, that matches up - 3/4 = three quarter-notes, 6/8 = six eighth-notes. BAM! There's your trick. 2/4 equals two quarters (two quarter notes per measure). 9/4 equals nine quarter-notes.
Time signatures ARE fractions. Treating them like anything else only makes things confusing. Treat them like fractions, and everything will make sense from now on. But wait, that's math, not music! Oh, right - for nerds math is cool, so this actually works out better! Win.
Key Signature
Now, key signatures are a little more complicated, as you may know. Since there are twelve half-steps (distinct notes, including sharps and flats) in an octave, the combinations of which sharps and flats you have can become quite complex. One thing is on your side - except for accidentals, you will always have either all sharps or all flats. There is no key signature with both sharps and flats. The only "odd man out" is the key signature with neither sharps nor flats.
Another thing that adds to the complexity is that each key signature can be either major or minor, and it may not be obvious at a glance which one is being used. In addition to that, there are flat and sharp versions of each major and minor scale. This can all be tabulated and calculated quite easily by counting the number of sharp or flat symbols in the key signature, and then using the following chart:
0 2 4 -1 1 3 5
At first, these numbers probably seem like they could serve no useful purpose. The fact is, they already represent the seven natural keys! And the simplest part is they begin with C and proceed in alphabetical order. In music, nothing goes past G, so starting from zero you have:
C = 0
D = 2
E = 4
F = -1
G = 1
A = 3
B = 5
Now, what do the numbers mean? It's quite simple: positive numbers represent sharps, and negative numbers represent flats, while zero means no sharps or flats.
For example, if you see a key signature with two sharps, it's either D major, or the relative minor for that same key (which also has two sharps).
Determining the relative minor is just as easy! Add three. D is 2, so D major's relative minor is 2 plus 3 or 5, which is B. So the key signature with 2 sharps is either D major or B minor.
What about sharp and flat scales? G sharp (G#) major and A flat (Ab) minor and so forth? Amazingly, it gets easier yet! Simply subtract or add seven. Since flats are negative, you subtract seven to get the flat version of the key, and you add seven to get the sharp one. Ab is 3 minus 7, which is -4, so that key signature has four flats.
You can also calculate minor keys directly by subtracting three. For instance, what would C minor be? Take the value for C (zero) and subtract three. You get -3, which indicates that C minor has three flats.
Time for another example: suppose you want to look at G# major. Here, an exception occurs. We end up with 1 + 7 or 8 sharps. However, the key of G# is never used; it is purely theoretical. If a composer were to want that exact key, he or she would use the enharmonic equivalent key of Ab major instead, rather than using a double sharp and six sharps to indicate the proper eight-sharp key of G#.
In some cases you may have to add or subtract twice. For instance, what about A# minor? First, you add seven to the value of A (3) to give you A# major, which is 10. Then, you subtract three for the minor, which gives you 7. Thus, A# minor has seven sharps.
One last example: if you see three flats, well this isn't on the chart, is it? But you know one possibility - add three and you end up with zero, which is C. So the relative minor is C minor, which could be the key. Another way to get -3 is subtract 7 from 4, which is how you calculate Eb major. The key is thus either Eb major or C minor.
Credit for this system goes to musictheory.net, though it doesn't mention the detail that you can add three to get the relative minor.
Staves and Clefs
Lastly, understanding where all the notes are, independent of the clefs and staves, will greatly aid your ability to read different clefs. This section focuses only on the treble and bass clefs.
I'll assume that if you do know how to read music, you probably grew up playing a musical instrument. Unless you picked the baritone, tuba, or trombone, you are probably already familiar with the treble clef, and completely unfamiliar with the bass clef. Either way, the following should help you read the other clef a bit easier.
First, note that middle C is precisely and exactly that, when it comes to the treble and bass clefs. Treble-pitched instrument players will know that middle C resides on the first ledger line below the treble clef staff. Bass-pitched instrument players will know that middle C resides on the first ledger line above the bass clef staff. I bet both types were surprised to learn this about the other clef! In fact, let's say you situated the clefs together so that the lines match up (so the treble clef lines blend perfectly into the bass clef lines as you move downward, and vice versa). There would in this case be exactly one ledger line between both staves, with only one space in between on either side. Notes on this line would of course be middle C! How much simpler could it get?
One major helpful thing to note is that, for most notes, line notes in the treble clef become space notes in the bass clef, and vice versa. So the note G in the treble clef, a line note on the second-lowest line, becomes a space note in the bass clef, in the topmost space. Don't think about this too hard, as there are cases where it fails, but it's another handy thing to remember.
The major tip I can give you here is that the space notes (going from bottom to top) in the treble clef spell out the word FACE, and in the bass clef, they instead form the acronym ACEG (all cows eat grass). If you can just remember these two words (face = treble, bass = all cows eat grass) then you can use the space notes to go up and down and determine the other notes from there.
Tuning Systems
Concert Pitch
Concert pitch is the system in which most music is written today. Let's say I have a trumpet tuned to B flat and a cornet tuned to C. These tunings are also in concert pitch. The primary goal of this system is to prevent the difficulties that arise when the same note can have different fingerings depending on the key. With concert pitch, as long as you know the fingerings for each note, you don't have to worry what key you're in when reading the music (other than pressing all the right fingerings for that key and any accidentals).
If I am playing the same piece of music written in concert C, it will sound different depending on whether I play it on the trumpet or cornet. If I play it on the trumpet, I am actually playing in concert B flat. I wouldn't hear the difference if playing by myself, but if I played along with someone else who was playing a C cornet, it would sound quite awful indeed. So why doesn't a concert full of instruments all pitched differently sound terrible?
Relative Pitch
The trick here is all in the writing. Solo pieces can be written in relative pitch, meaning your only limitation is to write within that instrument's range. What you hear may not always be the right key, but it will sound good by itself because you have no other parts behind it for a reference. It is often written out of key (transposed) to put more of the notes within the staff and make it easier to read, but without a tuning fork or a highly trained ear, you wouldn't know that it's out of key. With no other instruments playing (no reference), all the pitches would still sound correct, relative to each other. Being out of key only makes the overall pitch of the song higher or lower than normal.
Transposing to Concert Pitch
By contrast, for ensembles and concert pieces, each part is normally written transposed to the right pitch for each instrument, using the concert pitch system. Thus, B flat trumpet parts are written in B flat concert, transposed with the key of the song. If the key is C, for instance, all notes must be transposed up a half-step. Now, by playing these transposed notes, a B flat tuned instrument is playing in C concert pitch. Likewise, for an F-tuned instrument, the notes would be transposed down five half-steps for a song written in concert C. If the key is concert B flat, then a trumpet B flat part would not need transposed at all. A notation such as "horn in F" would indicate that F is the concert pitch tuning for that instrument's part. Incidentally, F is also the standard concert pitch for horns, as is B flat for clarinets, and so forth.
Transposing Instruments
Some instruments, on the other hand, have such high or low ranges that their music always needs transposed simply to avoid having the notes so far away from the staff, requiring many ledger lines. Such instruments can be kept in the same key, but transposed up or down by one or more octaves. Examples of instruments that must always be transposed due to their range are the piccolo and the contrabassoon.
Besides extreme ranges, there are other reasons why instruments might be written transposed from concert pitch, but all such instruments written this way are known as transposing instruments. For these, concert pitch is not used as the standard. Instruments that use concert pitch are known as non-transposing instruments.
Transposed Reading
There are certain skilled individuals who can read and play music outside of concert pitch. This means they have to use a different fingering depending on which key the music is in, in order to match the correct concert pitch. If I want to play a part labeled "trumpet in B flat" but I want to actually play tuned to C concert, for instance, I would have to do the transposition myself as I am reading the music, playing each note a half-step higher than what is written. It would be far easier, however, just to obtain a "trumpet in C" part for that song!
Added to that, my own studies (going through all the lessons on musictheory.net in one night) provided a somewhat unstable basis for learning the actual theory. I compose primarily by ear, which may not be the best way, but it works for me. All that aside, I'd like to share some simple tricks for just about anyone. If you're a nerd like me, you will hopefully find these tricks a bit easier to remember than the old-school methods. The three tricks are how to quickly read a key signature, how to quickly read a time signature, and how to quickly read bass clef. A fourth tip is the simplest explanation I could muster for the idea of concert pitch, something that confused me to no end until recently.
Overview
Here is an overview of how to read music, what all the clef symbols and notes mean, and some of the other basic symbols on the notes.
Pitch and Clefs
Pitch is determined by the "height" of the note on the staff, and further, the staff's clef and location relative to other clefs. The higher the dot on the note, the higher the pitch. Don't look at the stems because they can point up or down, so that may be confusing (the stem is the line emerging from the dot).
For instance, on a piano score, you will see the treble clef, connected by a long vertical bar on the left side to the bass clef. The notes at the top of the treble clef are highest, and the notes at the bottom of the bass clef are lowest. The treble clef looks like a cursive letter S with a big dot at one end, but the important part is that the curl in the middle ends on the note line for G. The bass clef looks like a backwards C with two small dots to the upper right. The main shape also curls into a larger dot in the middle, a dot which would be the note F. Thus, these two clefs are often nicknamed G-clef and F-clef. Looking at their dots is one quick way to identify those particular notes.
The other clefs are actually even easier to read, because there is only one, and its position on the staff tells you where middle C is. It looks like a double thick bar on the left, with a curly bracket thing on the right (the entire thing looks like the letter B). The bracket has a sharp point going left, and this sharp point will always be on a line. That line is always middle C. Thus, this is the C-clef and is used mostly for vocal parts, except where hymns are concerned, since hymns normally have the same 4 voices (alto, tenor, baritone, and bass) and are written all on one page, using only the treble and bass clefs. When a single vocal part (say, for opera) is written on its own page, then the C clef is normally used to indicate which voice part it is.
Rhythm
The rhythm is largely determined by the type of dot in each note. The single 'beat' - the most basic unit in music - is normally the quarter-note, shown as a filled dot. Half notes and whole notes are unfilled dots. A half note is the one with the stem, and it gets two beats, while the whole note has no stem, and gets four beats. In common time or any time signature with a number 4 on the bottom, there are four beats in each measure. The small vertical lines in the staff divide the measures for easy reading.
If a note's stem has a tail on it, then it is an eighth note (if there is a tail, the dot will always be filled). A double tail indicates an even shorter note, the sixteenth. A triple tail indicates a thirdy-second note, and so on. Generally, the number used tells you what fraction of a measure the note represents, at least for common time. Thus, a thirty-second note is so fast, you could fit 32 of them into a single measure!
If two notes with a tail (eighths or shorter) are next to each other, the tails are connected, forming bars instead. Similarly, if four such notes are found together, all four tails are connected into one long bar. If the tails were double tails (for sixteenth notes) then there will be double bars instead.
A note with a smaller dot just to its right is a tricky one. You can think of this type of note or rhythm as working overtime - it gets time and a half! A dotted quarter note gets a quarter of the beat, plus half of that same value. Half of a quarter is an eighth, so a dotted quarter gets a quarter beat plus another eighth beat. It makes a lot more sense when you hear it, but the simplest way to think of it is two separate notes tied together. It sounds the same - a tie is the curvy line connecting two adjacent notes of the same pitch. Ties are normally used to connect notes across measures, since it's usually cleaner to combine them if they are in the same measure.
A slur is just a tie between notes of different pitches. This indicates that the second note isn't as distinct as the first, giving a blurred or slurred sound between them.
Finally, the accidentals - the things that make music look the most confusing! They are certainly the trickiest part since they occur when there is a modulation (when the notes or key at that spot don't match the overall key of the song). There are only three different symbols - one looking like a lowercase letter B, one that is the pound sign or hash (#) and a third that looks like a box with lines extending from two of its corners (almost like the hash with six of its 'arms' cut off). The first is the flat, causing the note to its right to go down one half-step. The second is the sharp, which does the opposite - the note it modifies goes up a half-step. Finally, the most strange looking one is the natural - it means the note is neither sharp nor flat, and assumes its normal pitch for that location in the staff. There are also double flats and double sharps, but I think that's getting a bit advanced for this post.
Quick Read Tips
Time Signature
Now, here is the quick-read tip for the time signature. In case you can't find the time signature, it is usually on the very left side of each staff, just to the right of the clef symbol. It is two small numbers, one on top of the other, both wedged inside the lines of the staff. Sometimes (if the time signature changes during the song) you may also see a time signature just before a double bar.
The top number tells you the length of each measure. If it says 4, there are four beats between each of the small vertical lines dividing the measures. If it says 8, there are eight beats instead. However, the beat is defined by the bottom number, which tells you what note is considered a single beat.
I still haven't gotten to the actual trick yet. I find that examples work best - let's say you want to understand how 3/4 time relates to 6/8 time. The two are actually very similar!
Think of it in terms of math (because that's what musical rhythm boils down to). Reduce fractions, and 6/8 actually equals 3/4. What does that tell you? The ratio between the measure length and the beat is the same! And what does that tell you? Well, for one, you can conduct 6/8 in much the same way as 3/4, waving your arms in a triangle-like shape. Second, you can tell that 6/8 is 3/4 times 2/2 which means everything is doubled. Where in 3/4 you only have three quarter-notes per measure, in 6/8 you have six eighth notes. Hey, that matches up - 3/4 = three quarter-notes, 6/8 = six eighth-notes. BAM! There's your trick. 2/4 equals two quarters (two quarter notes per measure). 9/4 equals nine quarter-notes.
Time signatures ARE fractions. Treating them like anything else only makes things confusing. Treat them like fractions, and everything will make sense from now on. But wait, that's math, not music! Oh, right - for nerds math is cool, so this actually works out better! Win.
Key Signature
Now, key signatures are a little more complicated, as you may know. Since there are twelve half-steps (distinct notes, including sharps and flats) in an octave, the combinations of which sharps and flats you have can become quite complex. One thing is on your side - except for accidentals, you will always have either all sharps or all flats. There is no key signature with both sharps and flats. The only "odd man out" is the key signature with neither sharps nor flats.
Another thing that adds to the complexity is that each key signature can be either major or minor, and it may not be obvious at a glance which one is being used. In addition to that, there are flat and sharp versions of each major and minor scale. This can all be tabulated and calculated quite easily by counting the number of sharp or flat symbols in the key signature, and then using the following chart:
0 2 4 -1 1 3 5
At first, these numbers probably seem like they could serve no useful purpose. The fact is, they already represent the seven natural keys! And the simplest part is they begin with C and proceed in alphabetical order. In music, nothing goes past G, so starting from zero you have:
C = 0
D = 2
E = 4
F = -1
G = 1
A = 3
B = 5
Now, what do the numbers mean? It's quite simple: positive numbers represent sharps, and negative numbers represent flats, while zero means no sharps or flats.
For example, if you see a key signature with two sharps, it's either D major, or the relative minor for that same key (which also has two sharps).
Determining the relative minor is just as easy! Add three. D is 2, so D major's relative minor is 2 plus 3 or 5, which is B. So the key signature with 2 sharps is either D major or B minor.
What about sharp and flat scales? G sharp (G#) major and A flat (Ab) minor and so forth? Amazingly, it gets easier yet! Simply subtract or add seven. Since flats are negative, you subtract seven to get the flat version of the key, and you add seven to get the sharp one. Ab is 3 minus 7, which is -4, so that key signature has four flats.
You can also calculate minor keys directly by subtracting three. For instance, what would C minor be? Take the value for C (zero) and subtract three. You get -3, which indicates that C minor has three flats.
Time for another example: suppose you want to look at G# major. Here, an exception occurs. We end up with 1 + 7 or 8 sharps. However, the key of G# is never used; it is purely theoretical. If a composer were to want that exact key, he or she would use the enharmonic equivalent key of Ab major instead, rather than using a double sharp and six sharps to indicate the proper eight-sharp key of G#.
In some cases you may have to add or subtract twice. For instance, what about A# minor? First, you add seven to the value of A (3) to give you A# major, which is 10. Then, you subtract three for the minor, which gives you 7. Thus, A# minor has seven sharps.
One last example: if you see three flats, well this isn't on the chart, is it? But you know one possibility - add three and you end up with zero, which is C. So the relative minor is C minor, which could be the key. Another way to get -3 is subtract 7 from 4, which is how you calculate Eb major. The key is thus either Eb major or C minor.
Credit for this system goes to musictheory.net, though it doesn't mention the detail that you can add three to get the relative minor.
Staves and Clefs
Lastly, understanding where all the notes are, independent of the clefs and staves, will greatly aid your ability to read different clefs. This section focuses only on the treble and bass clefs.
I'll assume that if you do know how to read music, you probably grew up playing a musical instrument. Unless you picked the baritone, tuba, or trombone, you are probably already familiar with the treble clef, and completely unfamiliar with the bass clef. Either way, the following should help you read the other clef a bit easier.
First, note that middle C is precisely and exactly that, when it comes to the treble and bass clefs. Treble-pitched instrument players will know that middle C resides on the first ledger line below the treble clef staff. Bass-pitched instrument players will know that middle C resides on the first ledger line above the bass clef staff. I bet both types were surprised to learn this about the other clef! In fact, let's say you situated the clefs together so that the lines match up (so the treble clef lines blend perfectly into the bass clef lines as you move downward, and vice versa). There would in this case be exactly one ledger line between both staves, with only one space in between on either side. Notes on this line would of course be middle C! How much simpler could it get?
One major helpful thing to note is that, for most notes, line notes in the treble clef become space notes in the bass clef, and vice versa. So the note G in the treble clef, a line note on the second-lowest line, becomes a space note in the bass clef, in the topmost space. Don't think about this too hard, as there are cases where it fails, but it's another handy thing to remember.
The major tip I can give you here is that the space notes (going from bottom to top) in the treble clef spell out the word FACE, and in the bass clef, they instead form the acronym ACEG (all cows eat grass). If you can just remember these two words (face = treble, bass = all cows eat grass) then you can use the space notes to go up and down and determine the other notes from there.
Tuning Systems
Concert Pitch
Concert pitch is the system in which most music is written today. Let's say I have a trumpet tuned to B flat and a cornet tuned to C. These tunings are also in concert pitch. The primary goal of this system is to prevent the difficulties that arise when the same note can have different fingerings depending on the key. With concert pitch, as long as you know the fingerings for each note, you don't have to worry what key you're in when reading the music (other than pressing all the right fingerings for that key and any accidentals).
If I am playing the same piece of music written in concert C, it will sound different depending on whether I play it on the trumpet or cornet. If I play it on the trumpet, I am actually playing in concert B flat. I wouldn't hear the difference if playing by myself, but if I played along with someone else who was playing a C cornet, it would sound quite awful indeed. So why doesn't a concert full of instruments all pitched differently sound terrible?
Relative Pitch
The trick here is all in the writing. Solo pieces can be written in relative pitch, meaning your only limitation is to write within that instrument's range. What you hear may not always be the right key, but it will sound good by itself because you have no other parts behind it for a reference. It is often written out of key (transposed) to put more of the notes within the staff and make it easier to read, but without a tuning fork or a highly trained ear, you wouldn't know that it's out of key. With no other instruments playing (no reference), all the pitches would still sound correct, relative to each other. Being out of key only makes the overall pitch of the song higher or lower than normal.
Transposing to Concert Pitch
By contrast, for ensembles and concert pieces, each part is normally written transposed to the right pitch for each instrument, using the concert pitch system. Thus, B flat trumpet parts are written in B flat concert, transposed with the key of the song. If the key is C, for instance, all notes must be transposed up a half-step. Now, by playing these transposed notes, a B flat tuned instrument is playing in C concert pitch. Likewise, for an F-tuned instrument, the notes would be transposed down five half-steps for a song written in concert C. If the key is concert B flat, then a trumpet B flat part would not need transposed at all. A notation such as "horn in F" would indicate that F is the concert pitch tuning for that instrument's part. Incidentally, F is also the standard concert pitch for horns, as is B flat for clarinets, and so forth.
Transposing Instruments
Some instruments, on the other hand, have such high or low ranges that their music always needs transposed simply to avoid having the notes so far away from the staff, requiring many ledger lines. Such instruments can be kept in the same key, but transposed up or down by one or more octaves. Examples of instruments that must always be transposed due to their range are the piccolo and the contrabassoon.
Besides extreme ranges, there are other reasons why instruments might be written transposed from concert pitch, but all such instruments written this way are known as transposing instruments. For these, concert pitch is not used as the standard. Instruments that use concert pitch are known as non-transposing instruments.
Transposed Reading
There are certain skilled individuals who can read and play music outside of concert pitch. This means they have to use a different fingering depending on which key the music is in, in order to match the correct concert pitch. If I want to play a part labeled "trumpet in B flat" but I want to actually play tuned to C concert, for instance, I would have to do the transposition myself as I am reading the music, playing each note a half-step higher than what is written. It would be far easier, however, just to obtain a "trumpet in C" part for that song!
Tuesday, July 3, 2012
Will Program For Twenty Cents
The subject of this post is actually programming, and another word after it which makes the post title a geeky pun. Bonus points for those who can figure it out! (Hint: You won't find the word anywhere in this post. I took extra effort not to use it).
From the first time I looked at computer code, I was fascinated by it. Ironically, during elementary school, I didn't think I'd ever be smart enough to program computers. This may have been because I wasn't smart enough at that point - the only intellectual limit of childhood seems to be one's inability to think farther than a week ahead. Better understanding your own potential for growth is part of maturing into an adult, I have found.
When personal computers first became available, their use was not widespread. Rather, the internet was simply a network of the major computers that existed at that time, and primarily between research facilities. Programming at that time would have been a headache compared to what it is today. Since binary (or more generally, anything digital) is nearly the opposite of how the human brain works (everything is analog), computer instructions then were written in hexadecimal, a number system on the other end of the scale from binary. Binary uses two digits; hexadecimal uses sixteen. In comparison, the number system we write with uses ten digits, and is simply called decimal.
Even in hexadecimal, computer code is all just numbers, but in a form more easily usable by humans. This is because, due to having eight times more digits than binary, a very long number in binary becomes a very short number in hexadecimal, meaning a lot more code can be shown with very few digits. This was the first form of software programming; hardware programming previously used switches that had to be set by hand.
Next came spaghetti code. The mental picture is fairly accurate - instructions just thrown in wherever they were deemed necessary. There was no real structure or organization at all. Each instruction was directly mapped to an address; the address was actually part of the programming code. The addresses had to be in order, but you could skip ones you didn't need, or decided not to use. You can see how it got its name with this kind of ad-hoc arrangement! However, the one improvement was that actual words could be used instead of codes. This introduced the need for another program, called a compiler, to come along after you write the code and turn the words into the hexadecimal and/or binary instructions that the computer can execute.
The first real structure came with the invention of - you guessed it - 'structured' code. The new idea here was to cut up the spaghetti into logical segments. Each segment, also known as a 'routine' or 'subroutine' was given a name, usually one that described what that portion of the instructions did. For instance, you might have a routine to display text on the screen, and another one to ask the user for input. In this way, instructions were organized by function, rather than being all thrown together in one big monolithic mess. In addition, this introduced the idea of parameters. In the case of a routine that displayed text on the screen, a parameter could be the text to be displayed. Whenever you invoke or call the routine (so that it performs the instructions contained therein) these parameters are given. This way, you need not reinvent the wheel and write the same code over and over each time you want to display text on the screen. You just call the routine that does it for you, and pass the text you want displayed as a parameter. This is also known as functional or procedural programming, because it is organized by function (routines are also known as functions or procedures).
This phase lasted quite a while until the next revolution: object-oriented programming. This provided not only further structure, but also several important, new concepts that would change the way programming was thought of, and what it was capable of doing. These powerful new tools created quite a stir and made computer code far more elegant and interesting. The three primary concepts are: encapsulation, inheritance, and polymorphism. All three fall under the umbrella term "abstraction" since they all give us new ways to represent abstract ideas (or objects) such as bank accounts, transactions, and other such things managed by computers, using computer code. This means the code is structured in a way that more accurately represents these objects, and therefore, more accurately handles and manages them.
Encapsulation is the idea of the black box. Think of a car engine, for instance. Many people haven't the foggiest notion of how a combustion engine works (perhaps a better example is how an airplane stays up in the air, since even fewer seem to understand that secret). However, that isn't a very big problem, unless of course, your car breaks down (or the airplane crashes). As you drive the car, it doesn't (and shouldn't) concern you what happens when you press the gas pedal, or the brakes. When you turn the steering wheel, you don't care how the engine responds and decides which way to turn the car. It doesn't matter to you, because it's a black box system. As long as it does its job, the black box can remain a mystery, and there is absolutely no problem with that.
We can do precisely this same thing with computer software. We can now write a portion of code that can interact in a well-defined way (known as an API) with other code. We can bundle up the code we wrote, sell it to someone else, and then they can write code on top of it that turns the steering wheel and pushes the pedals, so to speak. They don't care how our code works; it just works. When they turn the steering wheel, the car turns, and when they push the gas pedal, the car moves forward.
Encapsulation is accomplished in the software world by defining the scope of program elements. The scope tells us where in the program (and outside) we can see those elements. Functions, as mentioned earlier, are one such element. Stored data is the other primary element. We can define something as public (viewable by everyone, everywhere) or private (viewable only within the black box). This allows us to share the information we want, and protect the information that shouldn't be shared within the black box.
Inheritance is a lot simpler; you are already familiar with one form of it - genetics. In programming, inheritance works exactly the same way. We can write generic code that acts like an Animal - it has behaviors (defined by functions) such as speak, play, sleep, and so on. Then, we can write more specific code that acts like a Dog, but inherits the more generic aspects that it shares with all Animals. All animals can speak, but when a Dog speaks, the behavior can be defined specifically as "Bark." We could then write a Cat which inherits this same behavior (speaking) but again, when we invoke the Cat's 'speak' function, instead we receive a "Meow" in response.
Finally, polymorphism is the most complex of the three. It's quite a difficult concept to wrap your mind around, even if you're a programmer. However, the simplest way to explain it was already done in the last paragraph. It is closely related to inheritance. When a Cat speaks and we hear a "Meow" then a Dog speaks and we hear a "Bark," this is an example of polymorphism. In either case, we are simply invoking the inherited "speak" function - but the behavior is different depending on the subclass (Cat or Dog). This is polymorphism - the ability to define a specific response to a generic behavior.
In essence, these abstractions give us two dimensions in which to program. With structured design, a function always does the same thing every time you call it. With object-oriented design, polymorphism gives us a different response based on both the function/behavior and the object/idea. Invoking the same function on a different object normally produces different results.
Now, prepare your mind for some extreme warping - we are now in the age of subject-oriented programming, where we can wield three such dimensions. The result or response we get from a function can now be defined by the name of the function, the object on which it is invoked, and the subject related to the invocation. For instance, my Dog might have a different bark depending on whether he was happy to see me, or whether he was trying to fend off an intruder. This constitutes the subject, or aspect, in which the behavior is invoked.
Aspect-oriented programming is very similar to subject-oriented, but to spare your mind further warpage, I won't go into any detail on the differences between the two. Instead, I will just say that programming has come a long way from using hexadecimal codes and command line interfaces. We now have the power to determine the software's behavior based on the desired function, the object performing the action, and the context in which the interaction occurs. This gives incredible potential even just for artificial intelligence. Computer code that can update and edit itself is now just around the corner.
And yet, DNA has been doing exactly that for thousands of years. Is that something that occurred by random chance? I think it's about as likely as computers assembling and programming themselves out of thin air. It takes a mind more intelligent than a computer to design and build a computer. By the same token, it takes a mind more intelligent than a human mind to create such an incomprehensibly vast universe, and to populate it with beings whose bodies themselves contain technology far more advanced than computers; least of all, the human mind itself.
From the first time I looked at computer code, I was fascinated by it. Ironically, during elementary school, I didn't think I'd ever be smart enough to program computers. This may have been because I wasn't smart enough at that point - the only intellectual limit of childhood seems to be one's inability to think farther than a week ahead. Better understanding your own potential for growth is part of maturing into an adult, I have found.
When personal computers first became available, their use was not widespread. Rather, the internet was simply a network of the major computers that existed at that time, and primarily between research facilities. Programming at that time would have been a headache compared to what it is today. Since binary (or more generally, anything digital) is nearly the opposite of how the human brain works (everything is analog), computer instructions then were written in hexadecimal, a number system on the other end of the scale from binary. Binary uses two digits; hexadecimal uses sixteen. In comparison, the number system we write with uses ten digits, and is simply called decimal.
Even in hexadecimal, computer code is all just numbers, but in a form more easily usable by humans. This is because, due to having eight times more digits than binary, a very long number in binary becomes a very short number in hexadecimal, meaning a lot more code can be shown with very few digits. This was the first form of software programming; hardware programming previously used switches that had to be set by hand.
Next came spaghetti code. The mental picture is fairly accurate - instructions just thrown in wherever they were deemed necessary. There was no real structure or organization at all. Each instruction was directly mapped to an address; the address was actually part of the programming code. The addresses had to be in order, but you could skip ones you didn't need, or decided not to use. You can see how it got its name with this kind of ad-hoc arrangement! However, the one improvement was that actual words could be used instead of codes. This introduced the need for another program, called a compiler, to come along after you write the code and turn the words into the hexadecimal and/or binary instructions that the computer can execute.
The first real structure came with the invention of - you guessed it - 'structured' code. The new idea here was to cut up the spaghetti into logical segments. Each segment, also known as a 'routine' or 'subroutine' was given a name, usually one that described what that portion of the instructions did. For instance, you might have a routine to display text on the screen, and another one to ask the user for input. In this way, instructions were organized by function, rather than being all thrown together in one big monolithic mess. In addition, this introduced the idea of parameters. In the case of a routine that displayed text on the screen, a parameter could be the text to be displayed. Whenever you invoke or call the routine (so that it performs the instructions contained therein) these parameters are given. This way, you need not reinvent the wheel and write the same code over and over each time you want to display text on the screen. You just call the routine that does it for you, and pass the text you want displayed as a parameter. This is also known as functional or procedural programming, because it is organized by function (routines are also known as functions or procedures).
This phase lasted quite a while until the next revolution: object-oriented programming. This provided not only further structure, but also several important, new concepts that would change the way programming was thought of, and what it was capable of doing. These powerful new tools created quite a stir and made computer code far more elegant and interesting. The three primary concepts are: encapsulation, inheritance, and polymorphism. All three fall under the umbrella term "abstraction" since they all give us new ways to represent abstract ideas (or objects) such as bank accounts, transactions, and other such things managed by computers, using computer code. This means the code is structured in a way that more accurately represents these objects, and therefore, more accurately handles and manages them.
Encapsulation is the idea of the black box. Think of a car engine, for instance. Many people haven't the foggiest notion of how a combustion engine works (perhaps a better example is how an airplane stays up in the air, since even fewer seem to understand that secret). However, that isn't a very big problem, unless of course, your car breaks down (or the airplane crashes). As you drive the car, it doesn't (and shouldn't) concern you what happens when you press the gas pedal, or the brakes. When you turn the steering wheel, you don't care how the engine responds and decides which way to turn the car. It doesn't matter to you, because it's a black box system. As long as it does its job, the black box can remain a mystery, and there is absolutely no problem with that.
We can do precisely this same thing with computer software. We can now write a portion of code that can interact in a well-defined way (known as an API) with other code. We can bundle up the code we wrote, sell it to someone else, and then they can write code on top of it that turns the steering wheel and pushes the pedals, so to speak. They don't care how our code works; it just works. When they turn the steering wheel, the car turns, and when they push the gas pedal, the car moves forward.
Encapsulation is accomplished in the software world by defining the scope of program elements. The scope tells us where in the program (and outside) we can see those elements. Functions, as mentioned earlier, are one such element. Stored data is the other primary element. We can define something as public (viewable by everyone, everywhere) or private (viewable only within the black box). This allows us to share the information we want, and protect the information that shouldn't be shared within the black box.
Inheritance is a lot simpler; you are already familiar with one form of it - genetics. In programming, inheritance works exactly the same way. We can write generic code that acts like an Animal - it has behaviors (defined by functions) such as speak, play, sleep, and so on. Then, we can write more specific code that acts like a Dog, but inherits the more generic aspects that it shares with all Animals. All animals can speak, but when a Dog speaks, the behavior can be defined specifically as "Bark." We could then write a Cat which inherits this same behavior (speaking) but again, when we invoke the Cat's 'speak' function, instead we receive a "Meow" in response.
Finally, polymorphism is the most complex of the three. It's quite a difficult concept to wrap your mind around, even if you're a programmer. However, the simplest way to explain it was already done in the last paragraph. It is closely related to inheritance. When a Cat speaks and we hear a "Meow" then a Dog speaks and we hear a "Bark," this is an example of polymorphism. In either case, we are simply invoking the inherited "speak" function - but the behavior is different depending on the subclass (Cat or Dog). This is polymorphism - the ability to define a specific response to a generic behavior.
In essence, these abstractions give us two dimensions in which to program. With structured design, a function always does the same thing every time you call it. With object-oriented design, polymorphism gives us a different response based on both the function/behavior and the object/idea. Invoking the same function on a different object normally produces different results.
Now, prepare your mind for some extreme warping - we are now in the age of subject-oriented programming, where we can wield three such dimensions. The result or response we get from a function can now be defined by the name of the function, the object on which it is invoked, and the subject related to the invocation. For instance, my Dog might have a different bark depending on whether he was happy to see me, or whether he was trying to fend off an intruder. This constitutes the subject, or aspect, in which the behavior is invoked.
Aspect-oriented programming is very similar to subject-oriented, but to spare your mind further warpage, I won't go into any detail on the differences between the two. Instead, I will just say that programming has come a long way from using hexadecimal codes and command line interfaces. We now have the power to determine the software's behavior based on the desired function, the object performing the action, and the context in which the interaction occurs. This gives incredible potential even just for artificial intelligence. Computer code that can update and edit itself is now just around the corner.
And yet, DNA has been doing exactly that for thousands of years. Is that something that occurred by random chance? I think it's about as likely as computers assembling and programming themselves out of thin air. It takes a mind more intelligent than a computer to design and build a computer. By the same token, it takes a mind more intelligent than a human mind to create such an incomprehensibly vast universe, and to populate it with beings whose bodies themselves contain technology far more advanced than computers; least of all, the human mind itself.
Subscribe to:
Posts (Atom)