deep learning
In 2006, after visiting the Computer History Museum's exhibit on Chess [https://blog.codinghorror.com/chess-computer-v-human/], I opined: > We may have reached an inflection point. The problem space of chess is so astonishingly large that incremental increases in hardware speed and algorithms are unlikely to result in
algorithms
I graduated with a Computer Science minor from the University of Virginia in 1992. The reason it's a minor and not a major is because to major in CS at UVa you had to go through the Engineering School, and I was absolutely not cut out for that
algorithms
One of my all time favorite blog entries is a truly epic tale of dating gone wrong that culminates in the strangest reference to P=NP you'll probably ever encounter. Joey: So you really did graduate from computer engineering? New Girl: Yes I did, from UBC! Joey: And
computer science
Have you ever heard a software engineer refer to a problem as "NP-complete"? That's fancy computer science jargon shorthand for "incredibly hard": The most notable characteristic of NP-complete problems is that no fast solution to them is known; that is, the time required to
file copy
If you've used Windows Vista, you've probably noticed that Vista's file copy performance is noticeably worse than Windows XP. I know it's one of the first things I noticed. Here's the irony-- Vista's file copy is based on
algorithms
In my previous post on shuffling, I glossed over something very important. The very first thing that came to mind for a shuffle algorithm is this: for (int i = 0; i < cards.Length; i++) { int n = rand.Next(cards.Length); Swap(ref cards[i], ref cards[n]); } It'
arrays
Pop quiz, hotshot. How would you write code to shuffle a deck of cards? I was thinking about this after reading Mike's card-shuffling algorithm woes: Here's where the non-CS mind comes into play. My first thought was to generate an unshuffled deck as an array-like structure