If you include the fact that you never bought it, that's more information that affects the probabilities. It's just like in the Monty Hall problem where revealing a goat behind one door changes the probabilities of what's behind the other doors.
Given the fact that cannabis was recently made legal where you live, you may be 5% less like to pass a class. Given the additional fact that you chose not to use cannabis, you may be 5% more likely to pass a class due to the curve being lowered by those who do smoke.
I thought we already knew the academic impact of canibus use from the documentary Fast Times at Ridgemont High
I thought the characters drove their cars to school in that movie.
When most AI people are talking about artificial intelligence, they are talking about narrow "intelligence". This is why in Russell & Norvig's book they quickly move away from the term "intelligence" and instead speak of "agents" working in a particular "task environment", and whether the agents behave rationally or not. For example, a chess program may be able to win chess games against a grandmaster chess player, so we say this agent is performing rationally within this specific task environment. The chess program is not "intelligent" in the sense that you and I are -- it's an incredibly dumb automaton, as is nearly every computer program. You can see this when it fails miserably when put in any different task environment.
The intelligence that will bring about the singularity is artificial general intelligence, which is the same intelligence that you and I have, that is, the capability of performing well in a very wide variety of environments. This type of agent would be able to reason about how to improve itself and bring about that improvement. Very little AI research these days involves artificial general intelligence, and the progress in this area is slow.
The goto statement isn't the issue. The issue is non-structured programming, which includes the use of goto, break, continue, multiple returns from a procedure, exceptions, longjmp, and anything else that interrupts the normal control flow of a program. The idea is that to understand a program, you need to understand all the ways the flow of control can occur. Each time you conditionally break the flow of control, you're potentially doubling the number of ways control could flow through the program, making it potentially exponentially harder to understand and test.
Once a co-worker proudly showed me how he wrote the following construct:
do {
if (condition) break;
if (another condition) break;
} while (0);
to avoid goto statements. My reaction is that goto statements would more clearly express the jumps in the control flow. A do-while indicates a loop, but it isn't a loop; it's gotos in disguise.
Some programmers take this idea to an extreme and even write code such as:
int abs(int x) {
int retval;
if (x >= 0) retval = x;
else retval = -x;
return retval;
}
In this case, multiple return statements would make the code simpler, not harder to understand. Similarly, using exceptions wisely can make code easier to understand, not harder.
The bottom line is that as a general rule it's best not to break the flow of control. But a good programmer will know when it makes sense to do so, and if a goto statement makes sense, it can be the clearest way to express such a break.
The moon is made of green cheese. -- John Heywood