I've often struggled with Quantum Mechanics, like many I never really accepted it into my world view because the conclusions of to contradicted with my everyday experience. More than that though I used to reject relativity because again it contradicted my world view. It's important to say that I'm not saying that they were wrong, just that they were too weird to be right.
To be fair it's normally a good measure of the validity of a theory, at least in the rest of life that it if it feels right then it is probably good. Just like a fast race car normally looks nice, and a good engine sounds good. (or is that just because we have trained ourselves to look for the right structures? That's another discussion though).
Anyway I'll stay on relativity for the moment, I was taught it by any number of thought experiments. The man running on top of a train, the spaceship to the next start system with a clock on each. In each one of these they reached a set of conclusions about the way that things had to work and from this concluded that the speed of light must be constant and that all frames of reference are equally valid. This left me cold and not believing it. This is let's not argue a question of belief because i could never experience them and because it didn't match my existing world view I discarded the new belief.
Now where I think this was wrong was that I missed the first bit. What I should have done is started from the "let's pretend that we had a world where the speed of light is constant for all viewers and all reference frames are equally vaild. Now how would this world have to behave if you were to push the limits of the rules..." From that you then discuss all these relativity thought experiments. Now if you'd happened to say that 'actually if we do this real world experiment then this ties in with this thought experiment'. etc etc.. Unfortunatly that never happened and it took a long time for me to tie up the loose ends by myself.
At the same time I was going through this with Quantum Mechanics. I was smugly superior that there must have been something deeper. What I hadn't realised was that I had come up with the hidden variable theory. Had wikipedia existed at this point or had I actually been studying physics I might have come across this, but I didn't. Of course the outcome of this is that there are experiments possible to determine if QMs probabilities are real or if there are some hidden variables. They of course did them and QM stands. This blew my mind.
Now let's fast forward slightly I'm trying to defend QM specifically and science in general on a random discussion board and this whole thing comes back around again so here is a somewhat re-written version of what I posted.
There's a difference between science and religion, or at least religion as it is often practised. I admit that science can be seen to be a religion to many looking at it, but all that can happen is that people try and explain their point of view and hopefully the truth will become evident. I guess that is at the end of the day the view of all rational parties on both sides: that if they could just find a way to explain themselves properly then the other side will come around. So let me try for the side of science.
Science doesn't care what you think, it doesn't care about your past it just cares if you are correct, or at least interesting. This is not to say that there are not those in authority. If Richard Feynman were to say "You know I've been thinking about it and maybe the maths behind electron behaviour is a bit wrong" then people would probably listen. If some random user on a web forum says the same thing then there would be much more scepticism. This is the right way for things to be though; there are many more insufficiently educated people who don't understand enough of the relevant field than there are experts or even well informed outsiders with a valuable perspective to offer. The outsider is not to know that most things have already been considered by thousands of others previously and the chances are that they have made a error someone has made before. They might not have even made an error, they just may not be aware of certain experimental evidence. At first glance (to me) the hidden variable theory makes much more sense than QM, but reality nor the scientific community doesn't care what you think or what makes sense if it doesn't match experiments and only once you have proved you are aware of the vast range of experimental data can you start to question those who are.
Taking a step back, many before have commented on how Newton was wrong, Einstein could/must be wrong.
Well no, let me use a bad analogy that I find reassuring: Suppose you grew up in the Yorkshire Dales. Let's say you had never left Skipton. As far as you're concerned, water falls from the sky, when there's a lot of it you get a river. When it gets cold it freezes, then you leave it in a cup it evaporates. From this you could determine many properties of water. You could maybe even work out the basics of the water cycle and predict huge amounts of its behaviour. But could you predict deserts? Or would you reject it as just not possible because almost every other day if not every single day water falls from the sky. What about oceans? Salty water would be ludicrous to you. While you might be able to get what they were thinking when someone told you about it, water that you couldn't drink might be just impossible for you to accept.
I think the same applies for QM and relativity, that I can't accept that the world could be governed by probability, that all of this highly predictable world I am used to could be the result of lots of randomness. I can do that maths and use it, but I don't really accept it because it is outside my experience. Who was it who said that you don't understand $advanced_science you just get used to it.
The post would end here but I came across something the other say that blew my mind again. As I understand it, edge effects on a 2d plane could cause the behaviour of the universe as we observe it. I really like this, i could accept that as part of my world view, not because it is complex, but because it is complexity from something very simple; and that really appeals to my aesthetic.
Then again we could all be living in a simulation and the more I learn about string theory the more that seems probable. Although AFAIAC the simulation argument is the new Godwin's law of physics discussions so on that note...
Monday 15 November 2010
Friday 12 November 2010
Electronics for Dogs
Okay so I've not posted in over a year. I've had nothing to say, so I've not said it.
Anyway I remembered this morning a project I started years ago and never quite finished. So I thought I'd have another go at it on here.
The challenge came from the idea that I think engineering and computers are actually really simple, people just think they're complex because what you have is a great number of very simple concepts working together and you have to understand most of then to understand any of them.
For me it came as a revelation about 3/4 of the way into my electronics BTEC that ever since then the concepts have been easy even if the maths and execution is difficult. Therefore I wanted to explain the easy bit to help people understand this fundamental part of the modern world even if you do leave the complexity up to those who have studied.
The project aim was expressed at the time as "To explain electronics in such a way that my girlfriend could understand it". Which goes to show how much I have learned over the past few years because I should have known how bad an idea it was to express the concept in such an insulting form. To then go on and tell her that I was naming said project "Electronics for Dogs" in a tribute to Wallace and Gromit goes on to show just how badly I could get things wrong and explains why I spent almost all of University single.
So here we go, I present the first chapter, if this proves successful to me then I'll post more later.
Computers are complex and a pillar of modern society. They're clearly designed by really clever people. Rubbish. I design them and that should be enough justification for you that they're not that hard.
To start geeky as I mean to go on Tom Barker in his first Doctor Who story expressed it best "A computer is a very fast idiot. They do exactly what you tell them to at amazing speed. Which becomes a bit of a problem if you've told them to do something you don't want them to."
I don't think the average person would believe just how simple a computer actually is at its heart but it'll be a while before we can get to that, let's start off with a simple problem. A key code door lock. It's a simple device really, everyone can understand how to use one, but how hard is it to make one? Very simple actually, provided you break the problem down. This is going to be the key to everything we do if you'll pardon the pun. It's crucial to say that at each stage you may ask, "but how do you do that?" to which I could explain and hopefully will later on in further chapters but the most vitally important part to getting your head around all this stuff is the ability to say to yourself "I won't worry about that now, that's someone else's problem" Up until now, how a computer works or how to build an electronic door lock might have been someone else's problem, well let's try and peel the onion a bit, but don't worry yet about what lies at the heart of the onion we'll get there, but it may take a while. All I will say is that if you can follow this first article you too can understand the depths of your computer because this one covers what I believe is the hardest concept.
However just so you know here's the plan I assume you know nothing about the internals of computers or electronics or anything above basic physics, so you'll have to bear with me otherwise it will go:
Student: How does a computer work?
Me: Erm I need to explain programming languages [explanation follows]
Student: well how does that run on a computer
Me: Well I have to explain what a processor is [explanation follows]
Student: Well what is a logic gate?
Me: Well I have to explain what a transistor is [explanation follows]
Student: But I don't understand quantum mechanics
Me: Neither do I, just trust me on this. (In fact there is the quote that "If you are not completely confused by quantum mechanics, you do not understand it")
So for our first discussion we talk about programming languages and only programming languages. Trust me that next time we'll talk about how you could implement a programming language in a way that it would run on a machine. It doesn't matter yet that you understand how that machine would look, just that you follow the basic concepts in the programming language bit.
So let's take that door lock, lets break the problem down into a few steps.
1) If the user presses a button, is it the clear button? If it is then clear everything otherwise:
2) Does the button match the first digit in the code? If it is then wait for the second button.
3) Does the button match the second digit in the code? If it is then wait for the third button
etc until
4) have all buttons been pressed in the correct order? If yes then unlock the door.
That does help us break the problem down and so is helpful, but it's a bit confused, but often your first attempts are a bit confused.
Let's introduce some pseudo-code, that is a way of writing some of these things in a way that while still ambiguous is more precise than the English language. Over time we'll develop this pseudo code into a more precise language.
What I'll say is "if {something or other} then {something we want to do} otherwise {something we'll do instead}.
So let's try that door lock again shall we, hopefully this time a little bit more precise.
if {someone has pressed a button} then {does it match the first digit of the code? } otherwise {it's the incorrect code so do nothing until someone presses clear}
Hang on though before we go any further and finish that off notice that our first thing to do is another question. so let's take that and break it down again, we could re-phrase that as:
if {button pressed is equal to first code digit} then {first digit is pressed so we need to test for next code digit}
which means the thing to do could again be written as
if {button pressed is equal to second code digit} then {second digit is pressed so we need to test for next code digit} otherwise {it's the incorrect code so do nothing until someone presses clear}
This is all getting quite confusing now, having these statements inside statements means things get awefully complex very quickly. What we need is a way to remember what button press we're up to. So what about having seen what I've written above can we produce something more clean? Well have this thing, this variable, I'll call it anything I want, let's say last_correct_code_pressed that I can set to a value and when i reference it in other parts of the program the pseudocode will know that I'm referencing this thing I set earlier. It doesn't matter what it actually is, or how the code does it, as long as the reader (and therefore later the machine) knows that I'm referencing this thing.
Let's try restating the problem as
set last_correct_code_pressed to 0
if {a button is pressed} then
{
if {button pressed is equal to the next code in the sequence} then {
set last_correct_code_pressed to last_correct_code_pressed +1
if {last_correct_code_pressed is the last code in the sequence} then {open the door }
}
otherwise
{
set last_correct_code_pressed to 0
}
}
Okay it's quite a different way of stating the problem but hopefully you were able to follow what we're trying to say, by breaking the code across multiple lines and using the brackets to keep the code together we can break the problem down. Now the above isn't a full solution to the problem neither will it run on any computer in existence. That is not the point of this exercise. There are lots of books on how to write software code that will take you from the concept to the implementation. The point I'm trying to start with is that you have the concepts.
To push the concept further now you might ask, "well how does it know a button is pressed?" Well, to give you a quick answer, assume there are the numbers 0 to 9 on a keypad. in a typical implementation you would have a bit of code that every few milliseconds (that is thousands of times a second) does the following:
button_to_check = 0
while {button to check is less than or equal to 9} then {
if {the button to be check is telling me that it is pressed} then {tell who needs to be told} otherwise {button_to_check = button_to_check +1}
}
The important part here being this while statement will keep going round and round within itself until button_to_check is equal to 10. if it detects a button pressed it will go and "call" whoever needs to do something about it. Given that this is happening in our example 1000 times a second you can understand it's probably for the best that nothing much happens a lot of the time.
"Ah, but" you say "You still haven't answered how a button can tell me it is pressed"
To which I will say, "good point". Now this is the really weird bit, or the really trivial bit depending on your point of view. Assuming you followed the above with the button_to_check then you already know the answer. In the same way there was a variable called button_to_check that you could store a number in there can be a variable called (for example) button_pressed that tells you what button is pressed. How that piece of magic happens will for the moment remain magic, but trust me it will become clear later.
Now I'm not saying that's all there is to programming, far far far from it, you wouldn't spend 3 years at university learning computer science if that was all there was to it. That is however the start and almost enough. Let's jump a few stages from key locks to something much more complex, let's try a web browser. In our pseudocode parts of a web browser's code might look something like:
if {user presses back button} then {switch address to previous page}
if {user presses refresh button} then {reload this page}
if {user presses home button} then {set address to recorded home page}
Hang on we've yet to actually draw the web browser on screen yet, okay so lets take a step back; after firefox loads, code equivalent to this might run:
Draw a generic window this_wide by this_high at this_location on the screen
put the firefox logo at this_location
Set the window title text to Blogger: Double you - Create Post - Mozilla Firefox
Add a file menu
Add an edit menu
Add a view menu
etc
Hang on though, you ask how do you draw a window?
Simple, you ask the operating system to do it for you. Most people don't care because it is someone else's problem but let's assume you're curious; as always break the problem down:
Draw a grey box this_wide by this_high at this_location on the screen
Draw the minimise, maximise and close icons
Draw the title bar from here to here in this colour.
etc
Fine you ask, how do you draw a grey box on the screen, (answer: you ask the graphics card driver to do it for you), then knowing that you ask how does the graphics card make those pixels light up etc.
Hopefully you can see that this is all about taking what appears to be a very complex problem and breaking it down. As soon as you can break it down into logical steps you can then break each of those steps down into more and more steps until you end up with something so simple even an idiot like a computer could do it. The only thing a computer does is these very very simple things very very very fast.
What those simple things a computer does is a topic for next chapter.
Anyway I remembered this morning a project I started years ago and never quite finished. So I thought I'd have another go at it on here.
The challenge came from the idea that I think engineering and computers are actually really simple, people just think they're complex because what you have is a great number of very simple concepts working together and you have to understand most of then to understand any of them.
For me it came as a revelation about 3/4 of the way into my electronics BTEC that ever since then the concepts have been easy even if the maths and execution is difficult. Therefore I wanted to explain the easy bit to help people understand this fundamental part of the modern world even if you do leave the complexity up to those who have studied.
The project aim was expressed at the time as "To explain electronics in such a way that my girlfriend could understand it". Which goes to show how much I have learned over the past few years because I should have known how bad an idea it was to express the concept in such an insulting form. To then go on and tell her that I was naming said project "Electronics for Dogs" in a tribute to Wallace and Gromit goes on to show just how badly I could get things wrong and explains why I spent almost all of University single.
So here we go, I present the first chapter, if this proves successful to me then I'll post more later.
Computers are complex and a pillar of modern society. They're clearly designed by really clever people. Rubbish. I design them and that should be enough justification for you that they're not that hard.
To start geeky as I mean to go on Tom Barker in his first Doctor Who story expressed it best "A computer is a very fast idiot. They do exactly what you tell them to at amazing speed. Which becomes a bit of a problem if you've told them to do something you don't want them to."
I don't think the average person would believe just how simple a computer actually is at its heart but it'll be a while before we can get to that, let's start off with a simple problem. A key code door lock. It's a simple device really, everyone can understand how to use one, but how hard is it to make one? Very simple actually, provided you break the problem down. This is going to be the key to everything we do if you'll pardon the pun. It's crucial to say that at each stage you may ask, "but how do you do that?" to which I could explain and hopefully will later on in further chapters but the most vitally important part to getting your head around all this stuff is the ability to say to yourself "I won't worry about that now, that's someone else's problem" Up until now, how a computer works or how to build an electronic door lock might have been someone else's problem, well let's try and peel the onion a bit, but don't worry yet about what lies at the heart of the onion we'll get there, but it may take a while. All I will say is that if you can follow this first article you too can understand the depths of your computer because this one covers what I believe is the hardest concept.
However just so you know here's the plan I assume you know nothing about the internals of computers or electronics or anything above basic physics, so you'll have to bear with me otherwise it will go:
Student: How does a computer work?
Me: Erm I need to explain programming languages [explanation follows]
Student: well how does that run on a computer
Me: Well I have to explain what a processor is [explanation follows]
Student: Well what is a logic gate?
Me: Well I have to explain what a transistor is [explanation follows]
Student: But I don't understand quantum mechanics
Me: Neither do I, just trust me on this. (In fact there is the quote that "If you are not completely confused by quantum mechanics, you do not understand it")
So for our first discussion we talk about programming languages and only programming languages. Trust me that next time we'll talk about how you could implement a programming language in a way that it would run on a machine. It doesn't matter yet that you understand how that machine would look, just that you follow the basic concepts in the programming language bit.
So let's take that door lock, lets break the problem down into a few steps.
1) If the user presses a button, is it the clear button? If it is then clear everything otherwise:
2) Does the button match the first digit in the code? If it is then wait for the second button.
3) Does the button match the second digit in the code? If it is then wait for the third button
etc until
4) have all buttons been pressed in the correct order? If yes then unlock the door.
That does help us break the problem down and so is helpful, but it's a bit confused, but often your first attempts are a bit confused.
Let's introduce some pseudo-code, that is a way of writing some of these things in a way that while still ambiguous is more precise than the English language. Over time we'll develop this pseudo code into a more precise language.
What I'll say is "if {something or other} then {something we want to do} otherwise {something we'll do instead}.
So let's try that door lock again shall we, hopefully this time a little bit more precise.
if {someone has pressed a button} then {does it match the first digit of the code? } otherwise {it's the incorrect code so do nothing until someone presses clear}
Hang on though before we go any further and finish that off notice that our first thing to do is another question. so let's take that and break it down again, we could re-phrase that as:
if {button pressed is equal to first code digit} then {first digit is pressed so we need to test for next code digit}
which means the thing to do could again be written as
if {button pressed is equal to second code digit} then {second digit is pressed so we need to test for next code digit} otherwise {it's the incorrect code so do nothing until someone presses clear}
This is all getting quite confusing now, having these statements inside statements means things get awefully complex very quickly. What we need is a way to remember what button press we're up to. So what about having seen what I've written above can we produce something more clean? Well have this thing, this variable, I'll call it anything I want, let's say last_correct_code_pressed that I can set to a value and when i reference it in other parts of the program the pseudocode will know that I'm referencing this thing I set earlier. It doesn't matter what it actually is, or how the code does it, as long as the reader (and therefore later the machine) knows that I'm referencing this thing.
Let's try restating the problem as
set last_correct_code_pressed to 0
if {a button is pressed} then
{
if {button pressed is equal to the next code in the sequence} then {
set last_correct_code_pressed to last_correct_code_pressed +1
if {last_correct_code_pressed is the last code in the sequence} then {open the door }
}
otherwise
{
set last_correct_code_pressed to 0
}
}
Okay it's quite a different way of stating the problem but hopefully you were able to follow what we're trying to say, by breaking the code across multiple lines and using the brackets to keep the code together we can break the problem down. Now the above isn't a full solution to the problem neither will it run on any computer in existence. That is not the point of this exercise. There are lots of books on how to write software code that will take you from the concept to the implementation. The point I'm trying to start with is that you have the concepts.
To push the concept further now you might ask, "well how does it know a button is pressed?" Well, to give you a quick answer, assume there are the numbers 0 to 9 on a keypad. in a typical implementation you would have a bit of code that every few milliseconds (that is thousands of times a second) does the following:
button_to_check = 0
while {button to check is less than or equal to 9} then {
if {the button to be check is telling me that it is pressed} then {tell who needs to be told} otherwise {button_to_check = button_to_check +1}
}
The important part here being this while statement will keep going round and round within itself until button_to_check is equal to 10. if it detects a button pressed it will go and "call" whoever needs to do something about it. Given that this is happening in our example 1000 times a second you can understand it's probably for the best that nothing much happens a lot of the time.
"Ah, but" you say "You still haven't answered how a button can tell me it is pressed"
To which I will say, "good point". Now this is the really weird bit, or the really trivial bit depending on your point of view. Assuming you followed the above with the button_to_check then you already know the answer. In the same way there was a variable called button_to_check that you could store a number in there can be a variable called (for example) button_pressed that tells you what button is pressed. How that piece of magic happens will for the moment remain magic, but trust me it will become clear later.
Now I'm not saying that's all there is to programming, far far far from it, you wouldn't spend 3 years at university learning computer science if that was all there was to it. That is however the start and almost enough. Let's jump a few stages from key locks to something much more complex, let's try a web browser. In our pseudocode parts of a web browser's code might look something like:
if {user presses back button} then {switch address to previous page}
if {user presses refresh button} then {reload this page}
if {user presses home button} then {set address to recorded home page}
Hang on we've yet to actually draw the web browser on screen yet, okay so lets take a step back; after firefox loads, code equivalent to this might run:
Draw a generic window this_wide by this_high at this_location on the screen
put the firefox logo at this_location
Set the window title text to Blogger: Double you - Create Post - Mozilla Firefox
Add a file menu
Add an edit menu
Add a view menu
etc
Hang on though, you ask how do you draw a window?
Simple, you ask the operating system to do it for you. Most people don't care because it is someone else's problem but let's assume you're curious; as always break the problem down:
Draw a grey box this_wide by this_high at this_location on the screen
Draw the minimise, maximise and close icons
Draw the title bar from here to here in this colour.
etc
Fine you ask, how do you draw a grey box on the screen, (answer: you ask the graphics card driver to do it for you), then knowing that you ask how does the graphics card make those pixels light up etc.
Hopefully you can see that this is all about taking what appears to be a very complex problem and breaking it down. As soon as you can break it down into logical steps you can then break each of those steps down into more and more steps until you end up with something so simple even an idiot like a computer could do it. The only thing a computer does is these very very simple things very very very fast.
What those simple things a computer does is a topic for next chapter.
Subscribe to:
Posts (Atom)