questerzen

The given best-game solution is not optimal: Black can delay mate for another move to give a forced win in 11 ply rather than in 9 ply. Optimal is: N4 n5 N6+ k7 R4 as given, but Black can delay mate with ... n3+, rather than ...k6. The remaining moves are then: K2 n5 N8 k8 R5#. Perhaps your minimax code doesn't include moves-to-mate in the move score?

Here is an example of a case that backtracking is required where there is only one solution:

      11110
      -----
   11|....0
    2|....0
    0|00000
    0|00000
    0|00000

A more difficult problem is the following:

      11 1 
      11211
      -----
    1|..0..
    2|..0..
   11|.010.
    4|.111.
    0|00000

      11 1 
      11211
      -----
    1|..0..
    2|..0..
   11|.010.
    4|01111
    0|00000

The other solves the problem immediately as all remaining squares are immediately specified by a single constraint.

      11 1 
      11211
      -----
    1|00010
    2|11000
   11|00101
    4|11110
    0|00000

Of all the games with a unique solution that the sequential solver can't do that I looked at, almost all fell somewhere in the range of difficulty between these two. I didn't find any that require more than one move lookahead.

I realised the backtracker can stop early as soon as all squares are filled in (doh!). As a result the timings have changed dramatically.

Database generation: 25s; Sequential solver - all 'solvable' problems or abandon: 52s; Backtracking solver - all solutions: 19s; Database Lookup - all solutions: 16s;

Key takeaway is that the backtracker is not only much simpler, its actually much faster (for a computer at least) and almost as fast as looking up the answer in a table.

My sequential constraint solver (no backtracking) also found 24,976,511 games it could solve without backtracking or using more than one constraint at a time.

To get an idea of the speed difference between solving sequentially vs solving using backtracking, on my 10 year old MacBook Pro running on a single core, solving all 28,781,820 possible distinct games: - sequential solver: ~75s to either solve or abandon each problem - backtracking solver: ~175s (2.3x) to find every solution for every problem

The backtracking solver is unfairly disadvantaged in this comparison as it takes more time to solve the difficult games requiring backtracking and those with multiple solutions - for example the game {1, 1, 1, 1, 1 | 1, 1, 1, 1, 1} has 120 solutions that need to be found, but the sequential solver abandons its attempt after making no progress on its first pass through the constraints.

For the 25,309,575 uniquely determined games only, the gap in performance is a bit narrower: - sequential solver: ~60s - backtracking solver: ~120s (2.0x)

The recursive backtracking solver was a far simpler program to write though!

Incidentally, to generate a database of all possible games took ~35s and finding all solutions for all of the games by looking them up took ~20s in total.

I calculated that 25,309,575 games have a unique solution. My back-tracking solver correctly finds all answers for all of the 28,781,820 possible distinct games.

My experience with Packt has been wholly negative.

To give an example of what to expect, my experience with one particular book on Scientific Python: * most code examples wouldn't run without significant modification, mainly due to missing lines and multiple typos * some of the text was cryptic to the point of absurdity * topic coverage was unstructured, patchy and made no coherent sense overall * the website for the book was broken and I couldn't find any way to feed my corrections back to the author

Clearly Packt put no effort into quality assurance or editing. I would suggest you would be better off waiting for something from a more reliable publisher: such poorly edited books will just waste your time.

Funny, I just reread "What do you care what other people think?" yesterday. The parallel of NASA's design process for avionics software to TDD is both striking and revealing. People struggling with TDD could definitely benefit a lot by thinking hard about the examples of the main engine design process and avionics software. Thanks for posting!

Other people have also suggested Latin as the most likely base language. A better discussion is provided here: http://www.science20.com/patrick_lockerby/patterns_of_latin_...

Growing up around the tech industry in the 1980s, I found the casual racism and sexism of computer engineers difficult to deal with. The behaviour was "excused" by its being an exclusively white male niche, with "geeks" derided by society, excluded from the social core and under-valued as people. As long as this is the defining self-image of people in technology, framed by the US high-school geek vs jock enmity, there is little hope for change. This was not my experience, and it is not a frame that is useful given the dominance of technology in the wider culture. We need as an industry to stop behaving as outsiders and start to accept the responsibilities inherent in leadership. TBBT is one example of the antediluvian attitudes that no longer reflect reality and need to be changed. Cudos to the creator of this video for calling it out.

