IvoDankolov

Lovely effect! Particularly enjoyed how it seems to 'fake' refraction by sampling higher or lower from the background based on the drop shape. The trails squishing back into raindrops to simulate surface tension is also a pretty nice touch, though perhaps a bit over-exaggerated.

One caveat is the merging of the drops sometimes looks quite unnatural, but I'm not sure there's any simple way to represent that as just a couple of textures and a transformation, as real drops would have attractive forces on a molecular level pulling them towards one another once they're bridged, deforming pretty unevenly.

It's due to the day/night buttons being anchor tags as opposed to any Safari-specific issue.

If you wanted to keep the the ability to link to specific states, but avoid the history issue, you'll need to use the History API — https://developer.mozilla.org/en-US/docs/Web/API/History/rep...

Well, all of supervised learning is basically approximating an unknown function from a finite list of samples.

But it's still an approximation, with things like e.g. backpropagation 'simply' (in the abstract mathematical sense) tweaking weights in the direction of the derivatives to get closer to expected values.

The vast majority of machine learning just builds on that by going deep (more layers), automatically generating inputs (e.g. in game AIs playing against themselves), etc.

One might argue that's even worse than function optimisation as you can only vaguely guess at the target and thus all your validation is suspect and you have to prove it using humans by, for instance, beating them at Starcraft.

Yes, you are missing something, which is a bit of a quirk of C++. Normally, having two functions with the same signature in a parent and child class results in overloading.

  struct A 
  {
      void f() {std::cout << "A";}
  };

  struct B : A
  {
      void f() {std::cout << "B";} 
  };
  //.,...
  A a = B();
  B b = B();
  a.f();
  b.f();
  b.A::f();

This would print ABA, as the child's f() function simply hides the parent one when working in the context of B(), but it does not override it.

Now, what virtual does is it tells the compiler, "from here on out, resolve clashing signatures for this function in child classes by overriding. I'm sure you know how our example changes when you mark f() as virtual.

That's all old news, though. The more interesting bit, final, acts like so: from here on out, prevent overloading in child classes. Now, that only makes sense in the context of virtual, so that's the only place where you're allowed to use final, and here the actual difference to the first example becomes apparent. You see, final does not negate virtual, what it actually does is completely lock up the function signature from being used in any child classes. Adding virtual final to our example would not cause B's function to hide A's - it will simply not compile.

If you think that's all pointless semantics, you are absolutely right. Locking up names is not the point of "final". In fact, declaring something as virtual final in the base class is completely pointless from any practical standpoint. The actual problem that final is meant to solve is this:

As I mentioned earlier, virtual changes the way resolving names works in child classes forever. These two pieces of code are absolutely equivalent.

  struct A 
  {
      virtual void f() {std::cout << "A";}
  };

  struct B : A
  {
      void f() {std::cout << "B";} 
  };

And:

  struct A 
  {
      virtual void f() {std::cout << "A";}
  };

  struct B : A
  {
     virtual void f() {std::cout << "B";} 
  };

Therein lies an interesting dilemma. What if I wanted to prevent any child class of B, and only B, from changing the implementation of f. Under C++03, that is not possible. In C++11, final solves that.

But why go through the trouble of introducing a new keyword - and a keyword that is only a keyword in class and function declarations to boot (Holy context dependent grammar, Batman!) - and not just drop the virtual qualifier? Backwards compatibility - ever a dreaded thing when you wish you could undo your old mistakes.

It isn't all that big of a deal (said the C++ developer about every strange rule in the language, ever), though, since when you use "final" for the intended purpose, you won't actually be needing the virtual qualifier.

  struct A 
  {
      virtual void f() {std::cout << "A";}
  };
  
  struct B : A
  {
      void f() final {std::cout << "B";} 
  };
  
  struct C : B
  {
      void f(); //I'm afraid I can't let you do that.
  };

Could you be a bit more specific as to what you find confusing? Is it:

- That you can use the name of a variable, h, as if it was a function? That's because Javascript has first class functions [1] - the language is defined to support passing them around as variables and calling them like that.

