adolgert

I like that paper. Thank you. It has references which criticize the skipahead technique. I need to look into whether I believe that paper, though. There are lots of ideas about how to do this, and subtle flaws abound. While many generators are known to skipahead, there is a quite new technique for MT that makes it much faster, not by Barash and Shchur, but they used it. Again, thanks.

Do the Monte Carlo people all know about Barash and Shchur's work? They made an RNGSSELIB and PRAND (using NVIDIA cards), but the main contribution is that they incorporated a new way to generate multiple streams not by re-seeding the generator but by skipping ahead, even with Mersenne twisters. It is the only simple way to get parallel streams, and it didn't exist just a few years ago. You still need to be careful in various ways, but this helps a lot. A lot, a lot.

[1] http://arxiv.org/pdf/1307.5866.pdf

This is an interesting application, and dogged mathematical derivation, of survival analysis. We would do the same calculations today with standard Kaplan-Meier curves. Do you see the survival functions, S=1-F, in the first few pages? They also state a hazard rate, all without reference to stochastic variables. It's like seeing the mathematical version of a 1943 automobile.

My recent favorite reminder of why I need others in order to program well is the list of things I am unqualified to say about my own work, including, but not limited to

- Is the user interface intuitive?

- Will this library be efficient for its most common uses?

- Have I given the simplest explanation for what this thing I wrote does?

It helps to be able to say, "I can't know that yet, not until I ask someone." That might happen in use cases, watching over someone's shoulder, showing a conference poster, or getting complaints on a message board two years later, but it's always collaborative, even when I have my act together.

Haven't read it unfortunately. The table of contents shows a much more rapid treatment. When working outside of a university course, examples can be very useful. Anyone else read Burke?

Enough of you care about this to vote it to the front page? Who are you people? In that case, I have two favorite books on this topic.

Bamberg and Sternberg, A Course in Mathematics for Physics Students. It's a redo of calculus using differential geometry from the start. A very pretty way to do E&M, or calculations on the surface of the Earth, or vector flows.

Grady and Polimeni, Discrete Calculus. This is how you do calculus on graphs, which is how you do scoring algorithms on graphs. You know, for big data.

Discrete exterior calculus in Python! (almost forgot) http://arxiv.org/abs/1103.3076 They have demos that show how extraordinarily powerful it is.

That ought to keep you busy for a few months, you odd ducks.

It was a year after this paper that the Fenwick Tree came out. It compresses storage for the prefix sum into an N-length array instead of 2N-1. This is what's used in stochastic algorithms for chemical reactions.

There's an algorithm to deal with this kind of additive small error, the Kahan Summation algorithm. It keeps a second number to record the residual of an addition so that adding something small to something large doesn't go awry. With modern floating point, it's rarely an issue, but with a mere 24 bits, I guess it was a terrible problem.

Her CSPAN video: http://www.c-span.org/video/?c4486712/sen-feinstein-accuses-...

It's not common metal. The design of the slug is much of the work in creating a railgun because the electromagnetic push comes from generating back-currents within the slug itself. It has to be good at being pushed, then good at flying, all without melting.

Maybe you looked at Schroeder and Gibson from Fast07, which looks at MTBF calculations. They have lots more data, but none released. Hard drive failures are an easy example of the use of the concept of hazard to examine probability distribution functions. I'm not teaching this now, but I sympathize with the difficulty of finding good datasets. Who knows? If you group data by pod, or even location in datacenter, there could be something interesting in exploratory analysis.

The javascript shows they are thinking about this as particle traces of wind velocities. In visualization, the technique is called Line Integral Convolution (LIC). Each line follows the direction of the wind vector, and the overall brightness is the sum of the magnitude of the winds under the line. This particular variant just uses the wind speed at one point under the line. LIC won't accidentally miss field singularities like vector-arrow representations, and there are variants that provide smooth animations.

It's great that we've advanced from needing VTK to being able to do a visualization like this as a live movie, translating GRIB files to JSON.

