| Blast from the past |
[Jul. 7th, 2009|01:46 pm] |
Goldie recently (?) posted his BARGE2002 photos to flickr:
http://www.flickr.com/photos/11064896@N05/sets/72157620811088386/
Lots of pics of great people looking about 7 years younger, quite a few are of ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) scottro.
This was my second BARGE, and I'm so bummed that I'm not going to be able to make it this year. Newborns are aparently even *more* work when you've got a two year old.
*saddenz*
[easy photo fun: find a picture of me in there]
[hard photo fun: find a picture of Abdul] |
|
|
| Paul Erdos sucks at math |
[Jul. 5th, 2009|10:40 am] |
He tried to do the Monte Hall problem and got it wrong:
"When told of this, Paul Erdos, one of the leading mathematicians of the 20th century, said, "That's impossible." Then, when presented with a formal mathematical proof of the correct answer, he still didn't believe it and grew angry. Only after a colleague arranged for a computer simulation in which Erdos watched hundreds of trials that came out 2-to-1 in favor of switching did Erdos concede that he was wrong."
[via coding horror] |
|
|
| Great Consolation Prize |
[Jun. 23rd, 2009|07:06 pm] |
|
So yeah, it kind of sucks not to cash in a WSOP event this year. On the bright side though, hgfalling is down to 8 players in the 2500 8-game event with something approaching half the chips. Nothing would be cooler than seeing him take it down. |
|
|
| Last minute invitation to sweat |
[Jun. 14th, 2009|10:45 pm] |
I am heading to vegas tomorrow to play the $10k limit hold'em event, and the $10k stud/8 event. I am inviting people who would like to buy a "sweating share" along the same lines as last year an opportunity to do so. I am setting aside 15% of my action for people who would like to purchase such shares. The deal will be about the same as last year, with the proviso that if you don't transfer me money on PokerStars procrastination and flakiness may eat into the time value of your money. [As an example, I still owe two backers from last year.]
A total of 60 shares will be available. Shares are priced $100 each and get you .25% of my results. That's a 100% markup over par. Each person can buy one share until, first come first served, with the exception that last years backers will be favored over new backers. At 2pm tomorrow, if there are any shares remaining, the foolish may buy as many of the remaining shares as they like.
At 6pm, no more backers will be accepted. Note, since I will not be able to monitor this post regularly tomorrow, please do not comment if you are not interested in purchasing a share.
[I will be updating here and on twitter:andrewprock as technology allows.] |
|
|
| Toddler QOTD |
[Jun. 10th, 2009|07:01 pm] |
|
"Mommy's little, and Daddy's big." |
|
|
| C++ bashing |
[Jun. 8th, 2009|12:11 pm] |
I've been spending the morning going over some what some of the nay-sayers say about c++:
http://esr.ibiblio.org/?p=532
http://yosefk.com/c++fqa/index.html
It's great stuff. C++ is a monster of a language. In a lot of ways it really has a sort of pseduo-intellectual appeal that can sometimes really get in the way of actually writing code. [the obvious example is that I'm spending my morning reading about what the nay-sayers have to say.] Coding in C++ gotten better over the years, due in great part due to maturing libraries, and my own maturing as a programmer. Of course, it still rocks the competition when it comes to performance:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all
C++ clocks in at 30% "better" than Java, and even 15% "better" than C. And it utterly destroys Python, which is 23x worse than C++.
Which brings to light why C++ (and other statically typed languages) will always be around. Surprisingly, it's illustrated in one of the commenters which gets the logic inverted. He writes:
"As for performance, I think that Moore’s Law will eventually erode whatever advantages that C/C++ have in terms of performance."
Well, that's just it. If you're riding exponential (or big polynomial) algorithms, Moore's Law will never get you there. Having that 30% bump locked in can really give you a solid edge on the competition. [And this doesn't even address the fact that in 2002 I bought a 2.53 GHz cpu, and in 2009 I bought a 2.6GHz cpu.]
That said, I would shoot myself if I had to program exclusivly in C++. It really is clunky for a lot of things. And while it is getting better, it'll never be as easy to write as other languages.
[bonus fun fact for those of us who like to work with big data sets: In C++ an object with non-virtual methods can occupy as little space as a single byte; in Java 12 bytes is the minimum. When handling large data sets this frugality can make the difference between success and failure.] |
|
|
| Fun with Google guidelines |
[Jun. 4th, 2009|05:53 pm] |
I'm not the best c++ coder in the world, but freelikebeer pointed me to a great set of guidelines from Google. Overall, they have a lot of good guidelines, some of which I'm using, one or two I might add, and several that I just plain disagree with. Some of the guidelines are just plain goofy and crufty. I suspect that a lot of the odd cruft in their guidelines comes from the fact that they have a large team and are trying to avoid most of the common pitfalls of c++.
Good stuff:
All of the sections Header and Scoping. Most of the Class section and Other C++ section.
Here's a brief rundown of the goofs:
Define functions inline only when they are small, say, 10 lines or less.
Functions should almost universally be defined in an implementation file. The obvious exception is when it's a header only libraray. Having the function definitions spread across files is generally a bad idea since it messes with encapsulation, and makes it difficult to know where to find the code. The other minor exception is when you are dealing with the innermost of innerloops and you absolutly need the speed. In this case, you are probably better off using a static inline function local to the file where the code is.
Do not use a using-directive.
This is wrong, but they clarify what they mean int he comments. They mean do not use a "using namespace" directive. Using std::string is fine.
Make all data members private then later Regular functions have mixed case; accessors and mutators match the name of the variable
Why on earth go through all that work to do encapsulation, and then mandate breaking it in your naming convention? Such an odd policy.
We do not use C++ exceptions.
One of the single best language features to be added in decades and they are like, "meh, we don't want to change old code".
Use streams only for logging.
This is bad as well. They say to use printf instead. But what they don't mention is that printf yeilds undefined behaviour when the types don't match whereas streams don't. It looks like they are just being "lazy" and want to avoid dealing with legacy code.
You should not use the unsigned integer types such as uint32_t
Their code must be an endless mess of static_cast<> if they are using the std library at all. I hope they let people at least use size_t. They've got a really contrived exmple of why you shouldn't use unsigned types. It's as if the only kind of domain error they can think of is negative values. It's so strange that they mandate printf, but forbid unsigned ints because of type safety issues.
Naming
Their the entire naming section is a mishmash, with multiple distinct conventions depending on the context. Not to mention contradictory advice. Mostly it's reads like a set of rules for the sake of making rules. The best one is the one I referred to above, where private data has it's own naming type. *sigh*
Each line of text in your code should be at most 80 characters long.
Aparently at Google, they are all still using VAX terminals, and bench checking their code using daisy wheel printers. If they are going to limit it, it should probably be more like 100 or 120, with liberal allowances for exceptions.
Use only spaces, and indent 2 spaces at a time.
Sections in public, protected and private order, each indented one space.
If this really is a big deal for them, they should have a filter which reformats code when it gets checked in. |
|
|
| The tyranny of the short term |
[May. 28th, 2009|10:24 am] |
The world being what it is, I see a lot of fretting over the current status of the budget. And while I'm somewhat concerned about inefficiencies right now, it's not all that big a deal. Current budget issues are addressing an acute problem. In two to five years the downturn will have stabilized, and the colossal deficits will subside.
Such is the tyranny of the short term. The short term is going to go away, and when it's gone we'll be left with the long term. And that's where the real problem is:
Since the early 1980s the country has been generating higher and higher levels of gross debt. There was a brief respite during the end of the 1990s, but the long term trend has been financing our countries ongoing expenses through the use of credit.
Unfortunately, it seems no one really wants to discuss the long term issue, or reasonable solutions. Nearly all of the rhetoric I hear partisan bickering focusing entirely on the short term. There are occasionally partisans who bring up some long term budget issue (social security, military spending, etc) but only do so in the context of partisanship, not in the context of redirecting the mindset of our society away from reliance on credit.
Until politicians man up and address the fundamental problem with how our country manages finances, we won't escape the natural conclusion, an eventual unwinding of dollar valuation and resultant inflation. Of course, the nice thing about inflation is that it will generally solve a lot of these problems without anyone ever having to take a vote on it. |
|
|
| The goldmine of genetic insight that is correlational reasoning |
[May. 25th, 2009|01:07 am] |
Abstracted statement:
"The idea that Group X does so much better at Activity A than, say Group Y, for a non-genetic reason is going to be seen as being as ridiculous as blah blah blah."
Concretized:
Group X = whites
Group Y = asians
Activity A = winning Oscars
Group X = whites
Group Y = Hawaiians
Activity A = tennis
Group X = Americans
Group Y = Russians
Activity A = winning the Scripps national spelling bee
Clearly whites are genetically better actors than asians, genetically better tennis players than Hawaiians. And Americans are genetically better spellers than Russians. The data is plain as plain can be. And correlationally irrefutable.
Irrefutable I say.
Shall I say it again?
Because saying it over and over again, makes it more and more true.
Really. |
|
|
| Running in place |
[May. 20th, 2009|12:54 pm] |
I just finished a week and a half of redesign and refactoring to finally reach a point where my software works exactly like it did before.
Yay for no-ops. |
|
|
| Abstract Logic |
[Apr. 29th, 2009|10:40 pm] |
Consider the following argument (made recently in the bowels the comments of an LJ troll):
Proposition at hand: Population A is one of the causes of B
Argument:
1) "There is evidence that [A] has a mild but statistically significant tendency to [do things which promote B]"
2) "In other words the blatantly obvious casual route turns out to be true."
Is it just me, or is that a silly position to take? |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}