- That you can use h at all even though it's neither a local variable nor a parameter of the anonymous function? That's because functions in javascript aren't simply procedures in the traditional sense - i.e. description (function signature) + code - they are also closures [2]. If you declare one function inside another, it can capture (have a reference to) variables and parameters of the outer one. You are also guaranteed that local variables and parameters will not get cleaned up while a closure still exists that holds a reference to them.

[1] : http://en.wikipedia.org/wiki/First_class_function

[2] : Can't vouch for any particular article, try googling Javascript closures

In what terms do you think you "understand" it?

What do you make of this problem with distant entangled particles? The double slit experiment and interference in general? The Heisenberg uncertainty principle? (Or as I'd like to call it, Heisenberg's horribly mislabeled-in-order-to-confuse-students principle)

A shot in the dark - many of the problems with coming to terms with quantum mechanics arise from trying to impose on it that it should somehow behave like classical mechanics, or that somehow we humans stand above it and look down upon it, and heaven forbid that we're part of a qunatum system).

It's always amusing to see the kind of excuses that pop up when you try to explain entanglement or interference in the mindset of wavefunction collapse.

I'm still not entirely sure why so many people consider collapse to be simpler. Is it too daunting to think of the world as an amplitude distribution that propagates in a way that we're not intuitively used to? Too hard to think of ourselves as part of quantum mechanics, because that thing I see there on the measuring device must be the reality, damn it, and what the hell do you mean I've just entangled myself and the device along with the system?

Or maybe just tradition and accepting the "scripture" coming from the established authority. How could we best test that?

But when you "collapse the wavefunction" and "create" the internal state of the particle, do you also create the internal state of the other one that is entangled to it? Do you create it instantaneously?

You see, the problem is not whether you can transfer information in human readable form (though if you could that would certainly be a huge problem with relativity!), but whether any effect that propagates faster than the speed of light exists.

You'll have a hard time explaining that in the frame of wavefunction collapse, I think.

The way I've usually seen this one presented involves precisely the observation, in that you gain knowledge of the other particle. Of course, saying "because it was always a ~k particle" does not a good explanation make, because that would imply that the resolution of the measurement was somehow predetermined, which is a fancy way of saying that there's a hidden variable.

Not that interpreting all of this to mean that physics is non-local "spooky-action-at-a-distance" is the only viable route, mind.

Consider this: why, exactly, do you believe that when you measure the particle you somehow force it to enter one particular state and therefore the entangled one that's sitting X miles away suddenly enters the opposite one? Are we, humans, sitting outside of quantum mechanics and looking down upon it - and then what we observe is the one true way the world is?

Why would you not, instead, when you measure the particle, entangle the measuring device, and yourself, with the state of the particle? You are, after all, only another part of quantum mechanics the same as anything else.

Yes, I can quite easily think of Graham's number - I call it G.

You might think that I'm saying that in jest, but it is actually the way of things. There are quite literally an infinite number of numbers. Why should Graham's be important enough for us to consider. For that matter, why should we consider 1?

The answer lies in part in the question - why - it must be important in some way. That is exactly the case - we only consider numbers that, for some reason, relate to problems we are facing, whether it be in mathematics, programming, or grocery shopping, and even then not on their own merits. Past a certain point, you don't hold numbers in your head as little balls, but rather their decimal encoding. That's a clever hack, but not without its downsides. Ask some people randomly if they were in a position to decide, how much budget would they allocate to save 10000 birds, and ask others the same with 100000 birds. The mean of the second answer would not be ten times that of the first (unless your subjects know and actively try to work around that particular bias).

But back to Graham's number - if you think the only way to imagine it is to hold its decimal notation in your head - the obvious question is why? Why not hexadecimal? Octal? Why any base-p encoding at all? The usual reason to use base-10 is to quickly get an idea of the magnitude of a number relative to things we are familiar with and do some simple arithmetical manipulations on it. Both of these are pointless for Graham's number. Relative to familiar things like billions and trillions it's quite a ways of the chart, and adding, subtracting, or even raising to powers of such makes relatively no difference.