It makes me so happy to see such a clear picture of how service logs relate to the input and output token streams of finite state machines. We usually think of finite state machines as these little objects with a few states, but the category theory version of them is an essential definition of what it means for a system to be deterministic and depend only on current state and given inputs. It's a set of allowable input tokens (the input log), a set of allowable output tokens (the output log of actions taken by the system), an internal state Q, a dynamics delta that decides the next state from the previous one, and an output function lambda that decides what output token to return given the current input state.

By making the statement that logs are streams of tokens which have deterministic effect, this author is assuming that the services are finite state machines. This may not be the case if, for instance, they do not set random number generators to a known state. Any way a service doesn't just depend on its previous state violates this principle. If it meets this principle, then the logs are, by definition, taken from the strings of allowable input tokens X or the strings of allowable output tokens Y.

The debate in the article about at what level to log is a debate about which portion of the service to treat as an FSM. It boils down nicely.

Oh, a dense but beautiful article on this is Machines in a Category by Arbib and Manes.

Meyers' presentation slides, with notes, are available and excellent: http://www.artima.com/shop/overview_of_the_new_cpp. They include C++14. It isn't the deep dive, but it's a great overview.

Maybe more apt a comparison would be a choice between custom-built automobiles and those from factory lines. At the time, there was fear that working in factories was dehumanizing. The ethical question is resolved politically, by having labor unions so that workers have some control. From the undercover reporting articles on Amazon's warehouses, there aren't labor unions.

Amazon does provide a lot that stores don't, but now you're asking what is the outcome of your choice for yourself, not for others. There is a lot of that same focus in the comments here.

Counterexamples of people who work in stores and don't enjoy their jobs are perfectly valid. I would focus, though, on what my choice of where I spend money offers as an opportunity to others. The opportunity in the warehouse depresses me. The opportunity in the store seems pretty OK.

I, too, want what Amazon has to offer, and those who can pay taking what is offered them is the way of the world, but I still have to make my own choice.

Is there a significant ethical difference between purchasing from a store or from a large online retailer? In one case, shipping to the store is bulk, and employees may make low wages, but they interact with other people. For a retailer Amazon's size, warehouses run on people who read orders from handheld devices and are timed for retrieval speed per box filled. Then shipping is done per parcel. How have you decided what's the right behavior to encourage with your dollars?

It was relatively common in the CAVE to have someone see in stereo for the first time. The shutter glasses have LCDs that are synchronized to flip black and then clear, alternating eyes. The projectors are synchronized to this flip so they show the correct projection for the correct eye. This technique sometimes defeats eye dominance problems that impair stereoscopic vision. Because stereoscopic vision accounts for only about 30% of our ability to judge distance, behind occlusion and motion parallax, it was amusing but not life changing.

That's an excellent question. Latitude and longitude are straight in the projection he is most likely using, but great circle arcs are what we consider straight on the globe. The kicker is that most political boundaries are neither. They are Rhumb lines, aka loxodromes, which mean that someone started walking in a direction and kept going.

The standard solution for this is to put lots of little points into the state GIS definition, so that the points get transformed correctly. That way short line segments don't differ by more than a few meters. That means you have to watch out for simplified state representations, but not much else, unless you're being a stickler.

Mosquitoes in the US used to be mostly Aedes, but now there are a lot of Culex, which fly twice as fast (120cm/s, or about 2.7 mph) and are better hunters. The Aedes come into a room, find a wall, and eventually eat, while Culex go straight for the bite. Both of them tend to fly upwind toward meals. I wonder whether fans blow the close mosquitoes away but draw lots more to the area, in search of that good human-food smell the fan disperses.

For the coronovirus, people tend to check the type of infection only when the infection is bad. The people who have died all had comorbidities, meaning they were already sick with something else, so that 50% death rate is a result of a very strong observation bias and unlikely to be a characteristic of the disease.

