IvoDankolov

Not just for the user - calling asynchronous tasks using the new C# or VB keywords is so mind-bogglingly easy that you'll just have no excuse not to do it when writing apps.

Even the use cases that are not covered by the two keywords, like fetching a whole bunch of stuff together or issuing a lot of requests and having the data trickle in as they are completed one by one are handled easily with the Task API, to the point where you have WhenAny and WhenAll methods and you just do "await Task.WhenAll(tasks)".

Aye, as someone who didn't have many expectations (though I didn't expect Windows 8 to be a failure either, I'm not one to rage about changing the sacred desktop look), throughout the keynote and this video they managed to pleasantly surprise me many times.

The design aside (which is an entire topic on its own), some of the functionality decisions like contracts just make you wonder why the sodding hell didn't we have these sooner. I mean there's the half-baked drag and drop handler than no one actually bothers to implement even when it makes absolute sense to do so, and that's it. Being able to pull things out of a web service from the file picker, on the other hand, just makes me go "I want this yesterday."

From what I can tell it's just a convention in their APIs for binding continuations. You do some WinRT asynchronous call and pass a func to the then method to run when it completes. Nothing more than a onFinished event.

No changes to async programming at all, events and continuations as always.

For me, it's kind of the default state of mind, building models of reality, and I can go as far as doing it unconsciously. Just a few hours ago I was in a friend's office talking to him about 3D models and through no conscious decision of mine I started twiddling around with a perforator. The point where I realized what my purpose had been was when I broke the flow of the conversation with the complete non-sequitur, "oh, now I know what that twiddly part on a spring does - you pull it and lock the perforator making it more compact".

I know other people that do that too. For some of us, the immediate reaction to a new thing is "ooh, shiny, how does it work? Let's run some experiments." The scientific mindset is useful, I think, no matter what you wish to exploit.

Interesting, though it's balanced only on average. I suppose it's possible that you can both get elements inserted in order and have the random priorities selected in decreasing order. The chance of ending in a worst case for a tree of non-trivial size would be exceedingly low so I don't see it causing much issue in practice. It is random, though, and sometimes you might prefer systems that are deterministic (say if you absolutely can't afford bad cases).

Anyway, when it comes to simplicity I will admit it is much more appealing than red-black trees and their 5 billion cases for insert and delete - none of them unreasonable, true, but I didn't like debugging that thing at all the first time I attempted to implement it. So, yeah, that's something you can reliably implement when you don't have time/ can't be bothered to look up the ridiculously complicated stuff and you just want to dish out a fast data structure that you know works (binary heap - 1, suffix tree - 0, treap - 1, RBTree - 0).