Besides which, in this case it isn't really pointless, it's impossible. Jokes about collapsing into black holes aside, there aren't enough bits of information in the universe to encode the decimal representation of Graham's number. There aren't enough bits of information to encode the number of digits of that. Not enough even to encode the number of digits of the number of digits. Interestingly, there also aren't enough bits to encode the number of times you'll have to repeat taking the base-10 logarithm to get back to a universal scale.

Which goes to show that not only your mind, but no entity in the universe can accomplish the feat of representing an arbitrary number in decimal notation, mathematician or otherwise. And what is the point, really? G is a perfectly good symbol, and so is g_64. Usefulness is important, not imagining a string of balls. For that matter, I bet you've been perfectly content to use Pi on at least a few occasions, even though in terms of representability in decimal, it is infinitely worse than Graham's number.

Yes, in fact F# has that built in as |> , which I've taken to using in Haskell as well. Though it's a bit more intuitive to me when it has the lowest precedence like so:

    (|>) :: a -> (a->b) -> b
    (|>) x f = f x
    infixl 0 |>

There infixl 0 means infix operator with left associativity and 0 precedence.

Then you can use all sorts of expressions inbetween:

     (5 + 3 |> show) ++ " times" |> putStrLn

Also, tying this back to one of the article's ideas, this piping-like syntax for doing things really manages to take away the emphasis from the function and put it back on the data. It isn't all about functions after all!

Well, surprisingly, that would only be as strong as doing OCR to get the words.

Why is that? Well, if you deliberately remove words that are easy to put back into the sentence, it's an easy task not because we humans are incredible at "out of the box" thinking, but because one or two word choices are orders of magnitude more likely than all the rest.

And when it comes to statistical guessing, computers are very good at that. Get a large enough corpus of the English language, and I can assure you that the probability distribution of the missing word, given that it's preceded by "I can't stand all" and followed by "your lies" is overwhelmingly in favor of "of".

Calculating these conditional probabilities is not a very hard task to program at all, though it does require quite some computational power and memory for longer chains.

I'd say this reads more like an ad than an explanation. The first paragraph is totally a sales pitch, then they invite you to use the product and constantly nag on about how awesome it is.

And anyway, marketing aside it's not really a good explanation at all. It's way too abstract to be of any practical use, completely obvious and revealing no information to someone who has made compilers, and completely opaque and, once again, revealing nothing to someone who hasn't.

That's a shame, really. If it works as advertised it would be a really interesting piece of tech. I don't want to know that it parses C# and then converts that tree to one for Java. How else would you do it? On the other hand, how exactly does the mapping from .NET classes to Java ones work? Does the converter also handle coding style and not just syntax and semantics? More importantly, how would you go about doing that?

Overall, I'm not terribly impressed with their transparency.

