Not to mention floating-point computation, numerical analysis, anytime algorithms, and classic randomized algorithms like Monte Carlo algorithms. Approximate computing has been around for ages. The typical scenario is to save computation, nowadays expressed in terms of asymptotic complexity ("Big O"). Sometimes (as is the case with floating point), this tradeoff is necessary to make the problem tractable (e.g., numerical integration is much cheaper than symbolic integration).
The only new idea here is using approximate computing specifically in trading high precision for lower power. The research has less to do with new algorithms and more to do with new applications of classic algorithms.
Believe it or not, CIL (or MSIL in Microsoft-speak), the bytecode for.NET, is an ECMA standard, and implementations of both.NET JIT'ers and standard libraries exist for practically all modern platforms, thanks to Mono. So I'd say: "competition for portable applications". Really! Just take a look at Gtk#. As a result, there are numerous applications for Linux written in.NET languages (e.g., Banshee). Having written huge amounts of code in both JVM languages (Java, Scala, JRuby, and Clojure) and.NET languages (F# and C#), I would take.NET over the JVM for a new project any day.
Also, to pre-emptively swat down this counter-argument: while the Mono people and Microsoft may have had some animosity in the past, it is most definitely not the case any more. Most of the Mono people I have spoken to (yes, in person) say that their relationship with Microsoft is pretty good.
Build systems and dependency management for the JVM are their own mini-nightmare..NET's approach isn't perfect but compared to [shudder] Ant, Maven, Buildr, SBT, and on and on and on... it largely just works.
P/Invoke, the other interop mechanism alluded to by the poster, is substantially faster than COM interop. I spent a summer at Microsoft Research investigating ways to make interop for.NET faster. There's maybe 20 or so cycles of overhead for P/Invoke, which is practically free from a performance standpoint. In addition to having its own [reference-counting] garbage collector, COM has extensive automatic-marshaling capabilities. These things make interop easy, but they add substantial overhead compared to P/Invoke. On the other hand, P/Invoke is somewhat painful to use, particularly if you want to avoid marshaling overheads and play nice with.NET's [tracing] garbage collector and managed type system. P/Invoke will often happily accept your ginned-up type signatures and then fail at runtime. Ouch.
Coming from the Java world, I was totally blown away by what.NET can do. I can't speak for Microsoft myself, but I would be very surprised if.NET was not going to stick around for a long time. With the exception of perhaps Haskell, the.NET runtime is probably the most advanced managed runtime available to ordinary programmers (i.e., non-researchers). And, with some small exceptions (BigInteger performance... GRRR!), Mono is a close second. What the Scala compiler is capable of squeezing out of the poor, little JVM is astonishing, but Scala's performance is often bad in surprising ways, largely due to workarounds for shortcomings in the JVM's type system.
Experiments can vary wildly with even small differences in floating-point precision. I recently had a bug in a machine learning algorithm that produced completely different results because I was off by one trillionth! I was being foolish, of course, because I hadn't use an epsilon for doing FP, but you get the idea.
But it turns out-- even if you're a good engineer and you are careful with your floating point numbers, the fact is: floating point is approximate computation. And for many kinds of mathematical problems, like dynamical systems, this approximation changes the result. One of the founders of chaos theory, Edward Lorenz, of Lorenz attractor fame, discovered the problem by truncating the precision of FP numbers from a printout when he was re-entering them into a simulation. The simulation behaved completely differently despite the difference in precision being in the thousands. That was a weather simulation. See where I'm going with this?
There's an interesting project out of Microsoft Research to design a language/IDE that is easy to input via touch interfaces called Touch Develop. I've spoken with one of the researchers at length, and his motivation for doing this boils down to the same argument you make. When he was a kid, programming was simple to get into: he used BASIC on his Apple II. It was a language that kids could teach other kids, because their parents largely didn't "get it". MSR has a pilot program in one of the local high schools where they teach an intro CS course using TouchDevelop. Anecdotally, kids seem to be able to pick up the language very quickly, and the ease of writing games motivates a lot of kids who wouldn't ordinarily be motivated to do this.
That said, I think TouchDevelop's interface (like most of Metro) is a bit of a train wreck. I am a professional programmer, but I find myself floundering around. Part of the issue is Metro's complete annihilation of the distinction between text, links, and buttons. Unfortunately, iOS 7 has continued in this trend. But I digress...
TouchDevelop is also not a graphical language, like LabView, and I also think that's a bit of a mistake. While I agree that I prefer a text-based language for real work, I think a visual interface would be entirely appropriate for a pedagogical language. Heck, LabView is used daily by lots of real engineers who simply want some basic programmability for their tools without having to invest the [significant] time into learning a text-based language.
Counting operations is not enough. Memory access time is nonuniform because of cache effects, architecture (NUMA, distributed memory), code layout (e.g., is your loop body one instruction larger than L1 i-cache?), etc. Machine instructions have different timings. CISC instructions may be slower than their serial RISC counterparts. Or they may not be. SMT may make sequential code faster than parallel code by resolving dependencies faster. Branch predictors and speculation can precompute parts of your algorithm with idle function units. Better algorithms can do more work with fewer "flops". And on and on and on...
The best way to try to write fast code is to write it and run it (on representative inputs). Then write another version and run it. Run it like an experiment, and do an hypothesis test to see which one has the statistically-significant speedup. That's the only way to write fast code on modern machines. The idea that you can hand-write fast code on modern architectures is largely a myth.
We rarely refer to the cost of an algorithm in terms of flops, since it is bound to change with 1) software implementation details, 2) hardware implementation details, and 3) input data dependencies (for algorithms with dynamical properties). Instead, we describe algorithms in "Big O" notation, which is a convention for describing the theoretical worst-case performance of an algorithm in terms of n, the size of the input. Constant factors are ignored. This theoretical performance figure allows apples-to-apples comparisons between algorithms. Of course, in practice, constant factors need to be considered for many specific scenarios.
"flops" are more commonly used when talking about machine performance, and that's why they're expressed as a rate. You care about the rate of the machine, since that often directly translates into performance. Computer architects also measure integer operations per second, which is in many ways more important for general-purpose computing. Flops are really only of interest nowadays for people doing scientific computing now that graphics-related floating point things have been offloaded to GPUs.
If you want to be pedantic, computers are, of course, hardware implementations of a Turing machine. But it's silly to talk about them using Big O notation, since the "algorithm" for (sequential) machines is mostly the same regardless of what machine you're talking about. The constant factors here are the most important thing, since these things correspond to gate delay, propagation delay, clock speed, DRAM speed, etc.
Microsoft doesn't use Perforce. They use an ancient, crappy fork of Perforce called Source Depot. I had to endure this piece of garbage while I interned at Microsoft. I can only guess that it's institutional momentum-- SD is so bad that I ended up using Subversion locally and then I would periodically sync back to SD when I needed to share my code. Not only does Source Depot lack run-of-the-mill Subversion features like "svn status", when I asked people what the SD equivalent was, a long conversation ensued with other Microsoft developers in which somebody ended up sending me a Powershell script. Gah. Of course, the number 1 thing I missed there was the UNIX shell.
That said, I was pleasantly surprised by the rest of Microsoft's toolchain. Having come from Eclipse (awful), IntelliJ (OK), and Xcode (baffling), Visual Studio was great. Visual Studio is so much better than any other IDE that I've ever used, that I would actually pay full price for it (I get the "Microsoft alum" discount) if I didn't have to use it on Windows. And Microsoft was more than willing to let me write code in F#, which was fantastic. In general, Microsoft takes care of their devs. Having integrated git is just icing on the cake.
Just as a bit of historical context: Sid Meier/Microprose used to have a favorably-priced service that offered backup disks for a few bucks. I suspect that the reason for this, at the time, was because few people (myself included) had more than one floppy drive. I took advantage of this to acquire copies of F19 Stealth Fighter and Railroad Tycoon. Sadly, I have since lost those games, although I should point out: you can get many old games, DRM-free, at GOG for next to nothing.
I think copyright is OK. As the creator of a work, you should be able to license it however you please. Many bits of software are a true labor of love, and I think that authors should be compensated for their work. Just because you do not agree with them does not mean that the law is unjust.
However, I think that copy-protection is extremely misguided. Fair-use exemptions aside, I believe that society should be allowed to archive these things, at least for historical reasons. Actually, there's a funny story about this-- I know a researcher at Microsoft who wrote a relatively famous Apple II game in the early 1980's, when he was a high school student. One of his recent projects has been developing software to get kids into programming, which is much more complicated than when we were kids hacking on Apple, Commodore, and TI machines ourselves. To prove his point, he fired up his old Apple II game in an emulator during the presentation, and he showed the kind of code that produced a game like his; simple stuff using BASIC. But that game-- he had lost it years ago, and he had to resort to using the cracked version floating around on the Internet. I couldn't get him to comment on the merits of copy protection, but I think the lesson is pretty clear.
I should also point out that I think that modern copyright terms are completely ridiculous. 15 years ought to be a reasonable amount of time to capitalize on your work before the public gets the benefit.
I have no affiliation with GOG, but I should point out that you can get your SMAC fix there as well.
Yeah, but there's a reason why statistical models are hot now and why the old AI-style of logical reasoning isn't: the AI stuff only works when the input is perfect, or at least, planned for. As we all know, language doesn't really have rules, just conventions. This is why the ML approach to NLP is powerful: the machine works out what was probably meant. That's far more useful, because practically nobody writes well. When Abdur Chowdhury was still Twitter's main NLP guy, he visited our department, and guess what-- people even write in more than one language in a single sentence! Not to mention, in the old AI-style approach, if you fill a big box full of rules, you have to search through them. Computational complexity is a major limiting factor in all AI problems. ML has this nice property that you can often simply trade accuracy for speed. See Monte Carlo methods.
As you point out, ML doesn't "understand" anything. I personally think "understanding" is a bit of a squishy term. Those old AI-style systems were essentially fancy search algorithms with a large set of states and transition rules. Is that "understanding"? ML is basically the same idea except that transitioning from one state to another involves the calculation of a probability distribution, and sometimes whether the machine should transition is probabilistic.
I think that hybrid ML/AI systems-- i.e., systems that combine both logical constraints and probabilistic reasoning-- will prove to be very powerful in the future. But does that mean these machines "understand"? If you mean something like what happens in the human brain, I'm not so sure. Do humans "understand"? Or are we also automata? In order to determine whether we've "cracked AI", we need to know the answers to those questions. See Kant and good luck.
This is not true. While complicated software can be difficult to test, and really complicated software can often only be evaluated empirically, straightforward, mathematical software you care deeply about can be reasoned about formally, even in the presence of unusual inputs. Quantifying the behavior of algorithms is, in fact, the purpose of computer science. I don't have a deep knowledge of financial algorithms, but it would surprise me if their analysis was markedly different from other algorithms. Often, best-case, worst-case, and average-case analysis for performance/runtime can be carried out, and even with nondeterministic algorithms, bounds can be put on the likelihood of their error. Good software engineering practices (using types or assertions, which would have eliminated this particular error) can also prevent your formal assumptions from being violated. It sounds to me like the people who wrote this particular algorithm did none of this. But the presence of mistakes like this don't make the idea of algorithmic trading inherently risky.
In the interest of creating a well-functioning system, I think system designers should try to catch these errors. If errors only affected the one party who made the mistake, your proposal might be worth considering, but in fact, these errors affect people who have nothing to do with it, simply because they participate in the market. Thus, it is better to eliminate errors altogether.
The most obvious fix is that negative trades should not be allowed. Even better would be a type system which expresses valid order sizes. But even within the range of valid orders, some order sizes are more likely than others. Given the volume of orders, it ought to be pretty easy to characterize the distribution of order sizes-- I think a smarter system should flag outlying order sizes for secondary human review. This is a pretty easy check to implement, and it surprises me that it doesn't already exist in the system.
While ZMM certainly borrows some ideas from eastern philosophy, this is not the central point of the book. Eastern thinking is mainly used as a counterpoint to the classical Western way of thinking.
I've read ZMM about seven times. I get something different out of it on every read. It is an attempt to apply rational thinking to the idea of rationality itself, in addition to just being a great story. The section on 'gumption traps' is worth the price of admission alone.
I suppose you could say that, because that's what lots of people think, but it's not quite true. COM is alive and well, and indeed, lots of.NET is hooked into it.
Disclaimer: Today was my last day at Microsoft, in their PL research group.
In my opinion, someone who knows their way around the various interoperability issues with Windows/UNIX is what you really should be asking for. Some things are easy (did you know that Active Directory offers LDAP and Kerberos services?), but other things are harder (domain trusts with non-Windows machines). Somebody who has experience integrating Samba with a fairly recent Windows domain will tend to have a pretty good idea how the entire ecosystem works.
I am also biased, because I am a programmer, but I think that anyone who spends time programming on a Windows machine is going to have a great deal more understanding than someone who just reads about how things work in books. For one, they don't throw their hands up in the air when they can't solve something-- they poke and prod and eventually program their way out of it. IT workers with programming experience aren't the easiest people to find (and Windows hackers seem to be more elusive than UNIX hackers for cultural reasons), but they're out there. I did this for years. Anyway, someone who can answer "What's the difference between COM and.NET?" probably has a pretty good idea how Windows is put together.
I work with a former Microsoft intern about whom I have a similar story. Microsoft plans a "special event" every summer for its interns, and they're often things like cruises or concerts. So I asked him-- what was your special event? He said, "Oh, it was just some wedding band or something. Totally boring." I later found out that it was Dave Matthews Band. Gah.
I ditched Gentoo when the "rolling release" schedule you so highly praise decided to upgrade libc. Practically the entire system stopped working. I haven't touched Gentoo since 2005, so maybe things are better now, but it left a bad impression.
The part you're missing though is services-- that's Apple's diversity. Apple has gone to extraordinary lengths to ensure that all of its physical products are tied to services that you need to pay to use. With the iCloud, they don't just want you to pay once, they want you to pay regularly.
There are many millions of people with their music and videos in iTunes AAC/M4V format. Given the choice between buying a (let's suppose) superior music player/phone and ditching their media collection or just buying another iPhone and retaining their library, I think most people will choose the latter. Sure, us nerds can move that music to another (non-Apple) machine, but the vast majority of people: 1) can't do this, or 2) can't be bothered to do this.
I have a hard time seeing how Android is diverse and Apple's iPhone is not. There's a HUGE ecosystem for the iPhone.
I recently traveled to China for a conference, and this exact question was a recurring thought to me. Aside from the restrictions on the internet (no Facebook, Google mostly doesn't work), and the large number of bored-looking (and sometimes sleeping-on-the-job) police, there were few reminders that the place was communist. To me, it seemed very much like a developing nation-- people were entrepreneurial and resourceful. To me, the main difference between the US and China for your average person is that many more Chinese live in what we'd consider poverty, and that the people there are not exactly safety-conscious.
No worries about the male assumption-- I am indeed male, and my spouse is my wife. I actually wrote 'spouse' because I wasn't sure if you were male or not;)
I am married, and presently, have no kids, although this is going to change in the near future. Fortunately, my advisor also had his children while he was in graduate school, and he is quite understanding on the matter. But this varies quite a bit. My first advisor, who left the university permanently to pursue a startup (he had exhausted his sabbatical leave), told another of my labmates point blank that my labmate's decision to have children in graduate school was "the worst decision he ever made." So I've seen both extremes. What it boils down to is, yes, it's possible, no, it's not easy.
I am very fortunate in that I have an extremely understanding and patient wife. This does not mean that she doesn't have her moments of impatience, but she has dealt with my busy schedule and general unavailability (like, right now I am on the west coast of the US and she is on the east coast while I am on internship) fairly well. We took turns doing graduate school-- her first-- and so I am very fortunate in that she is the primary breadwinner. She's a doctor. My salary pays our apartment rent, and the rest of it goes into savings. Anyway, the fact that we took turns, and that I supported her while she was in school, is the reason why I am starting graduate school later in life.
If my wife were not OK with this situation, it would not be worth it, at all. One thing I realized about myself while pursuing a PhD is that I am capable of learning most of this stuff on my own. The role that professors, advisors, mentors, and [most especially] your peers play in your education is primarily to steer you into asking the right kinds of questions. This is the problem-- when you're an outsider, you don't know how to solve your problems because you don't even know how to ask them. Figuring out how to ask them has a huge search space. There are scads of ways to set a problem up, but which one is best? The people around you will take your half-coherent ramblings and sharpen them into the kinds of pointed questions that you can ask and, by turning the appropriate cranks, get an answer. In any case, the point of this is: if I blow it now, I'm OK with it. I know I can hack it by myself-- it'll just take longer.
Your list of priorities may currently look something like this:
1. Spend time with family.
2. Do well at work.
3. Chores.
4. Fun hobby #1
5. Fun hobby #2
n. Fun hobby #n
What you need to know is that the list will be transformed into something like this:
1. Do research for advisor.
2. Do classwork.
3. Spend time with family.
That's right. ALL of your fun hobbies will go away, and your wife and children will have to pick up your slack on chores. This is why you need to have a frank conversation with them. If they're not ready to do this, for the next 6 years, you should reconsider.
I am able to maintain a steady income with my side jobs, yes. But my primary side-job is providing bugfixes for the employer I left when I came to grad school. They were disappointed that I was leaving, and I explained that my time was going to be very valuable, and that I needed to be compensated in a manner to account for this. But if you aren't able to make a prior arrangement, I would not count on side-money. Research is your #1 priority, and they will pay you roughly $20-25k a year for this job. The way many of my peers do it (and I would say that about 1/4 of them are married, maybe an 1/8 have kids), is that they put their families on the fairly generous university benefits packages offered to grad students (often free health care and discounted daycare), their salaries go toward rent and food, and their spouses pick up the rest.
If your wife can't do this for you, grad school is not for you. I don't say that to be mean. You m
Your post is wrong on several aspects. I know this, because a few years ago I was in exactly the same boat at the person who submitted this question, and now I am mid-PhD in CompSci.
Firstly, a PhD can open doors to many jobs outside academia, as an industry researcher. While it's true that there are many "pure" research labs in industry anymore, even the "unpure" labs give you a great deal of leeway on your chosen research topic. Often the payout has to be "plausible in the near term". But if you can't achieve this, then you're probably not much of a researcher anyway. In any case, there are industry labs at IBM, Microsoft, Google, PARC, HP, NEC, Samsung, VMWare, Intel, and numerous other smaller places. I have friends or acquaintances working at ALL of those places this summer, and I am presently at MS. You cannot get a job in one of these research labs unless you have a PhD or are in the middle of working on one (i.e., an internship).
Also, I'm not sure what you mean by "on 20k a year". If you mean that you have to pay 20k a year-- no. Any PhD program worth its salt will pay you. If you mean that you earn 20k a year, well, yes, that's in the ballpark. But that doesn't account for summer internships (which for me, double my pay), and side jobs, which are numerous and lucrative for someone with the specialized technical knowledge that a grad program brings. I have turned down a number of offers, because my compensation is satisfactory, and I would rather spend my free time being free.
You need to think of a PhD like this: it's an apprenticeship. This is why it is absolutely crucial that you seek out who you want to work with before you apply to various CS programs. Your entire graduate research agenda will be shaped by your advisor. Also, even if your prospective advisor likes you and wants to bring you into his or her lab, they may not be able to due to funding constraints. A graduate student costs roughtly $100k a year in salary, benefits, conference travel, tuition, and research costs (for CS). If you come with money attached (i.e., you've applied for and received a scholarship/fellowship), your arguments will be much more persuasive.
Many of the faculty I have spoken with prefer older students, because they're more focused and persistent than younger students. However, older students are also riskier-- their lives are more complex, and the possibility that they will have to drop out due to family, health, or personal reasons is higher.
Also, if you want a PhD, apply for a PhD. An MS will not help your admissions case at all, except for one thing: academic contacts. Now, academic contacts are pretty important-- in fact, letters of reference are probably the most important part of your graduate application. But if you think that an MS will shorten the amount of time to receive a PhD, in many cases, that's wrong. My own program considers very little prior graduate work toward your PhD; at best you can exempt out of one or two classes, but you still must pass our version of the qualifying exam (actually a thesis-like project) and all other requirements stay the same.
Now, as everyone here has said, getting a PhD is not a rosy experience. I was 31 when I entered graduate school. I was a mixture of commercial programmer and IT worker for the previous 10 years (it was a small shop where the IT guy really did do everything). I left because, although my job paid well, I had great coworkers, and I worked on important problems that let me keep my head in code all day, it wasn't satisfying to me. I have always wanted to design programming languages, and from the small amounts of literature I was able to understand, it was a deep topic with a long history. Entering grad school was the best decision for me, despite the large pay cut, because I now do the things I've always wanted to do. I have three research projects in the pipeline, with my first paper coming out in October. The hours are terrible, yes-- y
Slashdot Mirror
My mind inevitably goes to this when someone says "Big O". Makes being a computer scientist somewhat difficult.
Not to mention floating-point computation, numerical analysis, anytime algorithms, and classic randomized algorithms like Monte Carlo algorithms. Approximate computing has been around for ages. The typical scenario is to save computation, nowadays expressed in terms of asymptotic complexity ("Big O"). Sometimes (as is the case with floating point), this tradeoff is necessary to make the problem tractable (e.g., numerical integration is much cheaper than symbolic integration).
The only new idea here is using approximate computing specifically in trading high precision for lower power. The research has less to do with new algorithms and more to do with new applications of classic algorithms.
Exactly..
Believe it or not, CIL (or MSIL in Microsoft-speak), the bytecode for .NET, is an ECMA standard, and implementations of both .NET JIT'ers and standard libraries exist for practically all modern platforms, thanks to Mono. So I'd say: "competition for portable applications". Really! Just take a look at Gtk#. As a result, there are numerous applications for Linux written in .NET languages (e.g., Banshee). Having written huge amounts of code in both JVM languages (Java, Scala, JRuby, and Clojure) and .NET languages (F# and C#), I would take .NET over the JVM for a new project any day.
.NET's approach isn't perfect but compared to [shudder] Ant, Maven, Buildr, SBT, and on and on and on... it largely just works.
Also, to pre-emptively swat down this counter-argument: while the Mono people and Microsoft may have had some animosity in the past, it is most definitely not the case any more. Most of the Mono people I have spoken to (yes, in person) say that their relationship with Microsoft is pretty good.
Build systems and dependency management for the JVM are their own mini-nightmare.
P/Invoke, the other interop mechanism alluded to by the poster, is substantially faster than COM interop. I spent a summer at Microsoft Research investigating ways to make interop for .NET faster. There's maybe 20 or so cycles of overhead for P/Invoke, which is practically free from a performance standpoint. In addition to having its own [reference-counting] garbage collector, COM has extensive automatic-marshaling capabilities. These things make interop easy, but they add substantial overhead compared to P/Invoke. On the other hand, P/Invoke is somewhat painful to use, particularly if you want to avoid marshaling overheads and play nice with .NET's [tracing] garbage collector and managed type system. P/Invoke will often happily accept your ginned-up type signatures and then fail at runtime. Ouch.
.NET can do. I can't speak for Microsoft myself, but I would be very surprised if .NET was not going to stick around for a long time. With the exception of perhaps Haskell, the .NET runtime is probably the most advanced managed runtime available to ordinary programmers (i.e., non-researchers). And, with some small exceptions (BigInteger performance... GRRR!), Mono is a close second. What the Scala compiler is capable of squeezing out of the poor, little JVM is astonishing, but Scala's performance is often bad in surprising ways, largely due to workarounds for shortcomings in the JVM's type system.
Coming from the Java world, I was totally blown away by what
Experiments can vary wildly with even small differences in floating-point precision. I recently had a bug in a machine learning algorithm that produced completely different results because I was off by one trillionth! I was being foolish, of course, because I hadn't use an epsilon for doing FP, but you get the idea.
But it turns out-- even if you're a good engineer and you are careful with your floating point numbers, the fact is: floating point is approximate computation. And for many kinds of mathematical problems, like dynamical systems, this approximation changes the result. One of the founders of chaos theory, Edward Lorenz, of Lorenz attractor fame, discovered the problem by truncating the precision of FP numbers from a printout when he was re-entering them into a simulation. The simulation behaved completely differently despite the difference in precision being in the thousands. That was a weather simulation. See where I'm going with this?
There's an interesting project out of Microsoft Research to design a language/IDE that is easy to input via touch interfaces called Touch Develop. I've spoken with one of the researchers at length, and his motivation for doing this boils down to the same argument you make. When he was a kid, programming was simple to get into: he used BASIC on his Apple II. It was a language that kids could teach other kids, because their parents largely didn't "get it". MSR has a pilot program in one of the local high schools where they teach an intro CS course using TouchDevelop. Anecdotally, kids seem to be able to pick up the language very quickly, and the ease of writing games motivates a lot of kids who wouldn't ordinarily be motivated to do this.
That said, I think TouchDevelop's interface (like most of Metro) is a bit of a train wreck. I am a professional programmer, but I find myself floundering around. Part of the issue is Metro's complete annihilation of the distinction between text, links, and buttons. Unfortunately, iOS 7 has continued in this trend. But I digress...
TouchDevelop is also not a graphical language, like LabView, and I also think that's a bit of a mistake. While I agree that I prefer a text-based language for real work, I think a visual interface would be entirely appropriate for a pedagogical language. Heck, LabView is used daily by lots of real engineers who simply want some basic programmability for their tools without having to invest the [significant] time into learning a text-based language.
Counting operations is not enough. Memory access time is nonuniform because of cache effects, architecture (NUMA, distributed memory), code layout (e.g., is your loop body one instruction larger than L1 i-cache?), etc. Machine instructions have different timings. CISC instructions may be slower than their serial RISC counterparts. Or they may not be. SMT may make sequential code faster than parallel code by resolving dependencies faster. Branch predictors and speculation can precompute parts of your algorithm with idle function units. Better algorithms can do more work with fewer "flops". And on and on and on...
The best way to try to write fast code is to write it and run it (on representative inputs). Then write another version and run it. Run it like an experiment, and do an hypothesis test to see which one has the statistically-significant speedup. That's the only way to write fast code on modern machines. The idea that you can hand-write fast code on modern architectures is largely a myth.
As a computer scientist:
We rarely refer to the cost of an algorithm in terms of flops, since it is bound to change with 1) software implementation details, 2) hardware implementation details, and 3) input data dependencies (for algorithms with dynamical properties). Instead, we describe algorithms in "Big O" notation, which is a convention for describing the theoretical worst-case performance of an algorithm in terms of n, the size of the input. Constant factors are ignored. This theoretical performance figure allows apples-to-apples comparisons between algorithms. Of course, in practice, constant factors need to be considered for many specific scenarios.
"flops" are more commonly used when talking about machine performance, and that's why they're expressed as a rate. You care about the rate of the machine, since that often directly translates into performance. Computer architects also measure integer operations per second, which is in many ways more important for general-purpose computing. Flops are really only of interest nowadays for people doing scientific computing now that graphics-related floating point things have been offloaded to GPUs.
If you want to be pedantic, computers are, of course, hardware implementations of a Turing machine. But it's silly to talk about them using Big O notation, since the "algorithm" for (sequential) machines is mostly the same regardless of what machine you're talking about. The constant factors here are the most important thing, since these things correspond to gate delay, propagation delay, clock speed, DRAM speed, etc.
I know we're probably not going to read the articles, but... can't we have a link just for old time's sake?
Microsoft doesn't use Perforce. They use an ancient, crappy fork of Perforce called Source Depot. I had to endure this piece of garbage while I interned at Microsoft. I can only guess that it's institutional momentum-- SD is so bad that I ended up using Subversion locally and then I would periodically sync back to SD when I needed to share my code. Not only does Source Depot lack run-of-the-mill Subversion features like "svn status", when I asked people what the SD equivalent was, a long conversation ensued with other Microsoft developers in which somebody ended up sending me a Powershell script. Gah. Of course, the number 1 thing I missed there was the UNIX shell.
That said, I was pleasantly surprised by the rest of Microsoft's toolchain. Having come from Eclipse (awful), IntelliJ (OK), and Xcode (baffling), Visual Studio was great. Visual Studio is so much better than any other IDE that I've ever used, that I would actually pay full price for it (I get the "Microsoft alum" discount) if I didn't have to use it on Windows. And Microsoft was more than willing to let me write code in F#, which was fantastic. In general, Microsoft takes care of their devs. Having integrated git is just icing on the cake.
Just as a bit of historical context: Sid Meier/Microprose used to have a favorably-priced service that offered backup disks for a few bucks. I suspect that the reason for this, at the time, was because few people (myself included) had more than one floppy drive. I took advantage of this to acquire copies of F19 Stealth Fighter and Railroad Tycoon. Sadly, I have since lost those games, although I should point out: you can get many old games, DRM-free, at GOG for next to nothing.
I think copyright is OK. As the creator of a work, you should be able to license it however you please. Many bits of software are a true labor of love, and I think that authors should be compensated for their work. Just because you do not agree with them does not mean that the law is unjust.
However, I think that copy-protection is extremely misguided. Fair-use exemptions aside, I believe that society should be allowed to archive these things, at least for historical reasons. Actually, there's a funny story about this-- I know a researcher at Microsoft who wrote a relatively famous Apple II game in the early 1980's, when he was a high school student. One of his recent projects has been developing software to get kids into programming, which is much more complicated than when we were kids hacking on Apple, Commodore, and TI machines ourselves. To prove his point, he fired up his old Apple II game in an emulator during the presentation, and he showed the kind of code that produced a game like his; simple stuff using BASIC. But that game-- he had lost it years ago, and he had to resort to using the cracked version floating around on the Internet. I couldn't get him to comment on the merits of copy protection, but I think the lesson is pretty clear.
I should also point out that I think that modern copyright terms are completely ridiculous. 15 years ought to be a reasonable amount of time to capitalize on your work before the public gets the benefit.
I have no affiliation with GOG, but I should point out that you can get your SMAC fix there as well.
Yeah, but there's a reason why statistical models are hot now and why the old AI-style of logical reasoning isn't: the AI stuff only works when the input is perfect, or at least, planned for. As we all know, language doesn't really have rules, just conventions. This is why the ML approach to NLP is powerful: the machine works out what was probably meant. That's far more useful, because practically nobody writes well. When Abdur Chowdhury was still Twitter's main NLP guy, he visited our department, and guess what-- people even write in more than one language in a single sentence! Not to mention, in the old AI-style approach, if you fill a big box full of rules, you have to search through them. Computational complexity is a major limiting factor in all AI problems. ML has this nice property that you can often simply trade accuracy for speed. See Monte Carlo methods.
As you point out, ML doesn't "understand" anything. I personally think "understanding" is a bit of a squishy term. Those old AI-style systems were essentially fancy search algorithms with a large set of states and transition rules. Is that "understanding"? ML is basically the same idea except that transitioning from one state to another involves the calculation of a probability distribution, and sometimes whether the machine should transition is probabilistic.
I think that hybrid ML/AI systems-- i.e., systems that combine both logical constraints and probabilistic reasoning-- will prove to be very powerful in the future. But does that mean these machines "understand"? If you mean something like what happens in the human brain, I'm not so sure. Do humans "understand"? Or are we also automata? In order to determine whether we've "cracked AI", we need to know the answers to those questions. See Kant and good luck.
This is not true. While complicated software can be difficult to test, and really complicated software can often only be evaluated empirically, straightforward, mathematical software you care deeply about can be reasoned about formally, even in the presence of unusual inputs. Quantifying the behavior of algorithms is, in fact, the purpose of computer science. I don't have a deep knowledge of financial algorithms, but it would surprise me if their analysis was markedly different from other algorithms. Often, best-case, worst-case, and average-case analysis for performance/runtime can be carried out, and even with nondeterministic algorithms, bounds can be put on the likelihood of their error. Good software engineering practices (using types or assertions, which would have eliminated this particular error) can also prevent your formal assumptions from being violated. It sounds to me like the people who wrote this particular algorithm did none of this. But the presence of mistakes like this don't make the idea of algorithmic trading inherently risky.
In the interest of creating a well-functioning system, I think system designers should try to catch these errors. If errors only affected the one party who made the mistake, your proposal might be worth considering, but in fact, these errors affect people who have nothing to do with it, simply because they participate in the market. Thus, it is better to eliminate errors altogether.
The most obvious fix is that negative trades should not be allowed. Even better would be a type system which expresses valid order sizes. But even within the range of valid orders, some order sizes are more likely than others. Given the volume of orders, it ought to be pretty easy to characterize the distribution of order sizes-- I think a smarter system should flag outlying order sizes for secondary human review. This is a pretty easy check to implement, and it surprises me that it doesn't already exist in the system.
But clicking is such hard work!
While ZMM certainly borrows some ideas from eastern philosophy, this is not the central point of the book. Eastern thinking is mainly used as a counterpoint to the classical Western way of thinking.
I've read ZMM about seven times. I get something different out of it on every read. It is an attempt to apply rational thinking to the idea of rationality itself, in addition to just being a great story. The section on 'gumption traps' is worth the price of admission alone.
Definitely my favorite book.
I suppose you could say that, because that's what lots of people think, but it's not quite true. COM is alive and well, and indeed, lots of .NET is hooked into it.
Disclaimer: Today was my last day at Microsoft, in their PL research group.
In my opinion, someone who knows their way around the various interoperability issues with Windows/UNIX is what you really should be asking for. Some things are easy (did you know that Active Directory offers LDAP and Kerberos services?), but other things are harder (domain trusts with non-Windows machines). Somebody who has experience integrating Samba with a fairly recent Windows domain will tend to have a pretty good idea how the entire ecosystem works.
.NET?" probably has a pretty good idea how Windows is put together.
I am also biased, because I am a programmer, but I think that anyone who spends time programming on a Windows machine is going to have a great deal more understanding than someone who just reads about how things work in books. For one, they don't throw their hands up in the air when they can't solve something-- they poke and prod and eventually program their way out of it. IT workers with programming experience aren't the easiest people to find (and Windows hackers seem to be more elusive than UNIX hackers for cultural reasons), but they're out there. I did this for years. Anyway, someone who can answer "What's the difference between COM and
I work with a former Microsoft intern about whom I have a similar story. Microsoft plans a "special event" every summer for its interns, and they're often things like cruises or concerts. So I asked him-- what was your special event? He said, "Oh, it was just some wedding band or something. Totally boring." I later found out that it was Dave Matthews Band. Gah.
I ditched Gentoo when the "rolling release" schedule you so highly praise decided to upgrade libc. Practically the entire system stopped working. I haven't touched Gentoo since 2005, so maybe things are better now, but it left a bad impression.
The part you're missing though is services-- that's Apple's diversity. Apple has gone to extraordinary lengths to ensure that all of its physical products are tied to services that you need to pay to use. With the iCloud, they don't just want you to pay once, they want you to pay regularly.
There are many millions of people with their music and videos in iTunes AAC/M4V format. Given the choice between buying a (let's suppose) superior music player/phone and ditching their media collection or just buying another iPhone and retaining their library, I think most people will choose the latter. Sure, us nerds can move that music to another (non-Apple) machine, but the vast majority of people: 1) can't do this, or 2) can't be bothered to do this.
I have a hard time seeing how Android is diverse and Apple's iPhone is not. There's a HUGE ecosystem for the iPhone.
How is China a Communist state?
I recently traveled to China for a conference, and this exact question was a recurring thought to me. Aside from the restrictions on the internet (no Facebook, Google mostly doesn't work), and the large number of bored-looking (and sometimes sleeping-on-the-job) police, there were few reminders that the place was communist. To me, it seemed very much like a developing nation-- people were entrepreneurial and resourceful. To me, the main difference between the US and China for your average person is that many more Chinese live in what we'd consider poverty, and that the people there are not exactly safety-conscious.
No worries about the male assumption-- I am indeed male, and my spouse is my wife. I actually wrote 'spouse' because I wasn't sure if you were male or not ;)
I am married, and presently, have no kids, although this is going to change in the near future. Fortunately, my advisor also had his children while he was in graduate school, and he is quite understanding on the matter. But this varies quite a bit. My first advisor, who left the university permanently to pursue a startup (he had exhausted his sabbatical leave), told another of my labmates point blank that my labmate's decision to have children in graduate school was "the worst decision he ever made." So I've seen both extremes. What it boils down to is, yes, it's possible, no, it's not easy.
I am very fortunate in that I have an extremely understanding and patient wife. This does not mean that she doesn't have her moments of impatience, but she has dealt with my busy schedule and general unavailability (like, right now I am on the west coast of the US and she is on the east coast while I am on internship) fairly well. We took turns doing graduate school-- her first-- and so I am very fortunate in that she is the primary breadwinner. She's a doctor. My salary pays our apartment rent, and the rest of it goes into savings. Anyway, the fact that we took turns, and that I supported her while she was in school, is the reason why I am starting graduate school later in life.
If my wife were not OK with this situation, it would not be worth it, at all. One thing I realized about myself while pursuing a PhD is that I am capable of learning most of this stuff on my own. The role that professors, advisors, mentors, and [most especially] your peers play in your education is primarily to steer you into asking the right kinds of questions. This is the problem-- when you're an outsider, you don't know how to solve your problems because you don't even know how to ask them. Figuring out how to ask them has a huge search space. There are scads of ways to set a problem up, but which one is best? The people around you will take your half-coherent ramblings and sharpen them into the kinds of pointed questions that you can ask and, by turning the appropriate cranks, get an answer. In any case, the point of this is: if I blow it now, I'm OK with it. I know I can hack it by myself-- it'll just take longer.
Your list of priorities may currently look something like this:
1. Spend time with family.
2. Do well at work.
3. Chores.
4. Fun hobby #1
5. Fun hobby #2
n. Fun hobby #n
What you need to know is that the list will be transformed into something like this:
1. Do research for advisor.
2. Do classwork.
3. Spend time with family.
That's right. ALL of your fun hobbies will go away, and your wife and children will have to pick up your slack on chores. This is why you need to have a frank conversation with them. If they're not ready to do this, for the next 6 years, you should reconsider.
I am able to maintain a steady income with my side jobs, yes. But my primary side-job is providing bugfixes for the employer I left when I came to grad school. They were disappointed that I was leaving, and I explained that my time was going to be very valuable, and that I needed to be compensated in a manner to account for this. But if you aren't able to make a prior arrangement, I would not count on side-money. Research is your #1 priority, and they will pay you roughly $20-25k a year for this job. The way many of my peers do it (and I would say that about 1/4 of them are married, maybe an 1/8 have kids), is that they put their families on the fairly generous university benefits packages offered to grad students (often free health care and discounted daycare), their salaries go toward rent and food, and their spouses pick up the rest.
If your wife can't do this for you, grad school is not for you. I don't say that to be mean. You m
Your post is wrong on several aspects. I know this, because a few years ago I was in exactly the same boat at the person who submitted this question, and now I am mid-PhD in CompSci.
Firstly, a PhD can open doors to many jobs outside academia, as an industry researcher. While it's true that there are many "pure" research labs in industry anymore, even the "unpure" labs give you a great deal of leeway on your chosen research topic. Often the payout has to be "plausible in the near term". But if you can't achieve this, then you're probably not much of a researcher anyway. In any case, there are industry labs at IBM, Microsoft, Google, PARC, HP, NEC, Samsung, VMWare, Intel, and numerous other smaller places. I have friends or acquaintances working at ALL of those places this summer, and I am presently at MS. You cannot get a job in one of these research labs unless you have a PhD or are in the middle of working on one (i.e., an internship).
Also, I'm not sure what you mean by "on 20k a year". If you mean that you have to pay 20k a year-- no. Any PhD program worth its salt will pay you. If you mean that you earn 20k a year, well, yes, that's in the ballpark. But that doesn't account for summer internships (which for me, double my pay), and side jobs, which are numerous and lucrative for someone with the specialized technical knowledge that a grad program brings. I have turned down a number of offers, because my compensation is satisfactory, and I would rather spend my free time being free.
You need to think of a PhD like this: it's an apprenticeship. This is why it is absolutely crucial that you seek out who you want to work with before you apply to various CS programs. Your entire graduate research agenda will be shaped by your advisor. Also, even if your prospective advisor likes you and wants to bring you into his or her lab, they may not be able to due to funding constraints. A graduate student costs roughtly $100k a year in salary, benefits, conference travel, tuition, and research costs (for CS). If you come with money attached (i.e., you've applied for and received a scholarship/fellowship), your arguments will be much more persuasive.
Many of the faculty I have spoken with prefer older students, because they're more focused and persistent than younger students. However, older students are also riskier-- their lives are more complex, and the possibility that they will have to drop out due to family, health, or personal reasons is higher.
Also, if you want a PhD, apply for a PhD. An MS will not help your admissions case at all, except for one thing: academic contacts. Now, academic contacts are pretty important-- in fact, letters of reference are probably the most important part of your graduate application. But if you think that an MS will shorten the amount of time to receive a PhD, in many cases, that's wrong. My own program considers very little prior graduate work toward your PhD; at best you can exempt out of one or two classes, but you still must pass our version of the qualifying exam (actually a thesis-like project) and all other requirements stay the same.
Now, as everyone here has said, getting a PhD is not a rosy experience. I was 31 when I entered graduate school. I was a mixture of commercial programmer and IT worker for the previous 10 years (it was a small shop where the IT guy really did do everything). I left because, although my job paid well, I had great coworkers, and I worked on important problems that let me keep my head in code all day, it wasn't satisfying to me. I have always wanted to design programming languages, and from the small amounts of literature I was able to understand, it was a deep topic with a long history. Entering grad school was the best decision for me, despite the large pay cut, because I now do the things I've always wanted to do. I have three research projects in the pipeline, with my first paper coming out in October. The hours are terrible, yes-- y