As for the problem, it should be quite simple if you just keep tabs on the element count on the left and right subtrees, which is small price to pay (under a few million elements, but even with you're working with hundreds of millions - suck it up and buy an extra gig of ram). Something like this pseudocode (hopefully with added error checking) :

  pos n root =
    if root.right.count >= n then
      pos n root.right
    else if n == 1 || root.right.count - n == 1 then
      (root.key, root.value)
    else
      pos (n - root.right.count) root.left

Overall, quite an interesting mix of ordered (search) trees and heaps, I like it.

Oh, don't get me wrong, I have no trouble with multiple outcomes, or to put it in a different way, the whole wavefunction being real. Otherwise you'd have a pretty strange time explaining interference ("oh, one thing is real, but it considers the other possibilities anyways" or "oh no, the waveform hasn't collapsed just yet, but it will once we observe it"). In fact, the Feynman path integral, i.e. the sum over all histories, appeals a lot to me on a conceptual level.

But that isn't the point really. I just feel like saying "oh, it's in some weird quantum state of being both this and that at the same time" is a bit disingenuous, since it is not true in any classical sense, which, shockingly, most people would assume and get utterly confused. It is necessarily true if you consider many worlds as the valid interpretation (which I do like, but let's not go there), but it doesn't I think hint that well enough, nor does it hint that we have entered a cloud of possibilities that is about to collapse if that was the point.

More than just being clear on what is physically happening (and I do say "oh, it's just equations, they have no meaning" is the biggest hand waving of all), it feels kind of immature. The tone hints to a confusion in the speaker, as if we've just gotten these strange experimental results and we're not sure how to deal with them yet. It's something that could've been acceptable when practically nothing was known about quantum mechanics, but more than half a century later?

And to be perfectly fair, I'm not sure how you would phrase the wavefunction / amplitude distribution to at least give someone without knowledge of the subject a workable model. Maybe the inferential distance is too long to even have a not completely wrong intuition, but I feel we can do better.

  And if the first photon was in some weird quantum state, where it can’t be said to have struck the atoms or not, the second photon will be both extra-delayed and not extra-delayed at the same time.

Maybe it's just me, but these always come out sounding massively hand-wavy and scare off a lot of people (or make you look like an idiot, depending on how much respect they have for physicists). I think the fix would be mostly a matter of coming up with terminology that doesn't fall flat on its ass, but still remains accessible, because, on the other hand, speaking of amplitude distributions would kind of alienate a lot of people.

Anyway, much more importantly - it's a clever little engineering trick to entangle the two photons. However, and I will say I have not researched the topic of quantum computing - doesn't operating them require interference between the different branches of the system at some point to get meaningful results? If so, you would need to get two or more branches to end up in exactly the same state, and nothing in the article mentions that the cesium atoms that have been altered will reset without outside influence.

Anyway, I put the conditional probability that I know everything about the system or quantum mechanics awfully close to 0, so it's more of a curiosity (how would you make it work?) instead of a genuine concern.

Interesting - the mode bit is kind of in the lines of contract programming, only the type system is good enough so that the compiler can check them for you.

I feel like there's much ground to explore in the realm of stronger guarantees. In plain old C, there is absolutely no way to guarantee that a function will not do anything obnoxious and just return a result. That is largely true for most "mainstream" languages, which are all more or less inspired by C and its predecessors (ALGOL). In fact, in Javascript it goes so far that you can't trust the object prototypes because any of them can be changed.

True, common sense and coding conventions dictate that you simply shouldn't write things prone to be impossible to debug and break random pieces of code in an unrelated part of the project. That is not the problem, though - getting bugs because you've forgotten a side effect somewhere is quite a common occurrence. And besides - how much do you trust external libraries not to do the same (obviously not an issue when it has a large open source community, but that is not always the case)?

Now, on the other end of the spectrum we have things like the monads in Haskell, which are basically computations/side effects in a box. We have contract programming to guarantee the structure of the data. Pure functions that you simply know that you can call in whatever order and however many times you want and the result will always be the same, with nothing breaking behind the curtains.

It would be interesting to take these ideas of managing effects and having a stronger type system back to a C-style language and seeing how they work out. At the very least I'd certainly be happy to never dereference another null pointer ever again, for instance, or calling a writing function and knowing that it can't delete my data (placing your own guarantees is kind of moot when a function can access all of the standard library in the background). In a sense, it's like how you don't have to worry about a function leaking memory or memmoving into your own stuff in a garbage collected language that doesn't expose memory management.

Oh, first Visual Studio Python integration and now this. I really have no excuse not to learn Python. Honestly, I've been meaning to learn it for a while, but Haskell sucked out all of my "goofing around with programming" time and I'll be damned if I didn't enjoy it.

Time to put the "rapid prototyping" claim to the ultimate test, I guess. Even better, I have no idea what I'll be prototyping - just going to wing it all the way through. It should prove interesting.

I had to do a double take when I saw Bayes's theorem on that illustration - "wait a second, did I read that domain name correctly"?

Even more surprising is that they would use the terminology of prior and posterior probabilities and the like, applied correctly. It gives one the impression that the author knows what he is talking about.

I don't know how motivating this article would be to someone without training in probability theory, though. I mean, it's all well and good to be factually correct, but showering people outside of the field with technical terms and "weird" claims can, I think, be very counterproductive.

Concerning the theorem itself, no effort was actually made to at least rephrase it in a more friendly way. It's not enough to just poke fun at yourself with "(trumpets sound here)". Many people, even with formal mathematical training do not intuitively understand why it is true, and without that, applying it for probability calculations would feel like hollow and mindless mechanical work.

To that effect, I also recommend Eliezer's explanation, found at [0]. I must admit that I kind of glossed over it, because I had the correct intuition regardless of not formally knowing the theorem (no idea how to reproduce that, unfortunately, because it would be a pretty good tool), but even so, I found it both funny and informative. And as a bonus, it doesn't assume that you have any rigorous training in mathematics (a common misconception among mathematical explanations).

[0] : http://yudkowsky.net/rational/bayes

  "Even now, mathematics students are expected to learn complicated (e- d)-proofs in analysis with no help in understanding the logical structure of the arguments. Examiners fully deserve the garbage that they get in return."

Oh yes, speaking from personal experience, calculus professors are so guilty of that one - "oh, don't worry that you don't know formal logic, use your intuition", "let's fix our delta to be epsilon / ( 2 * (b-a) ). Don't worry, it will work out".

And more generally, many of the academics I know seem to be underestimating the inferential distance to their students not by one, but by a dozen or so degrees. And then they're surprised that 75% of the would-be computer scientists with questionable interest in formal mathematics fail. Surprised!

It's certainly not the only fallacy going around, but it can be surprisingly pervasive.

As for the book. I've only read a very small part of it, but if it does turn out to be a comprehensible description of the basics of mathematics - well, it's something that would benefit a lot of people if it gained mainstream attention.

To be fair, going from a less syntactically rich syntax to an almost complete superset of it isn't too hard. Yet, to draw from that the conclusion that javascript, or any other modern language of that family is pretty much the same seems like too much of a stretch to me. I just don't buy the argument that "oh, pretty much no one uses the new syntax" invalidates it.

One usually doesn't go around designing features around what an idiot would use. And to ignore a feature on that exact point, I think, completely misses how much modern compilers can do for you. I'd very much like to see converting something that uses yield[0] to generate collections in C#, or handling variable capture and anonymous functions to, say, C, by just twiddling around with the syntax.

[0] : I have working lazy evaluated collections in C++, complete with state machine generating code. It is not, by any stretch of the imagination, pretty to implement. However, being able to say - naturals()->Map([](int x) { return 2 * x; })->Take(N); - can be pretty satisfying.

Following the details link on youtube yields what wtracy found. Looking around the site, I managed to dig this [0] up, which, judging by the filename, will be used in their Siggraph talk. Unfortunately, it is still very brief and doesn't expand much on the preview. Here's [1] the paper that it references, which does give more detail about voxel rendering.

Though I haven't looked very much into the techniques in voxel rendering, it seems animation, to this point, has been only a theoretical possibility and a huge setback. That Crassin et al. can achieve a reasonable framerate on such complex scenes struck me as a very big achievement. We'll probably have to wait a few more months for more details, though.

[0] : http://artis.imag.fr/Publications/2011/CNSGE11a/GIVoxels_Sig...

[1] : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.158...

Bare in mind that you also need to somehow do a brain scan with enough resolution to map every single connection if you want something functional. Also, what are you going to do about the sensory inputs (sight, hearing, nervous system). I'm sure it can't be good for a person's sanity to suddenly get completely 100% disconnected from the world.

And while a 1:1 map of the brain would maybe be feasible to do at the moment or in a few years, but very expensive (although getting ever cheaper), it's kind of like the straw-man AI researcher's answer to everything : do a neural network, repeat training set and hope that it computes what we want. Trying to flaunt your lack of knowledge and trying clever ways to avoid solving the problem yourself is just asking for trouble in so many ways.

In the end, the point is that AI is a software problem. Adding hardware will allow you a more stupid approach in solving it, but effective solutions are those that matter most.

I wonder whether this has any practical use. Touch screens already remove physical feedback and it's very hard to use them with your eyes closed when you can't confirm your actions in any other way than looking, unless you have accessibility software. Now, with this "invisible touch screen", not only can you not see the phone, but instead of moving your fingers on a smooth surface, you use something that is neither smooth or comfortable and it certainly isn't the same shape as an iPhone screen.

Besides all that, when the technology can detect any gesture, why limit ourselves to arbitrarily tapping our hand. It would be a lot more useful to just bind a few simple gestures to features that you use often.

This article was very painful to read.

> "It actually explains a few of the trickier things about quantum physics, like why particles have an indeterminate position until they're observed."

And then it goes on in the next paragraph, of all things, to assert that most of the people are "computer controlled".

The whole thing has the general attitude of ... ooh, we're living in a SIMULATION, let's make some random assumptions that sound audacious. We don't have to care if they hold up for more than a microsecond under scrutiny, because it's a simulation!

And while that's an exaggeration, the word simulation does provide an easy excuse, a semantic stop sign as it were, to avoid thinking about the implications of your idea beyond "hmm, that would be cool."

Fortunately, that's not how it works. Also, as to the whole "simulating only what's needed" is in the category of easier said than done. QM might be locally computable at each step, but you can't factor out a part of the universe without affecting its state. And don't even get me started on the problems you'll have if you try to cut out things all the way up at the human level.

Since I first heard about CUDA and ran the N body simulation with hundreds of bodies in real time on a cheap GeForce 8500 I became aware of how good of a parallel processor these things are.

Of course, had I learned about how the rendering pipeline for graphics works it would have been obvious, but that only came later.

After that, I've always wondered how feasible it would be to write an OS for regular users (there are CUDA supercomputers, but that isn't very representative of how most people make use of computers) that makes use of the GPU for various computations other than graphics. Hopefully, this project will shed some light in that direction.

I don't really don't like the wording of the author - "infinity + 1" - because it isn't. The omegas are used to describe the ordering of the set and not, in any way, the "magnitude" of the infinity.

Well, I guess the catch phrase "infinity is a number - an infinite number of numbers" is just too good of a "deep wisdom" that people repeat it regardless of how much sense it makes.

Anyway, omega + 2 tells us, to put it simply, that we have a countably infinite subset, followed by a finite subset of two elements. In the same way, omega + omega would mean one countably infinite subset followed by another.

Note that this has no bearing whatsoever in the magnitude of the set. No matter how many omegas you add, you can still project the result onto the "basic" set of natural numbers. The labels don't matter, you aren't limited by the author's example of splitting even/odd. You can try it with sets {x, xx, xxx, ...} and {y, yy, yyy, ...} and they still project onto the naturals just fine.

Actually, n! / (2! * (n-2)!) comes out exactly at n * (n-1)/2. It's just one form of the general formula for combinations.

However, multiplying the possible situations is, of course, wrong. A case of a wrong explanation of the final result I'd imagine (permutations instead of combinations),