Yes: https://zigbin.io/771ac5

Nice!

Nix is turing complete (it can implement the Lambda Calculus), even conveniently so.

Then people shouldn't say it is, such as in the article under discussion.

What aspect of lambda calculus is not declarative?

That's right if you want to do nothing on error. I think TFA uses `...` to represent the code they would actually want to run if an error happened.

That's how I've always interpreted it unless its a convo about slices which are few. Everyone knows slices are the bees knees item 9, so not often does it need discussing.

That makes sense. But it's easy to confuse a prose ellipsis with the C++ notation for indicating the wildcard exception acceptance pattern.

Zig is not C++.

May no programming language ever introduce “foo” or “bar” keywords, lest mayhem be upon us.

Now I'm thinking there must be some brainfuck-like language called foobar.

Sorry, I suppose you could infer that but it was not my intent. It was merely my suggestion that someone's new exposure to Zig might be 'tainted' by previous exposure to C++ syntax.

This doesn't work because you're not left-shifting (doubling) the carry. But when adding the shifted carry to (x ^ y) we're back to potentially overflowing the highest bits. The solution is to add the highest and the lower bits separately:

  lower = 0x7f7f7f7f;
  highest = ~lower;
  z = ((x & lower) + (y & lower)) ^ ((x ^ y) & highest);

Note this only improves performance for larger container integers.

You're completely right! Typically you don't care about overflow though (and you should use unsigned ints to avoid undefined behavior).

You can directly query `getaddrinfo` with

  getent ahosts myhost

Thanks for this. I’ve always wanted to know how to replicate how the OS is resolving.

The OS X equivalent is: dscacheutil -q host -a name MYHOST

There's no assignment to the „m“ variables that would make your algorithm work in the general case.

im4w1l's strategy is just:

Player i returns (i - [Sum of the other players' suits]) % 4

(With i ranging from 0 to 3)

But the subtraction is simpler. I didn't want to confuse anyone with moduloing a negative number.

Can anybody guess in which way he used convolution for solving what is generally known as the change-making problem? Wikipedia [1] mentions a "probabilistic convolution tree", but that seems much more involved.

Edit: Solved. I've missed that the problem only deals with change amounts that can be reached with one or two coins. So a single convolution is sufficient in this specific case.

https://en.wikipedia.org/wiki/Change-making_problem

probabilistic convolution tree is not much more involved. In some sense it's just multiple polynomial multiplication.

But anyway, coin change problem can be solved much faster. http://link.springer.com/article/10.1007%2Fs00453-007-0162-8

Thanks! That paper is available on the author's website: http://gi.cebitec.uni-bielefeld.de/people/zsuzsa/papers/Algo...

I was dissappointed with the quality of the code and the final demo game. Also, it uses DirectX.

Here's an alternative: Dive into the GamePlay engine (https://github.com/blackberry/GamePlay/) and go through all the samples (https://github.com/blackberry/GamePlay/tree/master/samples), especially this collection of small feature demos (https://github.com/blackberry/GamePlay/tree/master/samples/b...). You'll get exposed to core concepts like Lighting, Terrain, Particles, 2D GUIs and Lua Scripting, all implemented from the ground up in C++ and OpenGL.

Take some of that time to figure out the math and the code becomes trivial:

  for (n = 1; n <= 20; n++) {
    window.alert(n << (n-1))
  }

A short explanation: http://mathbin.net/98435

A shorter explanation with no binomial coefficients in it: Write down those 2^n numbers once in order, and once in reverse order, and pair them off. Note that each x gets paired with 2^(n-1) XOR x. So each number and its partner have exactly n 1-bits between them. In other words, twice the number we're looking for is 2^n.n; so the number we're looking for is 2^(n-1).n.

(More informally: Each bit is 0 half the time and 1 half the time, because you can pair off x and 2^(n-1) XOR x. Therefore the total number of 1-bits is half the total number of bits, QED.)

Dude, thanks for that! I really enjoyed the closed form solution, though there is absolutely no way I could have come up with that under time-pressure in a codesprint.

My solution was rather trivial: The base case is 2 bit numbers, which are 00,01,10 and 11. The total number of one-bits is 0+1+1+2 = 4.

From then on, I just used recursion.

3 bit numbers are really 2 bit numbers with a '0' prefixed half the time, '1' prefixed the other half of the time. There are 8 3 bit numbers, so you are tacking on the '1' 8/2 = 4 times. So 4 + twicetwobits = 4+2 x 4 = 12.

4 bit numbers are really 3 bit numbers with a '0' prefixed half the time, '1' prefixed the other half of the time. There are 16 4 bit numbers, so you are tacking on the '1' 16/2 = 8 times. So 8 + twicethreebits = 8+2 x 12 = 32

If you write out the recurrence relation, it looks like:

f(n) = 2^(n-1) + 2 x f(n-1)

This seems silly since you can neither define f(n) nor recursively call f(n-1) in Blockly just yet. But if you memoize the f(n-1) results in a list, the recurrence is computable by straight iteration - which is exactly my Blockly solution.

C++11 support in common compilers: http://wiki.apache.org/stdcxx/C++0xCompilerSupport

Thanks to you both, that what I was looking for.