Sure you can wrap up the c handlers in c++ objects which then have automagic destructors, but that is a lot of extra layers and code just to get around using a goto.
Let me preface this by saying I don't think gotos are always "bad", that said, I don't think they're the best solution for this example when writing in C++. Extra layers, yes (but mostly negligible), but extra code? This is why we have libraries. To wit: def foo
library_thing1
ScopeGuard u1 = MakeGuard(boost::bind(undo_library_thing1)); ...
stuff that can go horribly bad ...
end
I apologize for the lack of indentation, I just couldn't get it right.
You don't even need to create a new class if you don't want to, and the setup and teardown are right next to each other, so you don't have to scan down to the bottom of the function to be sure you cleaned up after yourself (goto or no).
Final iteration. I should not consider the scenarios where monty can choose between 2 goats as two rounds, but rather one, as it's the same outcome regardless of which door Monty chooses
class Round < Struct.new(:car_door,:initial_chosen_door,:switched_to_door) def won? car_door == switched_to_door end
def switched? initial_chosen_door != switched_to_door end end
rounds_switch = [] rounds_noswitch = [] doors = [1,2,3] doors.each do |car_door| doors.each do |initial_chosen_door| (doors - [car_door, initial_chosen_door])[0...1].each do |montys_door| round_noswitch = Round.new(car_door, initial_chosen_door, initial_chosen_door) round_switch = Round.new(car_door, initial_chosen_door, (doors - [initial_chosen_door, montys_door]).first) rounds_noswitch << round_noswitch rounds_switch << round_switch puts "The car was behind: #{car_door}, I didn't switch and chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, I #{round_noswitch.won? ? "won" : "lost"}"
puts "The car was behind: #{car_door}, I did switch and initially chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, and I switched to #{round_switch.switched_to_door}, I #{round_switch.won? ? "won" : "lost"}" end end end
puts "Out of #{rounds_noswitch.size} rounds where I didn't switch, I won #{rounds_noswitch.select { |i| i.won? }.size} times."
puts "Out of #{rounds_switch.size} rounds where I _did_ switch, I won #{rounds_switch.select { |i| i.won? }.size} times."
I figured out the bug. The scenarios where Monty has two doors to choose from, him choosing the first door or the second shouldn't count as 2 rounds, because which door he chooses is irrelevant.
So I tweaked the code as follows, output is omitted. I get the same winningness whether you switch or not (and it adds up to 1 this time;) ). class Round < Struct.new(:car_door,:initial_chosen_door,:switched_to_door) def won? car_door == switched_to_door end
def switched? initial_chosen_door != switched_to_door end end
rounds_switch = [] rounds_noswitch = [] doors = [1,2,3] doors.each do |car_door| doors.each do |initial_chosen_door| (doors - [car_door, initial_chosen_door]).each do |montys_door| round_noswitch = Round.new(car_door, initial_chosen_door, initial_chosen_door) round_switch = Round.new(car_door, initial_chosen_door, (doors - [initial_chosen_door, montys_door]).first) rounds_noswitch << round_noswitch rounds_switch << round_switch puts "The car was behind: #{car_door}, I didn't switch and chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, I #{round_noswitch.won? ? "won" : "lost"}"
puts "The car was behind: #{car_door}, I did switch and initially chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, and I switched to #{round_switch.switched_to_door}, I #{round_switch.won? ? "won" : "lost"}" end end end
puts "Out of #{rounds_noswitch.size} rounds where I didn't switch, I won #{rounds_noswitch.select { |i| i.won? }.size} times."
puts "Out of #{rounds_switch.size} rounds where I _did_ switch, I won #{rounds_switch.select { |i| i.won? }.size} times."
That may very well be true. On the other hand, I'd much rather hear about the bugs in the code or in the assumptions expressed in the code, because the idea is to demonstrate that it is 2/3 and 1/3 by exhausting all the possibilities. Saying the results are wrong because they don't come out to the expected results doesn't help the code as an argument to convince someone who isn't already convinced of the results. Can you see where I miscounted? Of course you may not be interested in an exhaustive enumeration as proof and may be disinclined to help me;).
I just went thru all the possibilities exhaustively. I look forward to seeing someone complain about my code, I probably did something mathematically wrong
% cat monty_exhaust.rb class Round < Struct.new(:car_door,:initial_chosen_door,:switched_to_door) def won? car_door == switched_to_door end
def switched? initial_chosen_door != switched_to_door end end
rounds = [] doors = [1,2,3] doors.each do |car_door| doors.each do |initial_chosen_door| (doors - [car_door, initial_chosen_door]).each do |montys_door| round_noswitch = Round.new(car_door, initial_chosen_door, initial_chosen_door) round_switch = Round.new(car_door, initial_chosen_door, (doors - [initial_chosen_door, montys_door]).first) rounds << round_noswitch rounds << round_switch end end end
So, um don't be a blogger. Get into a profession where you can make a ton of money and not be tearing your hair out from stress. If the goal is to get money, don't lock yourself in a box by saying, "I have to be a blogger, so to make sure I make oodles of cash safely, let's fix blogging."
Being able to pass a pointer to a public property (or a pair of getter/setter methods) isn't about bypassing the encapsulation. It's about abstracting away _which_ property (the name of it, and/or even the class or type of the object whose property you are manipulating).
Slashdot Mirror
I think you're thinking of 2.96: http://gcc.gnu.org/gcc-2.96.html
thing
loose is a verb too.
Mad Maze was awesome.
def foo
library_thing1
ScopeGuard u1 = MakeGuard(boost::bind(undo_library_thing1));
stuff that can go horribly bad
end
I apologize for the lack of indentation, I just couldn't get it right.
You don't even need to create a new class if you don't want to, and the setup and teardown are right next to each other, so you don't have to scan down to the bottom of the function to be sure you cleaned up after yourself (goto or no).
It's defeat-able by invisibility paint!
Not even once? Impressive.
Final iteration. I should not consider the scenarios where monty can choose between 2 goats as two rounds, but rather one, as it's the same outcome regardless of which door Monty chooses
:initial_chosen_door, :switched_to_door)
class Round < Struct.new(:car_door,
def won?
car_door == switched_to_door
end
def switched?
initial_chosen_door != switched_to_door
end
end
rounds_switch = []
rounds_noswitch = []
doors = [1,2,3]
doors.each do |car_door|
doors.each do |initial_chosen_door|
(doors - [car_door, initial_chosen_door])[0...1].each do |montys_door|
round_noswitch = Round.new(car_door,
initial_chosen_door,
initial_chosen_door)
round_switch = Round.new(car_door,
initial_chosen_door,
(doors - [initial_chosen_door, montys_door]).first)
rounds_noswitch << round_noswitch
rounds_switch << round_switch
puts "The car was behind: #{car_door}, I didn't switch and chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, I #{round_noswitch.won? ? "won" : "lost"}"
puts "The car was behind: #{car_door}, I did switch and initially chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, and I switched to #{round_switch.switched_to_door}, I #{round_switch.won? ? "won" : "lost"}"
end
end
end
puts "Out of #{rounds_noswitch.size} rounds where I didn't switch, I won #{rounds_noswitch.select { |i| i.won? }.size} times."
puts "Out of #{rounds_switch.size} rounds where I _did_ switch, I won #{rounds_switch.select { |i| i.won? }.size} times."
I figured out the bug. The scenarios where Monty has two doors to choose from, him choosing the first door or the second shouldn't count as 2 rounds, because which door he chooses is irrelevant.
So I tweaked the code as follows, output is omitted. I get the same winningness whether you switch or not (and it adds up to 1 this time ;) ). :initial_chosen_door, :switched_to_door)
class Round < Struct.new(:car_door,
def won?
car_door == switched_to_door
end
def switched?
initial_chosen_door != switched_to_door
end
end
rounds_switch = []
rounds_noswitch = []
doors = [1,2,3]
doors.each do |car_door|
doors.each do |initial_chosen_door|
(doors - [car_door, initial_chosen_door]).each do |montys_door|
round_noswitch = Round.new(car_door,
initial_chosen_door,
initial_chosen_door)
round_switch = Round.new(car_door,
initial_chosen_door,
(doors - [initial_chosen_door, montys_door]).first)
rounds_noswitch << round_noswitch
rounds_switch << round_switch
puts "The car was behind: #{car_door}, I didn't switch and chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, I #{round_noswitch.won? ? "won" : "lost"}"
puts "The car was behind: #{car_door}, I did switch and initially chose #{initial_chosen_door}, Monty revealed the goat behind door: #{montys_door}, and I switched to #{round_switch.switched_to_door}, I #{round_switch.won? ? "won" : "lost"}"
end
end
end
puts "Out of #{rounds_noswitch.size} rounds where I didn't switch, I won #{rounds_noswitch.select { |i| i.won? }.size} times."
puts "Out of #{rounds_switch.size} rounds where I _did_ switch, I won #{rounds_switch.select { |i| i.won? }.size} times."
That may very well be true. On the other hand, I'd much rather hear about the bugs in the code or in the assumptions expressed in the code, because the idea is to demonstrate that it is 2/3 and 1/3 by exhausting all the possibilities. Saying the results are wrong because they don't come out to the expected results doesn't help the code as an argument to convince someone who isn't already convinced of the results. Can you see where I miscounted? Of course you may not be interested in an exhaustive enumeration as proof and may be disinclined to help me ;).
I just went thru all the possibilities exhaustively.
:initial_chosen_door, :switched_to_door)
I look forward to seeing someone complain about my code, I probably did something mathematically wrong
% cat monty_exhaust.rb
class Round < Struct.new(:car_door,
def won?
car_door == switched_to_door
end
def switched?
initial_chosen_door != switched_to_door
end
end
rounds = []
doors = [1,2,3]
doors.each do |car_door|
doors.each do |initial_chosen_door|
(doors - [car_door, initial_chosen_door]).each do |montys_door|
round_noswitch = Round.new(car_door,
initial_chosen_door,
initial_chosen_door)
round_switch = Round.new(car_door,
initial_chosen_door,
(doors - [initial_chosen_door, montys_door]).first)
rounds << round_noswitch
rounds << round_switch
end
end
end
puts "Won when switching %: "
switching_rounds = rounds.select { |r| r.switched? }.uniq
puts switching_rounds.select { |r| r.won? }.size / switching_rounds.size.to_f
puts "Won when wasn't switching %: "
nonswitching_rounds = rounds.select { |r| !r.switched? }.uniq
puts nonswitching_rounds.select { |r| r.won? }.size / nonswitching_rounds.size.to_f
% ruby monty_exhaust.rb
Won when switching %:
0.5
Won when wasn't switching %:
0.333333333333333
So, um don't be a blogger. Get into a profession where you can make a ton of money and not be tearing your hair out from stress. If the goal is to get money, don't lock yourself in a box by saying, "I have to be a blogger, so to make sure I make oodles of cash safely, let's fix blogging."
*applause*
Agreed. Not CN at all, his motives are always pretty clear.
Hehe. George W. Bush, material component for all Dick Cheney's spells.
The reign of terror imposed by GDI can only be ended by GDI+. Or maybe OpenGL.
I see the makings of a Law and Order episode.
Click the grey arrow (triangle) next to the list of existing tags. You're it.
Being able to pass a pointer to a public property (or a pair of getter/setter methods) isn't about bypassing the encapsulation. It's about abstracting away _which_ property (the name of it, and/or even the class or type of the object whose property you are manipulating).
Usable UI fine, but innovative? Why does a web browser's interface need to be innovative?
cute.
And of course by Brawl I meant Melee. Sigh