Actually, what you have written is not foldl, it's foldr. Why is it going right to left? Let's expand your example:

    (foldl * 1 '(1 2 3))
    (* 1 (foldl * 1 '(2 3))
    (* 1 (* 2 (foldl * 1 '(3))))
    (* 1 (* 2 (* 3 (foldl 1 '()))))
    (* 1 (* 2 (* 3 1)))
    ...
    6

Basically, the calls to * start nesting into each other, so the one that actually gets evaluated first is the rightmost one.

What would actually be foldl is this:

    (define (foldl fn accum lst)
       (if (null? lst)
            accum
            (foldl (fn accum (car lst)) (cdr lst))
       )
    )

Now if you expand this (dropping the tail recursion):

    (foldl * 1 '(1 2 3))
    (foldl * 1 '(2 3))
    (foldl * 2 '(3))
    (foldl * 6 '())
    6

And even though you think that such a tiny thing can't be a good implementations, it actually is super efficient. The tail recursion is automatically optimized for you (and you can assume that for any functional language - it's a very crucial optimization for this style of code, after all). That's what the core of it will be in an actual implementation, though with added error handling, type checking and so on.

P.S. unlike haskell, in Racket you don't really need to fold the basic operators, they take variable arguments, so you can just:

    (apply * (list 1 2 3))

in order to get it to run on a list.

Correlation does not imply causation? Statisticians like to use that one at every opportunity.

Bear in mid, though, that "you shouldn't investigate correlations anyway" is absolutely the wrong conclusion from this.

Was there really a need to put "legitimate" in quotes every single time?

More seriously, though, it shows that the legal system has put itself, perhaps unwittingly, in unexplored and potentially very volatile territory.

Most times, a warrant does not affect at lot of people in the grand scheme of things. Potentially inconveniencing an innocent household is, all things considered, not a big deal. But a warrant that affects quite literally millions of people, which cannot possible be all guilty - dangerous, that.

I wonder if this will force some changes in the way seizure of property is handled. I suppose it depends on how much of a "shitstorm" it continues to cause.

If you ask me, TA should be the more glorious position. There's just no point in speaking the same thing in front of 200 students every (half) year in front of 200 people with little to no interactivity. So what's the point of having that person in front of the class and not some recording?

Oh, right, there isn't one. There hasn't been for some years now, but the academia has had neither internal nor external incentives to innovate. Some might say giving the students the best possible experience should be an intrinsic motivation for professors. A shame it doesn't work that way.

I think though that TAs in Coursera/Udacity are not active enough. Given that tens of thousands (hundreds?) take a course, they can't afford to be. It makes me think that this model is not sustainable either.

I mean, in our day and age, dabbling in an area of science/art should not be a hard or expensive thing to do. And if you're willing to find your own information, it mostly isn't. But if everyone wanted to dabble in computer science and learn some basics, there just aren't enough TAs in the world to provide assistance.

There certainly would be enough learners, though! And I think that's a much more sustainable model. Udacity and Coursera both have active forums, I've heard Salman Khan mention it, and even in that "Intoduction to AI class" that did not have discussion forums from the start, people organized study groups, forums and subreddits all on their own.

Let's make it "cool" to study together and help others. Social routines will do the rest.

Well, yes, and the scathing tone of it is pretty thick, at least when I read it in my head. I was commenting on the idea, not the exact wording of it. It's just the first appropriate quote that I grabbed from the text.

    No access code means a lower grade, all in the best interests of science.

I ... no. I can't even...

I'm sorry, but I find it very hard to summon an inkling of sympathy for the publishers' plea against piracy when I see measures like that.

When I failed calculus because I didn't prove a theorem the way it was in the lecture notes and then was insane enough to argue the point, I thought it was pretty stupid. Here, I don't think the word even begins to describe the situation.

Commodity. That's a good way of describing the role of the students. It shows a rather alarming failure of the system that instead of incentivizing the pursuit of knowledge, students are set up for failure and milked for as much money as possible during their education.

I know a patent doesn't mean much in the grand scheme of things, and I do hope that most people in a position to make decisions in education call it out for being stupid, though I feel that's a tad optimistic. I'm just sad that a professor is the one proposing this. There go my non-existent beliefs in academia.

Good security is safe in spite of knowing exactly how it works. While revealing the exact details does not make an algorithm less vulnerable, it should not make it more so.

And if it turns out that you are using a flawed solution, talking about it early will, at the very least, get people to yell at you as to what you should do instead.

In this age, the best security algorithms are usually the one most talked about. The more you test it and the more people you get to look at it and write theorems and papers about size of the search space, results from various attacks and so forth, the better.

But that doesn't matter at all if the attacker is targeting your algorithm in particular.

Say my algorithm is to pick the password "1" * 1000 (that's the character 1 repeated 1000 times) and also pretend that 90% of the sites didn't have stupid limits and it was a valid password. It's certainly a long password. The time it would take to brute force it by testing all possible strings in order of increasing length is an unimaginable number. It's not on the scale of the universe - not on the scale of a million universes either.

But now let's say that this "the more characters the better" became a universal truth and everyone jumped on the same bandwagon and did the same quick hack of having 1000 1s. Suddenly, we're all screwed, because the algorithm "pick 1000 ones" is staggeringly weak. In fact, it provides no protection at all - the attacker already knows your password.

The true measure of security measures is not how long they last when no one knows about them - it's how long they last when everybody knows. "Pick 10 random symbols" will last for a while. "Pick 'password'", not even a second.

Where does "pick a meaningful English sentence" fall on the grand scale? That's one incredibly hard question to answer. It's also bloody difficult to break, for reasons of generating sentences, not password entropy.

I do agree on that point, but I'm not sure if pragmatic is the right word. Need of a specialized work environment, perhaps. Programming needs one, too, I suppose, but it just happens to be a computer.

Approaching other subjects the same way we do math and programming would be quite monumentally stupid. Could you trust a "doctor" to make the right decisions if his/her experience consists of watching lecture videos on YouTube and answering quizzes?

However, should we completely give up on those fields that require specialized practice? I see it as more of a challenge than a reason to despair. For one thing, you can combine online education with offline practice (provided willingness of all parties involved to experiment with new approaches, which is certainly not a trivial thing to ask). Also, an approach I'd try is having games that simulate the real-world task as close as possible. At some point, you probably would need specialized equipment and/or test subjects. Reducing that to a minimum, though, is in my opinion a very good thing, as it would drive down the cost of education.

I've received one of these emails as well. Almost makes you wonder how much would offline university degrees be worth in a few years.

Objectively, this is not a new idea. We have been talking about revolutionizing education for years - and free online education is pretty much the ideal. There is even enough material about most scientific fields and areas of study (some are more open than others, though) to become an expert.

So what is the problem? Becoming an expert with enough authority for people to actually listen to you. Easy enough to do it on your own in programming or entrepreneurship you might say. Not so easy in medicine or biochemistry (though I will admit I have no first-hand experience).

In that regard, certifications are a significant next step, provided that they get wide enough acknowledgement. That is the next battlefront, I think - convincing industries, governments and academia that online education is the way to go.

As Geee stated, it's about imitating the lighting of the scene. There's all sorts of subtle and not-so-subtle effects that come as a result of light bouncing around.

While it may be obvious when a virtual object is missing a shadow (as in the demonstration video), even implementing that would not be enough to fool the human brain completely, though it isn't always obvious what the problem is, only a subconscious nagging.

If you're interested in what precisely the effects that the real world has and augmented reality generally doesn't have - i'd say the biggest ones are shadows (including soft shadows [0]), depth of field [1], ambient occlusion [2], and indirect lighting.

You don't necessarily have to write a full-blown raytracer with global illuminasion, casting billions of rays to get a passable result. All of the above mentioned things can more or less be approximated in some way, and most modern game engines do so (I don't know of any phone games that do, mind, as the calculations are still non-trivial, but I do remember an interesting tech demo from Nvidia).

The biggest problem, though, is that we can do these things in a controlled setting, where you know the exact shape, texture and light reflective properties on every object in the scene. As you can imagine, that is not so in the case of augmented reality (as I quipped in my earlier post, you would have to infer surface reflectance from the image in some way). Compared to the problem of global illumination in a virtual scene - well, let's just say it's orders of magnitude harder. I don't recall anyone actually having scanned a scene with a single camera. And that's an AI breakthrough that indeed people would talk about.

[0] : http://en.wikipedia.org/wiki/Soft_shadows [1] : http://en.wikipedia.org/wiki/Depth_of_field [2] : http://en.wikipedia.org/wiki/Ambient_occlusion [*} : Also, google images

Now implement a raytracer that infers lighting location and reflectance (and subsurface scattering) of the objects in the scene from the image and then we can have a whole new level of realism.

In all seriousness, though, I do wonder what kind of processing power you would need in a handheld device to be able to do that. Could we realistically achieve it within 15-20 years? It's certainly one of those "gimmicks" with extreme potential.

That little tangent about realism aside, the engine itself does look quite remarkable in how smooth it is able to run. I wonder hwo well it handles occlusion, changes in lighting and the other benchmarks for computer vision, as it was not demonstrated at all in the video. In fact, the presenter quite handily avoided putting his hand between the camera and the soda can.

Other than that, I can't say much without trying the thing, but I do not own an iOS device and don't plan to in the near future. If someone decides to try out the framework, I'd be glad to read a more detailed analysis of it.

I have two issues with the article (notwithstanding that I had to look it up in google cache because the server wasn't responding).

First, while it's true that in this particular case iterating exposes gritty implementation details (because, to even define "iteration", you need to know about all the possible implementations and how they store items). However, that doesn't mean that the design of the interface can't be changed so that iteration is possible. The fastest I can come up with is adding a concept of inner set (that might or might not be null) and a method containsOuter, that by contract should not dig into the inner set. Then, for the adjoint set implementation you would have (in a more C-family style)

  bool contains(T item)
  {
    bool res = containsOuter(item);
    IntSet next = getInnerSet();
    while(!set && next != null)
    {
      res |= next.containsOuter(item);
      next = next.getInnerSet();
    }
  }

And we have iteration, without having to resort to implementation details. Barring any argument about aesthetic appeal of having this innerSet thingy, the code itself is simple enough to manage (heck, you could have that as a virtual method without any problems if you were in the frame of mind of class inheritance as opposed to interfaces).

Second, I don't see why we can't abstract this iteration business into an iterator. Fine, Java's iterators may or may not be a sprawling mess, but add lazy evaluation to the mix and you have a very, very powerful system. In particular, LINQ and Haskell handle collections quite nicely, and nothing stops you from implementing it in the OO language of your choice (if there aren't already some).

So how do lazy iterators help? Well, infinite sets become stupidly easy to handle. Heck, you can even self reference in C#:

  static IEnumerable<int> Nats()
  {
    yield return 1;
    foreach (var n in Nats().Select(x => x + 1))
      yield return n;
  }

Not that I recommend mapping your collection to itself, mind, but if you wished you could go all out with it. The point is, you can transform an infinite list, filter elements out of it, combine it with another infinite list and then take 10. It won't even take infinite time to compute.

So no, lack of tail recursion is not a detrimental problem to the OO abstraction. An annoying problem, yes, but no more than that.

The design of the site is quite good, but the mouse events on the canvas to control the shape of the gradient don't seem to work at all under Opera (it's fine under Chrome).

As a suggestion, gradients with more than 2 colors (a Photoshop style adding intermediate colors on a line or something similar) would be a useful feature to add.

We'll probably need the visual memories anyway, because the "input stream" tends to be a sprawling mess that only looks so good because the brain does some pretty awesome inference and pattern matching to construct a high quality scene.

I'm not sure how far on the AI scale that would be.

In case you don't speak Haskell:

    IEnumerable<T>.Where(Func<T, bool> predicate)

It's quite simple to use:

    var odd_numbers = numbers.Where( n => n%2 == 1 );

Well, what happens when you try to remove the 10th page when there's only 1 left?

As a rule of thumb, don't ever rely on indexation in a collection if you do random deletes. Usually you'll just blow up your app gracelessly. Sometimes, epic failure ensues.

Through some feats of logic we might deduce that there's always a first element, though, until the collection is empty. So you might do this inside the loop: MyControl.TabPages.RemoveAt(0)

Needless to say, calling Remove when you have the bloody index (on IList collections that is) is counter-productive.

And I guess that code would be okay. I mean, if you head to phrase it : let x be the number of elements in the list, take out the head of the list that many times.

However, is it really the fastest way to clear a list? No. If we could access the class internals, we could just replace the store with a new empty array. Voila, O(1) clear and the garbage collector takes out the trash for you.

Generally, though, don't spend time worrying about implementation if you already have one available. When you've done optimizing all of your stuff (which is never the case), then you could go on to suggest changes to the standard library.