dmlorenzetti

In the longer run, the issues that threaten humanity as a whole, rather than as individuals, are as important. Things like: (1) Water/energy availability, both singly and combined. (2) Global climate change. (3) Local environmental quality (air, water, food). Of course, all of these are linked, but when working on solutions it still makes sense to think about them individually.

For example, headers are just more text. Tables and figures that "float" to the top of a page, or in any other way interrupt the text, get read in the visual, not the logical, order. Images get "read" as a stream of binary data. Equations get mangled horribly. Etc. etc.

Without knowing the baseline population they're willing to consider in assembling their count, it's hard to say, but this might very easily be explained as a stochastic process that happens to be hitting a peak. It might even be the case that this sort of death rate happens all the time among the vast pool of "financial workers," but the Financial Post just happened to notice it this week.

I also find that having a little psychic space between work and home helps me better regulate intrusions between them.

And as you point out, you need to take the abs(y) as well, on the right-hand side.

Thanks for adding clarity.

I would be interested in hearing what advantage anybody thinks "infinite undo" would bring to a scientific simulation. I can sort of conjure up a scenario where you're doing a probabilistic optimization, and you want to be able to re-visit every single time step, in order to perturb the boundary conditions and watch how the system evolved differently. But the cost of storing all the meaningless "false" states that the solver generated as it searched around in the solution space for each time step, hardly seems worth it (compared to, say, some kind of way-pointing capability, which many scientific software programs have got already).

First, you really don't want to do that division x/y, which is slow, and which fails if y==0. It's much cheaper and safer to compare "abs(x-y) < 1e-10*y".

Also, you almost always want to compare (x-y) to an absolute convergence limit (in addition to your relative tolerance), in case x and y are very near zero.

Finally, if you really want a generic converge function that can be re-used elsewhere, you might want to allow for non-convergent processes. This requires tracking the number of iterations, and bailing when it gets too large.

By the way, now that your convergence function wants to know (x-y) rather than x and y individually, you might consider rewriting your logic functions to return the predicted change, rather than the final state. This avoids forcing a re-calculation of the change, which typically was already known in the logic function. It also avoids floating-point problems in which the calculated change x-y differs from the predicted change that produced y in the first place.

Similarly, there's nothing preventing an implementation in an object-oriented language from making the states of things at the beginning of a time step immutable. In fact, this is done all the time in scientific simulation (necessarily so, because you might try a time step that is too long, and have to re-try a shorter step from the same initial state).

So the author's conclusion that The second [fix] is to avoid any kind of intra-frame pollution of object data by keeping a list of all changes..., then applying all of those changes atomically as a final step sounds like a letdown to me. The imperative codes I work with do this all the time. It's just that the comments say mundane things like "Update the pressures" or "Report out final concentrations" rather than "Apply changes atomically to avoid intra-frame pollution."

A backup of a corrupt file wouldn't solve the problem.

If she's interested in biology, you might consider "Animals in Translation" by Temple Grandin. It's more about animals than about technology, but it touches on how understanding animals affects the low-tech systems that you use to handle them.

For interesting/easy intros to why some math skills are important, look at Darrell Huff's "How to Lie With Statistics" or John Allen Paulos' "Innumeracy" (or "A Mathematician Reads the Newspaper").

I haven't read any of them, but I hear Petroski's books recommended.

For a great short read that touches on architectural engineering, law, and ethics, look for Joe Morgenstern's "Fifty-Nine Story Crisis" which appeared in the New Yorker in May 1995. It's about how the structural engineer for the Citicorp tower realized its design was flawed, after the tower had been built and occupied. You can find it on the web.

Some of these are not overtly about "learn this technology", but to me they all sell the idea of technology and science as both central to our lives and interesting.