Ah, I missed their explanation. The 196% and 338% are still bizarrely high figures, given that the variance of a Poisson distribution equals the mean. 338% variance, and you don't ask what kind of distribution you're measuring?

Statistics would help us believe this article. Are they quoting 196% variance over the mean? What does it mean to be 4.5 times smaller? Even the basics are amiss here. There are a lot of conclusions from just two examples of highly complex dynamical systems. The authors poked around and thought a lot, and we know that unfortunately isn't enough to say something believable.

This multiplicative kind of model is happily amenable to time series analysis, so you can do stats to see what your numbers are and how well they fit. That's great. What's less great is the model quality, given that well-tested virality models can be found in other venues. Coffman looks at this, for instance, at http://datacommunitydc.org/blog/2013/01/better-science-of-vi.... The difference in these two types of models is that symmetries in the statement of the problem permit, or exclude, classes of solutions. Those symmetries come from assumptions about the contact graph, the most basic (and testable) assumption.

The grammar of Vega is a description of visualizations, but it isn't a grammar for computation of visualizations. That's where these tools fall short for me, in the sense that they fall short of VTK, VisTrails, and even old OpenDX. I appreciate a regular description, but it seems relatively powerless for data exploration where respect for the model, for uncertainty in data, for symmetries in data, ask for customization of visualizations. Vega is a nice piece of work, and I'd like more, much more.

Reproduction of work sometimes goes by the name "provenance." 1. Record what you want to do. 2. Record how, when, where, by whom it was done. 3. Include ability to run it again. (Exact reproduction is understood to be impossible given everything that can vary in the hardware, OS, and software.) There is an encoding format for provenance, called Open Provenance Model, that can function as a guideline for how to record actions faithfully.

A good example is VisTrails, a workflow application. If you use it to make an image, then you can click on that figure in a PDF, and the URL leads to an online record of what made the image, which downloads to your local machine and runs. You can pick up where the author left off (software, data, internet permitting). Running every program under such a workflow is cumbersome or impossible, though, but it's work in the right direction.

I like that explanation, coming from the data side. I wonder if the article's author is working with data or a model for the data. There is a general rule that, especially for high-dimensional models, only a few parameters are important because eigenvalues of the sensitivity matrix fall off quickly (with logarithmic density). That means the data is well-separate, as you described, and only a few parameters control whether the model fits, while the rest are relatively unimportant. It's a different kind of pointy.

Carter's papers on the subject:

Ballester, P. J., & Carter, J. N. (2006). Characterising the parameter space of a highly nonlinear inverse problem. Inverse Problems in Science and Engineering, 14(2), 171-191. doi:10.1080/17415970500258162.

Ballester, P., & Carter, J. (2007). A parallel real-coded genetic algorithm for history matching and its application to a real petroleum reservoir. Journal of Petroleum Science and Engineering, 59(3-4), 157-168. doi:10.1016/j.petrol.2007.03.012.

This article raises interesting questions. He has done low-level tests which do not read much from the data or instruction pipelines, so these tests show compiled MSIL can be better optimized than C++. C++ is prone to accidental performance deficits from problems like aliasing, so that makes sense.

Now I want to see higher-level tests, where algorithms reading significant data or application-level benchmarks are run. The faster the CPU core, the less penalty there will be from C# compilation. The problem is that it would take lots of time to translate something like WORF, GAMESS, or other standard numerical benchmarks.

Science has error bars.

IPython, with Matplotlib and Numpy, has a ton of numerical libraries, especially LAPACK, which aren't in SHO. Matplotlib is also much more extensive in its capabilities. Some coder cried when they were told to write another Matrix class.

SHO has all the advantages of .NET's ecosystem, so that it can call anything .NET and be called by anything .NET. Making an environment like this should not be about using a Python REPL. You could work on the hard parts - models for asynchronous interactive calculations, or provenance tracking, or helping translate data formats from one API to another - and let the user choose a REPL.