dmlorenzetti

But OK, I'll do it your way:

An interesting class of algorithms is finite-difference approximations [1]. Even more interesting are algorithms for designing such approximations [2]. A key insight to making these algorithms work is that Taylor series approximations can be used to study the truncation errors of discrete approximations to continuous phenomena. However these techniques, by themselves, mainly interest me in the context of the physical problems they are meant to address. Since those problems come from the physical world, I would argue that the algorithms themselves don't satisfy the formal criteria set forth in the original question, of what algorithms god would write down in a book.

[1] See LeVeque, "Finite Difference Methods for Ordinary and Partial Differential Equations".

[2] See Hamming, "Numerical Methods for Scientists and Engineers".

By the way, I would say not all algorithms occur in reality, and when they do, nature isn't necessarily very good at them. For example, sort and binary search just don't seem that high up on the list of things the physical world cares about. The natural sorting process by which dirt in a container separates out into various gradations of size, corresponds to bubble sort-- not an especially efficient algorithm.

"The Book" is all around us. The algorithms that nature cares about are woven into the fabric of the physical world. Our algorithms are just poor approximations, intended to make simulation tractable on discrete computers.

For example, this site occasionally carries posts about making water look realistic in games. Those posts usually acknowledge that the graphics approach they describe is cheating compared to actually solving the Navier-Stokes equations. But the NS equations are just a mathematical expression of reality. We then cook that mathematical expression down even more, in order to arrive at a collection of algorithms (finite-difference approximations, domain partitioning, numerical solvers) that attempt to embody the math.

Yet problems that today we would consider impossibly hard to solve computationally-- for example, fully resolving the flow of water around a sailboat, not to mention the wind in its sails, and the stresses in the mast-- nature solves billions upon billions upon billions of times a second.

Mostly this manifests as a reluctance to seek out advice from people who know the problem space well. It can also show up as a dedication to a particular self-brewed approach, despite strong hints from experts that some other approach probably would work better.

To turn that into direct advice, try to identify a mentor at work-- your boss may be one, but you really want a technical mentor-- who can spare you an hour a week or so to bounce ideas off of, and to give you an occasional nudge when you go astray (which you will). And then respect that mentor's time, by weighing his or her advice carefully before you reject it.

Another thing I've noticed is that physicists are very fast at making inroads on problems they've never encountered before. I'm not a physicist, so I can only speculate about why, but in general I think it relates both to their broad background training, and to an approach that emphasizes estimation as part of the analysis. I feel like physicists are far less likely than others to start off chasing a solution that's likely to tackle only 1% of the problem.

To turn that into direct advice, before you plunge off on some tack that you find interesting, try to perceive the outline to the answer of how this approach is going to solve the problem, or a substantial amount of your problem. Obviously you need time to build up your technical background, but maybe thinking in these terms will help you not only find the most likely research approach, but also figure out where you personally want to invest your time acquiring expertise.

Finally, the fact that you posted your question to HN implies your problem space is programming-related. Another side of the student/employee dichotomy is that students are much less likely to consider IP issues when scavenging code. Make sure you find out what your company guidelines are regarding provenance of any source code you use, and make sure you document where you got every last scrap of code you don't write yourself.

The issue arises if you know the message you want is somewhere under Calendar, but you're not sure whether it's in Calendar/Invites or Calendar/Rejected or Calendar/DateNotSetYet. As far as I know, it's not possible to search them all at once, just by searching under the tag Calendar.

Currently, you can't direct searches within nested folders. You either search all messages, or search within one folder/label. So for example, I have e-mails grouped by project, and within big projects there are sub-labels:

  project1/testing
  project1/doc
  project1/proposals
  ...
  project2/testing
  ...

Search also could use a grep-like capability. The "advanced search" options are a bit of a joke, especially coming from a company that cut its teeth on search.

At the outset, he identifies three broad categories of funding: (1) luring young people into STEM careers; (2) promoting science and technology at graduate schools; and (3) raising standards of science education. But the rest of his argument lumps these all together as if all the spending is for category #1, "luring".

For example, he points out that "no such government-backed programmes exist to pull children into being lawyers or accountants." And his broad argument, as expressed in the subheading, is that the funding biases the system to producing more scientists and technologists than it needs: "If programmes to bolster STEM education are effective, they distort the labour market..."

Only by ignoring the distinction between category #1, "luring", and category #3, "raising standards", can he complain that businesses who want better-educated scientists, if they really meant it, would just pony up and "pay and train newly graduated scientists and engineers properly." Either he thinks that the technical skills businesses want can be achieved by a quick training session after a broad general education, or else he thinks that raising the salaries of engineers will send a market signal to grade-schoolers that they ought to be more interested in STEM education. The problem of poor preparation never seems to enter his head. If all the accounting firms in the country were complaining that few recent college grads can add a column of numbers, and the government responded by trying to improve arithmetic education, would Macilwain complain about the money spent "luring children into accounting"?