In short, you have a vector of reals that you update over and over, one element at a time. This is simply not an operation that functional programming excels at (there is an idea in the functional programming community that the state of a system, because it is a snapshot in time, never changes, and that therefore it is appropriate to model this as a bunch of immutable vectors that stream along in time-- but in practice I don't find that a very powerful, or useful, abstraction).

So my reaction to functional programming, after reading a couple of articles and books, was "Huh, it's cool, but not that applicable to my work."

I can imagine how this also would be the case in embedded systems programming. My brother designs and builds robotic manufacturing systems, and from my limited experience looking over his shoulder, it sure looks like those systems are all about managing state transitions.

Nevertheless, there are a lot of powerful ideas alive in the functional programming world, and over time these have influenced the way I do things. At the most basic, when I design programs, I try to represent the lowest-level descriptions of physical processes as pure functions-- no globals, all state passed in as immutable arguments, and all results returned as numbers. I do find this style of programming easier to test, and to reason about, and that's one of the primary benefits of FP you hear about.

There are other things, too, like my approach to input and output, and how I think of certain operations as "maps" now, but I think you get the point. In the big picture, I'm scavenging for ideas, rather than adopting an approach wholesale. It's like reading about Extreme Programming, and shifting to test-driven development but not pair programming.

My advice would be, look to adopt FP ideas piecewise, rather than all at once. Look for the small ideas and approaches that will make your programming more clear, or easier to test, or easier to re-apply from one system to another. If you've put in an honest effort to understand FP, and you just don't see how any of it applies to your work, then don't worry about it. There's no need for you to "be convinced" of anything. It's about building up your toolbox of tricks that work for your application domain.

Since it sounds like you're in the south bay, you might check out NASA Ames; they may have something similar.

Grep-based search would be good.

When replying to a message, it would be nice if the controls for breaking the window loose of the rest of the application didn't require four or five actions, in different parts of the screen. Here's what I mean. Hit "reply" to a message. If you want to pop that window loose, so that it's actually useable while you run through other messages, you first go to the upper left corner of the editing area, click the drop-down, and hit "Pop out reply". Then go to the upper right of the subwindow that just opened, hold down shift, and click the arrow that points up and to the left. None of it is intuitive, and it's just too much clicking for such a simple action.

It would be nice if the editor wasn't so forgetful about the insertion point. For example, if you're editing some text in a reply, and click on the "..." icon to see the message you're responding to, the insertion point hops to the top of the editing window.

Ability to remove an attachment.

When you delete a message, and you're looking in Trash, have the quick-preview line (i.e., the first few words, shown in the main screen listing all the messages) show the contents of the message you're actually looking at, rather than the first sentence in the most recent e-mail with the same subject. I don't know how many times I've panicked, thinking that I deleted an important e-mail, rather than some formulaic "Catch you tomorrow" or "No problem" message that I had trashed.

I've long ago given up hoping that some organizational capability would come to Gmail that went beyond the pathetic "conversations" mode. Gmail's idea of organization pretty much amounts to this: (1) you either want to list all e-mails by subject all the time, or you want to list them by time all the time; (2) you only rarely want to switch back and forth between those two views; and (3) if you want to list them in any other way, then it's a "search" which delivers limited results, and disappears the instant you navigate away from it.

E.g., It is common practice to write the form A^{-1}b for economy of notation in mathematical formulas... The trouble is that a reader unfamiliar with numerical computation might assume that we actually compute A^{-1}... On most computers it is always more effective to calculate A^{-1}b by solving the linear system Ax = b using matrix factorization methods... (Dennis & Schnabel, "Numerical Methods for Unconstrained Optimization and Nonlinear Equations", section 3.2).

E.g., As a final example we show how to avoid the pitfall of explicit inverse computation... The point of this example is to stress that when a matrix inverse is encountered in a formula, we must think in terms of solving equations rather than in terms of explicit inverse formation. (Golub and Van Loan, "Matrix Computations", section 3.4.11).

If you haven't read "Working Effectively with Legacy Code" by Michael Feathers, I would strongly recommend it. The book officially is about how you get existing code under test, but its techniques orient around moving the code to a better organization.

The book "Large Scale C++ Software Design" by Lakos lists some actual, computable, metrics for assessing how interconnected your code is (and hence how hard to change). Never having used those metrics, I can't recommend them one way or the other; I just know they exist.

The site is needlessly vague about what it's going to show me. What are "my results", and will they be compelling enough for me to send personal information to somebody I don't know?

Coming to this site cold, with no expectations, I had no desire to enter my parents' ages, to tell you where they live, or to tell you how often I see them.

Naturally, there are a number of web resources, but none of them felt authoritative (in the sense of complete coverage). Furthermore, they used different techniques, so it was hard to integrate code samples from different sources. Finally, some had outright errors (my vague memory is that some of this was due to the documentation being written before a working implementation was available).

All of this had the effect of making me feel like SVG was a bit of a backwater. I liked the technology, and was willing to use it since I had total control of the machine I was going to run the demo on. However, I didn't feel comfortable with the idea that I could make the demos public and have them run anywhere.

The main requirement journals have is that we don't distribute the journal's marked-up final version. So we make them available as "Lab Reports" with our own typesetting, front cover, and so on.

The post repeatedly mentions functionality that used to be one click away, but is now multiple clicks away. That is about as objective as measures come. You may not mind it, but you can't say it's just subjective.

The post also points out how UI controls shift relative positions based on the view being presented. One could define a metric that assesses the effect, and anybody calculating the metric would get the same result. Again, you may not mind controls jumping about as you work, but you can't say it's not objective.

In fact, an explicit part of NIST's role is filling in science that businesses need but can't do themselves.

NIST started out as the National Bureau of Standards. It sits in the Department of Commerce. Most of its activities are directed at tasks-- like standardizing measurements-- that businesses depend on, but are too small, or too balkanized, to do effectively on their own.

Unless, you know, you like every corner gas station having its own definition of "gallon", and every appliance manufacturer rating its offerings using different definitions of energy, and every steel producer specifying tensile strength according to its own test procedure.

Disclosure-- I had a post-doc at NIST in the late 1990s.

That said, I've recommended learning Python to a few people, but have never even suggested anybody learn sed or awk.

Donald E. Knuth lived two separate lives in the late 1950s. During daylight he ran down the visible and respectable lane of mathematics. During nighttime, he trod the unpaved road of computer programming and compiler writing. Both roads intersected! -- as Knuth discovered while reading Noam Chomsky's book Syntactic Structures on his honeymoon in 1961. "Chomsky theories fascinated me, because they were mathematical yet they could also be understood with my programmer's intuition. It was very curious because otherwise, as a mathematician, I was doing integrals or maybe was learning about Fermat's number theory, but I wasn't manipulating symbols the way I did when I was writing a compiler. With Chomsky, wow, I was actually doing mathematics and computer science simultaneously."

That's a shame, because having collections of useful tools like that makes it a lot easier to keep track of options.

I imagine the authors could make a single node of the cluster use a GPU, if they wanted.

The article basically says he wrecked his body working punishing hours, so he quit, found a girlfriend, started collaborating with her on a mutual goal, and plans to get married. Headline says "he doubled his salary!"

If he doesn't care whether he's on the path to linear growth, why should we?