The Black Swan has a good point to make about reliance on over-simplified mathematical models, but Taleb's macho anti-intellectualism is ultimately nihilistic since he denies even the possibility of achieving a deeper mathematical understanding of risk. But what I really have a problem with is that he has created a band of idiot Twitter acolytes who can be counted on to heap brainless abuse at anyone who Taleb chooses to disagree with, which these days seems to be almost everyone with even slightly diverging views to his. He will not attempt reasonable debate, especially when he is faced with superior erudition: in this regard Mary Beard is only the latest of his many victims. The guy is a pure and simple thug.

I use Python a great deal, especially for tooling and prototyping and appreciate the fact that programming is fast, easy and focused on the inherent complexity of the problem. Similar positive experiences with Smalltalky and Lispy languages as embedded languages. But I write a lot of performance-critical libraries for programs that need good C/C++ interop and where C++ is pretty much the lingua franca. Swift, D and Go, for example, all have their strong points, and I plan to do more experiments when I have some time ... after this one last C++ project, though!

So I hate C++. What I really want is the speed, flexibility, universality and simplicity of C. But I wish structs had destructors, and a way to bind namespaced related functions. Only since I basically now have classes, I should really think about adding inheritance. And I also find prototyping, testing and non-speed critical programming is a pain without a good generic container library. Containers can be implemented fairly elegantly with templates, but then I probably also need some compile-time processing ability. Oh crap, I just ended up at C++ again. And so I persist with C++ as my main language, with a constant voice in the back of my mind saying, "this is just stupid, there must be a better way. Why is there SO g-d* much accidental complexity in this language?". In my view, C++ has probably wasted more programmer hours, and added more sadness and despair to the world (at the very least MY world) than any other technology. But given my language wish list it's very, very hard not to be tempted to fire up c++-mode for just one more hit.

I'm constantly surprised by how often I still need to look up file formats, and having a resource like this is a great starting point. Some examples from my recent experience for which using a library would be overkill / more effort: examining a .bmp file to figure out why the alpha channel got dropped during resizing; extracting meta-data (top-left pixel alpha value) from a .png file; fixing a failed library-call attempt to change the aspect ratio of an image; working out the version of an ancient document file so I could find an application to read it. We shouldn't become so dependent on libraries that this kind of simple manipulation forces us to install huge libraries and learn complex APIs for simple tasks, or else we collapse hopelessly into despair. Especially when a simple Python script and a one-page file description can allow us to do the job in a few seconds.

It is probably a sign of a good language that the words used most should be similar in frequency to their use in pseudo code. When words like "end" (Ruby), "self" (Python), "import" (Java), "err"/"error" (Go and Node) are over-represented, it's likely a sign that the language is introducing accidental complexity. By this metric Swift looks astonishingly sane.

I added division and brackets. This gets every number up to 5397, with only about 400 numbers still missing overall (<5%), but run time goes up to 40 minutes.

Potentiation is a problem though (particularly when combined with brackets) as Python becomes impossibly slow using bignums. (I estimate it will take several days of compute time to test all 250 million possibilities, unless I put some effort into speeding it up significantly.) But at least it would prove definitively whether 10958 is possible.

If the only goal were to search for a solution to 10958 though, it should be fairly straightforward to re-order the search in approximately ascending order of compute cost so that if a simple solution exists it will be found quickly.

From the Wikipedia page on the JVM: "[code verification]...allowing the JIT compiler to transform stack accesses into fixed register accesses. Because of this, that the JVM is a stack architecture does not imply a speed penalty for emulation on register-based architectures when using a JIT compiler."

I imagine you are right. But there should be plenty of scope for optimising this in the VM itself. Most stack operations are immediately preceded by a push, so hold the top of the stack in a register and the last push in another and you could avoid a high proportion of memory calls in the most common cases. Does anyone know if JVM implementations do this?