In short, he might have an argument. But until he grounds it in specifics, he's just hand-waving with the broad idea that trying to improve STEM education distorts the market. This is obvious tripe, because the same broad argument could be applied to education in general: "If programs to bolster education are effective, they distort the market for educated workers. If they aren't, they're a waste of money. Besides, if businesses really wanted educated workers, they would pay and train new hires properly."

Personally, I think that idea is hard to justify these days, especially when, in my experience, finding 20-30% speed differences between optimizing Fortran compilers isn't all that hard.

The only thing I absolutely hated about Fortran for parsing data files is that, according to the standard, a text file has to end with what amounts to an empty line. Many Fortran environments break this rule intentionally, but occasionally you'll find one that follows the rules. It inevitably bites people who forget that their last line of data must be followed by a newline, or else the line may never get read.

Thus a Fortran compiler doesn't have to do anything special to make sure it preserves order when storing and accessing from two different arrays. Therefore the compiler can be much more aggressive about unrolling loops and changing the order of operations.

By contrast, given a loop like

  for( i=0; i<N; ++i ) {
    y[i] = 2*x[i];
    }

This is one reason you see a lot of C code that does numerical work hand-unrolled, with explicit stores, like this:

  for( i=0; i<N; i+=4 ) {
    xi = x[i];
    xip1 = x[i+1]; xip2 = x[i+2]; xip3 = x[i+3];
    y[i] = 2*xi; ... y[i+3] = 2*xip3;
    }

It's ironic that the authors of this statement can't be bothered to typeset their opening quote marks in the right direction-- a typical noobie mistake in TeX.

The main thing that struck me about the analysis was that it showed some of his earlier speeches, which I had never seen before, and he did indeed come across like a completely different person.

Can the user change the differential equation being shown? By the way, what equation is being shown here?

In my browser (Safari 5.0.6), initial conditions get rounded down to nearest integer. E.g., y(0)==1 graphs the same as 0, y(0)==1.8 graphs same as 1.

You might re-think the title of the "go" button, since it doesn't really "go" anywhere. Maybe "set"?

So, taking the columns as the outputs, my point is that adding down the columns corresponds to no particular causal relationship in the physics of the gate.

Your comment did, however, make me realize that I hadn't modified the row probabilities for the second row to sum to one (11-month old under foot). So thanks for that.

Perhaps a quantum probabilistic NOT gate requires the columns to add up to 1, but it's certainly not a general requirement of any physical device that imperfectly implements a NOT gate.

Consider the following probability matrix:

      0    1
 0  0.1  0.9
 1  0.8  0.2

However, there's nothing forcing the probability of 0 as an output in one row to depend on its probability in another row. One could implement the gate above in software, with no problems, and a hardware equivalent could certainly be produced.

[Edit-- fixed row probabilities in second row.]

It touches on a lot of the ideas in this article, in much greater depth, and looking across a wider range of cultures and continents.

In short, if you find this article interesting, I would highly recommend the book.

What's there now? Among other things, there's a cartoon image of a man saying "It's locked." A picture of Keira Knightley, with an atheism/theism quote. A dog catching a piece of cheese. A picture of two shirtless guys jumping around in a hotel room. The top link points to an article with content that does actually seem to be corrupted by corporate manipulation (it could be read as an advert for Lockheed-Martin). However, the article itself is on Reuters, so Reddit is just acting as a low-quality aggregator site at that point.

In short, it's hard for me to take the front page of Reddit seriously as a "media" outlet. While I do find some subreddits interesting and informative, it's not clear how the quality of the front page would somehow get dragged down by a few professionally-produced marketing messages.

If pure glurge fiction, it would have ended with the narrator, or more likely the Apple store manager, receiving a note from the school, relating how the deaf kids had been treated poorly at every other store. Better yet, one of the deaf kids would have had a powerful father who went to the Apple store and lavished rewards on all the employees there. Father might even work for Microsoft. Let your imagination run wild.

By contrast, the amount of heating or cooling a building needs generally is set by the distributed conditions throughout the building. For example, many commercial buildings require cooling in the core throughout the year-- without regard for the insolation or the air temperature at the envelope. So this technology will not, in many cases, eliminate the need for mechanical assist.

Another aspect of the control problem is the wishes of occupants in the perimeter spaces. As described, the incident sunlight, or the interior temperature, are meant to control the porosity of the material. Thus occupants get no say in the amount of sunlight they get, or the amount of air passing through the wall.

Competing technologies allow much more control. For example, "smart glass" can regulate the amount of light entering a space, either in response to occupants, or to a building-level controller. Passive inlet vents can maintain a desired airflow rate, in the face of changes in wind pressure and indoor-outdoor temperature differences (controlling to airflow, rather than to local temperature, is desired for air quality reasons).

The "Ceder Group" mentioned in the article has a cleverly-chosen name. While Dr. Ceder runs the group, its name also is an acronym for "Computational and Experimental Design of Emerging materials Research".

