User talk:Darrellp

From Rosetta Code

An Additional Problem to Try

Now that you've done RCBF in F#, you might also want to try doing RCSNUSP. The logic is actually very similar so it's not a big challenge; you can probably start with your BF interpreter and adapt it. –Donal Fellows 08:48, 25 December 2009 (UTC)

Thanks for doing it! –Donal Fellows 21:23, 27 December 2009 (UTC)

Monty Hall Optimizations

Hi Darrell, could you check this talk page section about a previous Perl implementation that made too many assumptions/optimizations, and make sure that you have not made too many optimisations rather than simulate what happens in the game? Thanks. --Paddy3118 09:13, 27 December 2009 (UTC)

Response to Paddy

I'm new to Rosetta Code so I don't know the "official" way to respond to your request. I have no idea whether you'll ever see this, but here goes...

First of all, thanks for the suggestion. I went ahead and put in a version that explicitly does Monty's pick also. I put in a check to verify that Monty's pick had no effect on what the original code did and, unsurprisingly, that turns out to be the case. In cases like this, it's hard to see what should be "optimized out" and what shouldn't since part of the exercise is to "illustrate" over and above "calculate". I suppose that, in the extreme, you could "simulate" the problem by making the winner always be door 0 (without loss of generality) and also making my observation that in the switch strategy, if you originally pick the winner you lose in the end and vice verce so that the "simulation" consists of picking a random number between 0 and 2 and then checking if it's 0. I'll admit, that doesn't seem like much of a "simulation", though I think it's perfectly valid from a computational point of view. So I think we both agree that it's possible to "optimize out" the actual simulation. I guess it just depends on how far along that scale of "optimization" you're comfortable with. In the end, it feels to me like specifying Monty's pick is kind of like putting in code that specifies that the color of the door as an effort to more closely "simulate" the actual situation. Neither has any impact on the final outcome. Still, I understand that other people can have different feelings along these lines. I'm trying to meet two comfort levels by putting both versions in.

Again, thanks for the polite suggestion!

Hi Darrell, I had intended to check here for responses.
Thanks for the updata to the task. I usually click on the discussion tab at the head of each task just to check on any previous or current issues with a task before adding a new language solution, but in this case, I have been following Monty Hall quite closely and make suggestions to keep the standard up.
In general, I think RC is a site that welcomes new-comers and I think the community would make it easy for anyone to learn from their initial awkward-ness, after all - they might well be judging RC standards for the future. --Paddy3118 13:36, 27 December 2009 (UTC)
Hi, Darell. Sorry to butt in, but I thought I'd drop a note to respond to one of your areas of confusion. There are very few "official" rules. I'm not sure there are any 'rules' that wouldn't be preceded with the phrase "In general," or something similar. I founded RC and maintain the software, and in lieu of any sort of official body of rulemaking, it falls to me if some "official" decision needs to be made. Typically, no official decisions need to be made; In view that I'm perfectly likely to be less knowledgeable on the subject than the rest of the folks around here, I usually only offer opinions. Do what makes sense to you. Just be sure you notice when someone leaves a note in your talk page in case something you did is problematic. Not taking note and discussing prior to further action in such cases is about the only thing you can really do wrong.
Welcome to RC, and I hope your stay is mutually enjoyable. :) --Michael Mol 19:21, 28 December 2009 (UTC)