Computer science books and even my highschool basic programming class mentioned its not proper programming to use a GOTO. Is there any computer science professor that supports GOTO statements in programs?
GOTOs are not inherently bad. At some level, they're unavoidable. (Have you ever programmed in assembly language?)
As for CS professors, Donald Knuth uses and defends GOTO statements:
(His code comments often make reference to why he uses GOTOS. For example, in his implementation of the classic Adventure game, he writes: "By the way, if you don't like |goto| statements, don't read this. (And don't read any other programs that simulate multistate systems.)" In http://www-cs-faculty.stanford.edu/~knuth/programs/15puzzle-korf1.w, he writes: "as a full professor with tenure, I don't have to worry about being fired when I use |goto| statements.")
Not every programmer is good and a good programmer will refrain from making the program harder to read or more difficult to debug when jr programmers modify it later.
GOTOs by their very nature encourage bad programming as much as pointers do.
Pointers encourage bad programming? No offense, but do you have any real programming experience beyond your "highschool basic programming class"?
The first amendment protects the free expression of ideas and opinions in a peaceable manner on PUBLIC property only.
No, that's wrong. The First Amendment simply says that "Congress shall make no law [...] abridging the freedom of speech." There is no mention of public or private property. Congress cannot pass a law restricting free speech on private property. A private property owner is not restricted by the First Amendment, but it's certainly not true that the First Amendment ceases to apply on private property.
Peer-review isn't always what it's cracked up to be. Read about the Bogdanov controversy that erupted in my uni some years back that exposes some serious flaws in the peer-review process.
How about an operating system? It's an algorithm that's continuously looping, responding to user inputs. You can only predict the outcome of an algorithm if you can precisely define the input, and in this case the input has an extra element: time.
For an OS, you can prove that certain conditions hold before and after some operation. If an OS can be assumed correct at time t, and the possible states at time t+1 are known and can be formally verified, then by induction the OS will continue to run correctly.
Of course, in practice this could be very difficult, but the problems seem to be practical, not theoretical. In fact, it appears that Dijkstra proved the correctness of THE:
Well, undecidability, maybe no. But provability - yes. There are plenty of algorithms that yield results, but we haven't the faintest idea why. The models don't fit into regular mathematics or at least not any mathematics that we understand or have developed yet. I am talking about neural nets and genetic algorithms. Say a sample neural net/genetic algorithm can be trusted and 'verified' to result in a useful solution perhaps 90% of the time, measured on a large amount of tests. How are you going to prove mathematically that this 90% will hold over time, if you don't even know how to describe the solution (the solution is developed by the program itself over time). It's inherent to chaos theory that you cannot predict what will happen at that level of 'randomness'. But please prove me wrong! (pun intended)
You still ought to be able to prove the correctness of your algorithm even in this case; that is, each component (subroutine, loop, etc.) can be verified in terms of pre- and post-conditions, and the program can provably compute the algorithm in question. If the program is non-deterministic, you might have to prove that the output of some subroutine is X with probability p, Y with probability q, etc., but you can specify the set of outputs and guarantee that the program will run as designed. In other words, it won't crash (assuming the underlying hardware behaves as it should, which is perhaps a dangerous assumption), and it will compute what it is supposed to compute.
If your algorithm is based on heuristics and randomization, then perhaps you can't precisely specify the output. Yet you can still prove (given some assumptions about the hardware, etc.) that the algorithm will be correctly executed.
Dijkstra and similar contemporary theorists like to puff up their chests about how they are the "real" computer scientists because they can prove this and that. I'd like to see them "prove" that Google returns the most relevant search results, or that being on LinkedIn gets you a better job. What the theorists are doing is useful, but neither the heart nor the cutting edge of computer science. The real advances come from lateral thinking and imagination, with the formulas coming in behind and filling in the details.
You really ought to learn more about Dijkstra's work before you make these claims. Dijkstra was absolutely on the cutting edge of computer science. His discovery of the semaphore construct, for example, was groundbreaking. Then there's his work on ALGOL 60, THE, his shortest-path algorithm . . .
Do you mean some event-driven code that has an infinite loop underlying it, or are you referring to the halting problem? In the former case, establishing loop invariants and formal pre- and post-conditions for subroutines should suffice. For the latter: if there's a question of whether or not an algorithm will terminate, I suspect there's something wrong with the program. (Randomized algorithms are perhaps an exception to this statement, since you could have an algorithm that terminates with probability 1, yet could still (theoretically) loop forever.)
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious, and still fails to be correct in the presence of concurrency. Somehow the program proof advocates lost sight of Gödel's incompleteness theorems.
I'm not an advocate of Dijkstra's approach. However, does the Incompleteness Theorem really come into play here? I can't think of any useful algorithm for which I wouldn't be able to formally describe and verify the pre- and post-conditions. Can you think of any naturally-arising examples of algorithms for which undecideability might be an issue?
TFA describes video for traffic *stops*. Real-time video for traffic stops hardly seems to be a benefit beyond the recoded video we have seen for 20 years.
It allows the dispatcher to see trouble in real-time and to send backup. An officer involved in a sudden struggle may not have a chance to radio in for backup, so this could be a lifesaver.
I recall studying PDEs in a 3rd year undergrad course. How you can get to Ph.D level in maths and not have at least a working (basic) understanding of them is beyond me.
I'm finishing my PhD in math, and I know almost nothing about PDEs. It's not relevant to my field of research.
I was going to get one, but I was told by my doctor not to. He said if I was ever in an accident where my hand was swelling that hospitals do not have the tools to cut Titanium.
Well I'm not sure about all ER's, but I work on an ambulance in an area with a major medical center, and we are often called to the hospitals because they don't have any ringcutters at all.
Mind you, our ambulance ring cutters are basically a steel, handcranked can opener. It can cut purer gold fairly well, but even gold alloys can take close to an hour. I'm not exactly how we would remove a titanium ring, because titanium would break our ringcutter.
I went for a titanium wedding band. I first read about a bike frame builder who made one from offcuts. A good titanium bike frame might be $2000. The ring cost us $300 for about 1000th as much material.
When we were looking for rings the jeweler showed me his and he had it made out of Tungsten. He mentioned that it was one of the hardest materials next to diamonds. It was heavy too! I was thinking Titanium as well but he said it would scratch fairly easily and couldn't be polished like Gold or Silver. Is this the case as you have found it to be? I would dig a Ti band as I'm a serious mnt. bike racer.
P.S. a nice Ti frame can run as much as $5000.00 or more!
I wear a Titanium wedding ring. It's picked up some light scratches, but they can be buffed out with a Dremel. I bought my ring from (and highly recommend) Boone Rings: http://www.boonerings.com/
The McClintock effect, also known as menstrual synchrony or the dormitory effect, is a theory that proposes that the menstrual cycles of women who live together (such as in prisons, convents, bordellos, or dormitories) tend to become synchronized over time.
The marriage was broken up because the guy wanted to cheat on his wife but got caught instead. The prank actually did a wife a favor.
That is very, very questionable. It is quite possible that she would have preferred not to know about it. It is quite possible that she would have ignored an attempt to cheat except the information was made public and couldn't easily be ignored. Maybe she would have preferred to raise her children together with their father and this "prankster" prevented it.
Exactly. I don't condone infidelity, but there are a lot of relationships that have a sort of "don't ask, don't tell" situation going on. Some partners would simply prefer not to know what the other does, and putting all of this information online isn't helpful to either partner. It's also possible that some of these people were in open relationships, but would have preferred not to share their private life with the world.
Now, with that said, if my wife were cheating on me and one of my friends discovered this, I'd hope they would tell me privately, so that my family wouldn't be humiliated, and I could deal with that information as I saw fit.
Of course, and pound for pound it's hard to think of a better gadget for nudging rocks about, but that's not what this guy is suggesting. He has stated time and again that we must blow asteroids into little bits. I'm not sure why.
Plus you've got to somehow figure out how to cut up rocks in a predictable fashion using nuclear weapons, for which there is no experience on Earth, let alone in space. Plus all of the problems of a manned interstellar mission. Plus all the problems of landing on an asteroid.
Once again, using nuclear explosives to divert an asteroid does NOT mean blowing them apart. A little (thermal) nudge is sufficient:
Would one or more nuclear explosions affect the orbit of a dinosaur-killer very much? Steering by explosion if you will.
Yup, that's the idea. If the asteroid is detected early enough, the orbit doesn't even need to be altered dramatically to avoid a collision. It might be sufficient to simply to use energy from the blast to heat one hemisphere of an asteroid, which will result in a change in velocity.
Slashdot Mirror
But why use it you do not have too?
Computer science books and even my highschool basic programming class mentioned its not proper programming to use a GOTO. Is there any computer science professor that supports GOTO statements in programs?
GOTOs are not inherently bad. At some level, they're unavoidable. (Have you ever programmed in assembly language?)
As for CS professors, Donald Knuth uses and defends GOTO statements:
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
(His code comments often make reference to why he uses GOTOS. For example, in his implementation of the classic Adventure game, he writes: "By the way, if you don't like |goto| statements, don't read this. (And don't read any other programs that simulate multistate systems.)" In http://www-cs-faculty.stanford.edu/~knuth/programs/15puzzle-korf1.w, he writes: "as a full professor with tenure, I don't have to worry about being fired when I use |goto| statements.")
Not every programmer is good and a good programmer will refrain from making the program harder to read or more difficult to debug when jr programmers modify it later.
GOTOs by their very nature encourage bad programming as much as pointers do.
Pointers encourage bad programming? No offense, but do you have any real programming experience beyond your "highschool basic programming class"?
In Wisconsin you are not allowed to evict a tenant between November and March (IIRC). The idea is that people can freeze to death without a home.
This is a common belief, but it isn't actually true. See here:
http://www.portagelawyers.com/pamphlets/landlord_tenant.asp#A8
http://www.legis.state.wi.us/statutes/stat0704.pdf
I enjoy helping other people out, but I'd rather not be plugging things in and restarting computers the rest of my life.
As a junior-level CS major, do you really think that's what CS grads typically do?
Although the possibility is growing on me, I don't think I would particularly love to write code all day for a living either.
Then why are you majoring in CS?
I don't think you read my comment carefully. How does that contradict what I wrote?
The first amendment protects the free expression of ideas and opinions in a peaceable manner on PUBLIC property only.
No, that's wrong. The First Amendment simply says that "Congress shall make no law [...] abridging the freedom of speech." There is no mention of public or private property. Congress cannot pass a law restricting free speech on private property. A private property owner is not restricted by the First Amendment, but it's certainly not true that the First Amendment ceases to apply on private property.
Peer-review isn't always what it's cracked up to be. Read about the Bogdanov controversy that erupted in my uni some years back that exposes some serious flaws in the peer-review process.
http://en.wikipedia.org/wiki/Bogdanov_Affair
Or read about the ongoing El Naschie affair:
http://golem.ph.utexas.edu/category/2008/11/the_case_of_m_s_el_naschie.html
How about an operating system? It's an algorithm that's continuously looping, responding to user inputs. You can only predict the outcome of an algorithm if you can precisely define the input, and in this case the input has an extra element: time.
For an OS, you can prove that certain conditions hold before and after some operation. If an OS can be assumed correct at time t, and the possible states at time t+1 are known and can be formally verified, then by induction the OS will continue to run correctly.
Of course, in practice this could be very difficult, but the problems seem to be practical, not theoretical. In fact, it appears that Dijkstra proved the correctness of THE:
http://en.wikipedia.org/wiki/THE_(operating_system)
Well, undecidability, maybe no. But provability - yes. There are plenty of algorithms that yield results, but we haven't the faintest idea why. The models don't fit into regular mathematics or at least not any mathematics that we understand or have developed yet. I am talking about neural nets and genetic algorithms. Say a sample neural net/genetic algorithm can be trusted and 'verified' to result in a useful solution perhaps 90% of the time, measured on a large amount of tests. How are you going to prove mathematically that this 90% will hold over time, if you don't even know how to describe the solution (the solution is developed by the program itself over time). It's inherent to chaos theory that you cannot predict what will happen at that level of 'randomness'. But please prove me wrong! (pun intended)
You still ought to be able to prove the correctness of your algorithm even in this case; that is, each component (subroutine, loop, etc.) can be verified in terms of pre- and post-conditions, and the program can provably compute the algorithm in question. If the program is non-deterministic, you might have to prove that the output of some subroutine is X with probability p, Y with probability q, etc., but you can specify the set of outputs and guarantee that the program will run as designed. In other words, it won't crash (assuming the underlying hardware behaves as it should, which is perhaps a dangerous assumption), and it will compute what it is supposed to compute.
If your algorithm is based on heuristics and randomization, then perhaps you can't precisely specify the output. Yet you can still prove (given some assumptions about the hardware, etc.) that the algorithm will be correctly executed.
Dijkstra and similar contemporary theorists like to puff up their chests about how they are the "real" computer scientists because they can prove this and that. I'd like to see them "prove" that Google returns the most relevant search results, or that being on LinkedIn gets you a better job. What the theorists are doing is useful, but neither the heart nor the cutting edge of computer science. The real advances come from lateral thinking and imagination, with the formulas coming in behind and filling in the details.
You really ought to learn more about Dijkstra's work before you make these claims. Dijkstra was absolutely on the cutting edge of computer science. His discovery of the semaphore construct, for example, was groundbreaking. Then there's his work on ALGOL 60, THE, his shortest-path algorithm . . .
Algorithms that don't terminate?
Do you mean some event-driven code that has an infinite loop underlying it, or are you referring to the halting problem? In the former case, establishing loop invariants and formal pre- and post-conditions for subroutines should suffice. For the latter: if there's a question of whether or not an algorithm will terminate, I suspect there's something wrong with the program. (Randomized algorithms are perhaps an exception to this statement, since you could have an algorithm that terminates with probability 1, yet could still (theoretically) loop forever.)
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious, and still fails to be correct in the presence of concurrency. Somehow the program proof advocates lost sight of Gödel's incompleteness theorems.
I'm not an advocate of Dijkstra's approach. However, does the Incompleteness Theorem really come into play here? I can't think of any useful algorithm for which I wouldn't be able to formally describe and verify the pre- and post-conditions. Can you think of any naturally-arising examples of algorithms for which undecideability might be an issue?
More than not being "great", he seems to be rather foolish...
1) His main premise is that "software engineering" cannot exist because software cannot be proved correct
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness. See his "A Discipline of Programming", for example.
TFA describes video for traffic *stops*. Real-time video for traffic stops hardly seems to be a benefit beyond the recoded video we have seen for 20 years.
It allows the dispatcher to see trouble in real-time and to send backup. An officer involved in a sudden struggle may not have a chance to radio in for backup, so this could be a lifesaver.
Funny, I've never seen that "increase resolution" button in photoshop before.
There are ways to increase resolution through various interpolation techniques. Genuine Fractals is popular among photographers shooting stock images.
I recall studying PDEs in a 3rd year undergrad course. How you can get to Ph.D level in maths and not have at least a working (basic) understanding of them is beyond me.
I'm finishing my PhD in math, and I know almost nothing about PDEs. It's not relevant to my field of research.
I was going to get one, but I was told by my doctor not to. He said if I was ever in an accident where my hand was swelling that hospitals do not have the tools to cut Titanium.
That's not true: http://www.boonerings.com/faq.htm#4
Well I'm not sure about all ER's, but I work on an ambulance in an area with a major medical center, and we are often called to the hospitals because they don't have any ringcutters at all.
Mind you, our ambulance ring cutters are basically a steel, handcranked can opener. It can cut purer gold fairly well, but even gold alloys can take close to an hour. I'm not exactly how we would remove a titanium ring, because titanium would break our ringcutter.
It's not difficult to cut off a Titanium ring:
http://www.boonerings.com/faq.htm#4
I went for a titanium wedding band. I first read about a bike frame builder who made one from offcuts. A good titanium bike frame might be $2000. The ring cost us $300 for about 1000th as much material.
When we were looking for rings the jeweler showed me his and he had it made out of Tungsten. He mentioned that it was one of the hardest materials next to diamonds. It was heavy too! I was thinking Titanium as well but he said it would scratch fairly easily and couldn't be polished like Gold or Silver. Is this the case as you have found it to be? I would dig a Ti band as I'm a serious mnt. bike racer.
P.S. a nice Ti frame can run as much as $5000.00 or more!
I wear a Titanium wedding ring. It's picked up some light scratches, but they can be buffed out with a Dremel. I bought my ring from (and highly recommend) Boone Rings: http://www.boonerings.com/
Remember, you're going to have four women who are all menstruating at the same time - I think that would have some negative effect ;-)
McClintock effect
The McClintock effect, also known as menstrual synchrony or the dormitory effect, is a theory that proposes that the menstrual cycles of women who live together (such as in prisons, convents, bordellos, or dormitories) tend to become synchronized over time.
There isn't much evidence to support that theory:
http://www.straightdope.com/columns/021220.html
Do the police require warrants to bug my house? YES! The difference between my house and my car is very little so yes they need warrants too.
Yes, but do the police need a warrant to put a GPS tracker on your house?
The marriage was broken up because the guy wanted to cheat on his wife but got caught instead. The prank actually did a wife a favor.
That is very, very questionable. It is quite possible that she would have preferred not to know about it. It is quite possible that she would have ignored an attempt to cheat except the information was made public and couldn't easily be ignored. Maybe she would have preferred to raise her children together with their father and this "prankster" prevented it.
Exactly. I don't condone infidelity, but there are a lot of relationships that have a sort of "don't ask, don't tell" situation going on. Some partners would simply prefer not to know what the other does, and putting all of this information online isn't helpful to either partner. It's also possible that some of these people were in open relationships, but would have preferred not to share their private life with the world.
Now, with that said, if my wife were cheating on me and one of my friends discovered this, I'd hope they would tell me privately, so that my family wouldn't be humiliated, and I could deal with that information as I saw fit.
Of course, and pound for pound it's hard to think of a better gadget for nudging rocks about, but that's not what this guy is suggesting. He has stated time and again that we must blow asteroids into little bits. I'm not sure why.
Ahh, okay, gotcha.
Plus you've got to somehow figure out how to cut up rocks in a predictable fashion using nuclear weapons, for which there is no experience on Earth, let alone in space. Plus all of the problems of a manned interstellar mission. Plus all the problems of landing on an asteroid.
Once again, using nuclear explosives to divert an asteroid does NOT mean blowing them apart. A little (thermal) nudge is sufficient:
http://e-reports-ext.llnl.gov/pdf/343984.pdf
Also, several studies have indicated that nuking the average asteroid would be worse than pointless.
Which studies are you referring to? Here's one that claims the opposite:
http://e-reports-ext.llnl.gov/pdf/343984.pdf
Would one or more nuclear explosions affect the orbit of a dinosaur-killer very much? Steering by explosion if you will.
Yup, that's the idea. If the asteroid is detected early enough, the orbit doesn't even need to be altered dramatically to avoid a collision. It might be sufficient to simply to use energy from the blast to heat one hemisphere of an asteroid, which will result in a change in velocity.