He mostly just called himself "Al", but I loved watching the scene play out when he had to give his legal name. He would say "Alpo", and the person behind the counter generally would give a visible start. Then grandpa would nod and say, very matter-of-factly, "Like the dog food." It instantly turned his name into a non-issue.

Tail-call optimization says that if a function directly returns the result of calling another function, then you don't need to add to the call stack in order to effect the function call-- you just modify the current stack frame as needed. For a recursive function, apparently a good compiler can essentially transform this into code very similar to what you'd get with an explicit loop.

None of this means that a simple for-loop wouldn't be appropriate, or even faster. Personally I use for-loops a lot, and, like you, I would naturally incline to writing this using a loop rather than recursion.

I see yours is a new account, so maybe this is just a cultural thing that I've got used to. To generalize grossly, recursion is more fashionable on HN than iteration. Every once in a while you'll see a post here that touches on iteration-- like maybe somebody will mention the tradeoffs between counting down and counting up a loop variable. But guaranteed at least once a week you'll see something on recursion and functional programming.

My impression is that most people here understand that a simple for-loop will get the job done, but they don't see for-loops as very interesting, and don't figure it adds anything to the discussion to bring it up.

Meanwhile, there are people here who will actively advocate against using for-loops. There's a whole theory of functional languages that says that if your program doesn't directly modify variables, then it's easier to reason about. A for-loop modifies the trip variable, so it's not a functional construct.

See, for example, this Wired article: http://www.wired.com/geekdad/2012/06/dragonbox/all/

Here's an earlier HN discussion: http://news.ycombinator.com/item?id=4105397

Sure. I've experienced this myself, for example, when doing the research cited here: http://pubs.acs.org/doi/abs/10.1021/es202359j Unfortunately, my Lab doesn't have our report version of the work up on the web yet (I believe it should be freely available at some point, but they're re-doing the library).

In addition, I knew about this particular effect before I started that work, so I must have run into it earlier.

In most cases, naive bisection works fine. That's especially true if you use pretty loose tolerances-- for example, you if only want to identify the zero to a relative tolerance of 1e-6 or something coarse like that. But this work demanded very tight tolerances (because the output gets used in a time-marching numerical simulation that may iterate on time steps, and hence has to be very repeatable no matter what the initial condition). In this work, the relative tolerance was about 2e-15, and the absolute tolerance about 1e-18 (on a machine with double-precision epsilon about 2e-16).

By the way, if you're testing for convergence according to a bracket on the value, then you want to know (b-a) anyhow. So there's no reason not to go ahead and use it to bisect the interval as well.

Another interesting implementation detail-- at very tight relative tolerances, you also need to calculate the terminating bracket width based on the larger of |b| and |a|-- due to floating point effects, if you find the terminating bracket width by applying the relative tolerance to the smaller value, you can occasionally run into a problem where adding that width to one of a or b fails to change the estimated value.

Except for the bisection method, all of these implementations take an argument specifying the number of iterations to run. In most cases, the only way to terminate in fewer iterations is by hitting an "exact" root, i.e., calculating the residual as exactly zero. This is poor practice for a number of reasons. First, in practice it's pretty rare for a method to find an exact zero. Second, once a method has converged to the numerical precision of the machine, making more iterations just wastes flops. So a much better approach is to specify a solution tolerance (as shown with the bisection method). Even better is to provide absolute and relative tolerances, and to choose those values based on either the domain requirements, or on the machine characteristics. Dennis & Schnabel's excellent "Numerical Methods for Unconstrained Optimization and Nonlinear Equations" has a good discussion on choosing convergence tolerances.

This dependence on iteration counts to terminate, by the way, is probably why the author equates low iteration counts with greater accuracy. But in fact these methods don't vary in their intrinsic accuracy, rather, they vary in their order of convergence.

Another example of poor practice is in the bisection method implementation. One generally should not bisect an interval using c = (a+b)/2, because the nature of finite-precision arithmetic means there is no guarantee that c will lie between a and b, even if the machine can represent numbers between a and b. A better approach is to ensure a < b, then to set c = a + (b-a)/2. This expression is much less subject to roundoff errors.

If it was an honest performance review, they should have been more specific than "not completing enough work." Consider pressing for details about their performance expectations, and then either work to meet the metric they name, or work to convince them that the metric isn't the best one by which to measure your performance.

It may not be a problem you can solve by just boning up on exciting new technologies. You may have to educate them on the merits of things you do that, in their opinion, slow you down-- like writing unit tests, automating builds, creating bug databases, or whatever.

This book may not exactly address the situation you're in, but you might have a look at Terrence Ryan's "Driving Technical Change", which talks about how to convince others on your team of the merits of different approaches you've adopted.

I don't know about CS, but in most scientific fields, this may be a bad sign. It can mean they're just trying to pump up their own reference counts, or it can mean they don't really know what other people are doing.

The only way to be sure that neither of these is the case is to know, a priori, that they're truly doing groundbreaking work.

While tools are available to let the PDF creator tag the document in order to facilitate reading, in practice they don't seem to be used much, and even then the experience is painful at best.