"The best camera is the one you have with you" is a good adage. For prototyping a language needs to feel effortless so you can deal with the essential complexity of the problem and not hesitate to jump in and experiment.

For implementation, it's whatever tool best fits the job.

C is a good compromise, but it requires real discipline. The CPython and Linux code bases are great examples of how C can be wielded well in practice. But of course C also famously offers unlimited opportunities to make a complete hash of things. I certainly wouldn't recommend it to anyone as their first and only language.

An alternative approach is to be bilingual. For my current project the final code is in C++98 - sometimes there's no good alternative. But I do most of my experimentation, tooling and prototyping in Python. Python's excellent C/C++ interoperability is a huge benefit in this.

I definitely agree with the article that you shouldn't avoid hard things that improve you. But in choosing between ADA and C, the right answer is both and neither.

Roger Penrose's Road to Reality makes use of Clifford Algebra and Grassmann Products, so at least some serious physicists are using it seriously.

Even though I had come across it before, I had a real revelation when I read David Hestenes short paper on it (from Bret Victor's website) http://worrydream.com/refs/Hestenes-ReformingTheMathematical... It is indeed beautiful to see how complex geometry and vector fields are connected via GA. I found especially revealing the relationship between electric and magnetic fields. I agree with the article that whatever its absolute merits, it would be a good way to teach new physicists. I have already ordered my copy of "Clifford Algebra to Geometric Calculus".

Whether it is actually more practical to do work in General Relativity or Quantum Mechanics, or indeed Quantum Field Theory etc., I'll have to leave for the experts in those fields. From an outsider's perspective, it is a delight to understand some of the connections between different disciplines in a more intuitive way.

In any case, I would imagine that GA is exceptionally useful for computer graphics and physical simulations.

You can tell a lot about a person from his bookshelves and I know this is a guy after my own heart.

He has almost every non-fiction book on my Goodreads list: Books Scientists Should Read Before The Age Of 20. https://www.goodreads.com/list/show/75031.Books_Scientists_S...

Forget Amazon recommendations: this is the basis for my 2016 reading list.

Thanks for those that have worked hard to list the books!

PG does appear to want to do a better job than the rest of his industry and he should be applauded for that.

But there is very little evidence that PE or VC funding adds much value to a company through advice or services: the poor performance of post-boom PE funds and their companies, for example, suggests that such claims are vastly exaggerated. I recently had a conversation with the head of a very successful fund who, reflecting on the aftermath of the financial crisis, openly expressed his doubt that his fund had really helped the companies they bought stakes in. He, of course, became exceedingly rich and the steady stream of inflated IPOs produced healthy returns for the funds investors (at least until they didn't.) A large part of the problem is that the compensation model (the traditional "2 and 20") is geared towards the capital providers not the entrepreneurs or indeed to social benefits. Funds are incentivised to raise huge sums of capital from sources who offer nothing but cash and a healthy appetite for risk and over-capitalise the companies they fund (the fund earns 2% on invested external capital regardless of how it performs). To compensate the investors, the funds rely almost exclusively on extracting a very large profit from the few "unicorns" that succeed outrageously (of which the fund gets to keep 20%, or sometimes more). Taking $100 million from a single company is hard to justify, however greatly you value the advice and support you got. And the many worthy productivity-enhancing near-successes are left to flounder. PG may like to focus on the positive impact he is having helping founders succeed, but the reality of his business model is strongly skewed to financial rent extraction.

There are two separate issues here and it is important to distinguish them clearly. PG is correct that there are two basic strategies for making money: rent and productivity. 1) rent, although it has a positive aspect (it helps to efficiently allocate scarce resources to where they are most valuable and provides an incentive to add scarce resources to the economy), provides an inherent redistribution of wealth which makes owners of capital richer at the expense of non-owners. Piketty etc. have noticed that capital owners have recently been able to gain a greater share of wealth. This is socially and morally a bad thing, especially when it keeps non-capital owners in a state of relative poverty. 2) productivity, in general, is more positive because it provides a net gain to the whole economy as PG points out. If the incentives to a small number of people are very high for adding productivity, then there is no particular problem with this. So in this sense PG is correct. However, this is largely irrelevant as the main problem is that productivity gains are predominantly going to NEITHER workers NOR entrepreneurs. Rather they are going to existing owners of capital. The biggest problem with massive wealth accumulation by founders isn't whether it was deserved, but that when people stop being productivity enhancers they become capital owners and CONTINUE to earn wealth excessively not due to further productivity gains but through rent. There are many solutions possible, but none of the sensible ones would affect new founders very much. PG can sleep easily on this account. The reason PG should feel "hunted" is not that he is a founder enjoying the rewards for benefits he has provided to society, but that as a successful former founder and now capital owner he is continuing to gain excessive wealth by extracting rent from his YC investments such as AirBnB, and even worse, helping PASSIVE YC investors to capture that rent also.

Not quite true. The analog version is inherently parallel, the digital version is not (cf the MATLAB simulation discussed in the paper). The parallelism of the analog system increases exponentially with it's size, the digital system only linearly. So an analog computer built in the way they indicate might be able to create a useful and powerful practical system to test quantum algorithms on long before quantum computing becomes a reality, whereas the digital model cannot be more powerful than the computer it is running on and will struggle to model even moderately complicated quantum systems.

You could, but it is a bit pointless. The idea is that mathematically a superposition of analog waves looks the same as the superposition of quantum states, so you can get exactly the same behaviour using the natural laws of physics. A digital system that modelled the waves would require an absurd amount of resolution since the interference effects need to be modelled accurately. In essence you are throwing away most of your information capacity by switching to digital on/off signals from superimposed waves even though you are using the same wires. The reason quantum computing is interesting in the first place is to use all that wasted information to produce a Massive gain in computing power in a much smaller system.

This is something that has been noticed before mathematically, but hard to do in practice. The article is maybe a little confused. The limitation on size comes from the limit on frequency/amplitude resolution - for a given scale and resolution, the need to distinguish states grows combinatorially. It can be overcome by making the system smaller. Eventually you can rely on quantum effects to help, when you are no longer emulating a quantum system, you've basically built one.

Not everyone has had the same negative social experiences. I was very lucky to go to a school where being an outsider with nerdy interests was respected so long as you did it with passion, aspired to excellence, and were not afraid to show others what you found cool; and we were expected to have the same respect for the sportsmen, musicians, artists etc. In a sense we were all doing the same thing through different outlets. It's a culture I'm very proud to have been a part of and it produced some great people in many different fields. In contrast, in my programming niche, I frequently feel uncomfortable with the level of aggression and exclusion on display - every comment on a forum seems like you are exposing yourself to ridicule and judgement. Conversely, in pure maths forums, which I also participate in, the atmosphere is far more welcoming, open, patient and respectful of good work. I think the problem is that in computing it is far easier to be a dilettante and much harder to tell the difference. Yes, all communities will have their dicks, but responding with aggression and elitism pollutes the community for everyone and encourages hostile and collective responses from others: be sure that the dicks are a lot better at playing hardball and ganging up together than we are. Let's take some responsibility for creating communities we're proud to be a part of. Please.

Attacks in two of my home cities (Paris and Sydney) in recent weeks affecting people I am closely connected to. It is truly heartbreaking. It makes me very proud that in both cities, people refuse to accept these actions as anything but the actions of inexcusable murderers; and in both cases people have made use of the internet to share a positive message of hope and solidarity (Je Suis Charlie / IllRideWithYou). When I grew up in London during the IRA bombings, no such channel existed and the message was a very negative one issued by the government and echoed by the broadcast media. What a difference it makes that the general population now have a channel to direct the way these actions are viewed, communicated and reflected back to the perpetrators. Yes, now we ARE all Charlie.

I thought I'd have a quick look at a couple of the pages online to see if there was anything of interest. Several hours later... I've read most of the later chapters and a few of the earlier ones and already learned more about graphics programming and low-level code optimisation than I imagined possible. What an incredible book!