When you say entitlement, it evokes a bunch of money-grubbing welfare queens who have more and more children to increase their federal benefit. The truth is that the largest portion of the budget (24%) is social security, which isn't a government handout - it is funded by working taxpayers who have paid into the system for their whole lives.

Things that might be considered entitlements, or uncompensated financial assistance to the unemployed, disabled, etc. make up only about 12% of the budget, not the 2/3 you disingenuously claim. Source: http://www.cbpp.org/cms/?fa=vi...

What I'm confused about is why it isn't an "entitlement" when we give massive cost-plus contracts to defense contractors with no requirement that they actually produce products that perform as promised (JSF, or any number of botched projects with no accountability). Or force our nation to give them handouts to build overpriced, technically inferior products (SLS) when free market competition offers far superior options (Commercial crew). The point isn't just that the military budget is massive (though it is), it's that much of the spending is propping up useless programs, developing technically complex boondoggles to fight enemies that don't exist. We're getting the worst of both worlds, the bureaucracy and inefficiency of government with the greed and short-sightedness of industry.

Granted, I don't have much experience with R, but Python has some notable benefits - it is very well established and you can find tools to do just about anything. It is fast and easy to develop, and very easy to learn thanks to the readability and plentiful resources online. I imagine you'll have an easy time finding people with python experience, as well.

I haven't used it for any "big data" tasks, but for a number of small, interactive data analysis utilities it has been really enjoyable to work with. One standout tool for me has been pyqtgraph, which is lightning fast and creates some really impressive interactive visualizations. It's also got some pretty incredible features out of the box - arbitrary user-definable ROIs, instantly change any plot to a log-log, or even do a Fast Fourier transform with just a right click. If I sound like a fanboi, I kind of am - after trying to deal with the agony of 3D data manipulation in matplotlib (python's matlab package), it's a whole different world.

Others have said it, but I'll repeat: This video format sucks compared to the usual slashdot interview approach. I usually look forward to Slashdot Q&A's because there's an opportunity to have your exact question answered by someone, and so it gives lots of us who comment the next best thing to direct correspondence, assuming that your question is worthwhile enough to get upmodded.

This video, in contrast, is annoying to parse. Yes, there's the transcript, but I don't see him answering my specific questions, and it is a pain to read through a bunch of general and less articulate speech-to-text rather than getting a concise and direct response.

I could've forgiven you using this format if you still actually read him the questions that were written and voted on by us, but it seems like instead Tim decided to shit on that so he could have a Google hangout and feel important.

Maybe my description wasn't clear. These were two oscilloscopes, reading from the same source in parallel. One scope was looking at a high resolution, set to trigger on anything above noise, but with something like a 1V maximum amplitude (hence clipping at 1V). The second was set to trigger at anything over 1V, and had a much larger view window, so there was no data lost to clipping.

The motivation here was to get detail data while simultaneously making sure to capture the full amplitude of big signals. Neither scope had an appreciable impact on the signal of the other. Once I figured out the problem, which was that there was not in fact a 1:1 correspondence between clipping on scope 1 and triggers on scope 2, a good-enough algorithm was stupidly simple - just check if the signal reached its maximum for >3 consecutive samples, and it performed about as well as a human would.

I think the overall point he's making is that visualizing an algorithm's behavior can offer us better insight, faster, vs. just looking at our code and our error logs. I'm sure there are ubermensch programmers out there that never have their programs exhibit unexpected behavior, and always understand exactly why a test fails, but I'm not one of them.

I encountered this firsthand when I spent a couple of days trying to write a simple algorithm to detect clipping on an oscilloscope output. We had a secondary scope set up to trigger at the clipping level for the first, and so my target was to find as many clipping events as triggers on the second scope. My first several attempts failed, and I never got a direct match no matter what I was doing. Finally, I spent an hour or so coding up a visualization that would show the waveforms and pinpoint exactly where the program thought it detected clipping, and it became immediately clear to me that my initial assumption for my test was invalid - there were many times that the backup scope triggered without clipping on the first, and that clipping happened on the first without a corresponding trigger on the backup scope. It turned out that this was because of big transients showing up while the first scope was rearming, and vice versa - but without actually looking at the data and behavior of the program I would have kept wasting time thinking my algorithm was broken.

Of course, that's a unique situation, but I think the point still stands that our brains have a very powerful capacity to process visual information, and that sometimes an hour or two to slap together a visualization can pay for itself pretty quickly. Once you get familiar with the tools to make these kinds of visualizations, it can become very straightforward to develop one for your specific use case.

Interesting, thanks for that. Learned something new.

How would you respond to critics that believe that as soon as the Mayday PAC raises a substantial amount of money, all the other PAC's, along with the commercial media (who are the main beneficients of political spending) will jointly work together against the Mayday PAC and overwhelm it with superior resources?

Why do you believe that forming a PAC to elect reform-minded candidates is more promising than Wolf PAC's method, of bypassing the typical political process and trying to call an Article V Convention for the purpose of limiting the influence that money has over our political process?

What kind of accountability exists with the Mayday PAC to ensure that representatives elected due to this funding actually follow through on promises of campaign finance reform?

I toured Lockheed Martin's facility in Colorado Springs a while back - they have a system they developed (and tested!) that can extract hydrogen and oxygen from lunar regolith. One main byproduct was fairly pure titanium dioxide, and they had proposals in place to extend the system to make cast titanium parts. If you have enough energy, anything is possible - imagine if you could use 3D printing and laser sintering to build custom titanium parts, while getting water and fuel as well. It's technology like this that will make it feasible to open new frontiers. Although as you mentioned, you need something substantial, like a nuclear powerplant, to make this work. Energy makes or breaks the entire thing.

This is not really about the existence of bad compiler optimization - it is about a tool called Stack that can be used to detect this, which is known as "unstable" code, and has been used to find lots of vulnerabilities already.

Either with new plot elements or with physics, probably some combo of both though.

I don't know orbital mechanics well enough to say (particularly under constant propulsion), but could you argue that they needed to move to a larger orbit to avoid solar flare radiation/aliens/asteroids?

The other question would be if you've specified how much propulsion is provided. If we're talking .01 g, that's a much different scenario than 1 g, in which case you would do better to write in artificial gravity or centrifugal gravity because the time frame would be so far off.

In the low-acceleration case, you could also argue that the craft starts in LEO and takes a long time under constant, low acceleration to reach escape velocity, which would certainly work, but would cause the crew to have remained near the earth for a very long time. I suppose the same thing could work on the other end - the craft comes in at a very energetic orbit to Mars and then spends a long time with low acceleration to bleed off that velocity until they are slow enough to re-enter without burning up.

Sorry, don't know if any of this conflicts with existing plot points as I've only read one or two entries, but perhaps there will be something useful.

Actually, OP is completely correct. I just sat in on a series of NASA talks on cubesats (NEPP, look it up) - they have huge problems with radiation and reliability because there isn't the budget for the testing and qualification that happens with typical satellites. Translation: 30% failure rate in benign environments. For reference, we're talking about systems that are (mostly) good up to 1-4 krads of ionizing dose, while projections I've seen for the Europa environment are ~ 2 Mrads. Or 2000 krads, if your metric is rusty. So we're talking about as much as 3 orders of magnitude more dose, with a system architecture that already experiences horrendous failure rates.

I don't know anything about Draper systems, but unless they've included mass budget for some serious shielding (look up JUNO and the "vault" they used for their electronics) there's no way this thing will last long enough to do useful science, if it even survives the trip there. It's entirely possible that this entire thing is the brainchild of a couple of postdocs who took some classes on spacecraft architectures but no nothing about how rad-hard electronic systems are actually developed.

Now, it's certainly possible that this project would be in a different class of cubesat, and they might be able to afford real, rad-hard components with Mrad range dose tolerance, but even so, Jupiter is one of the harshest radiation environments in the solar system, and satellites with traditional, expensive development cycles still have mission lifetimes of several months, tops. The only real way I could see them being successful is with rad-hard components and an extremely short mission profile - show up, dump the chipsats, and beam back some data as fast as possible before your electronics go insane and melt.

Challenge accepted. *grabs bourbon*

Some of the money is from NASA's commercial crew, etc, but that is a few launches a year. Have you actually looked at SpaceX's launch manifest? They are booked solid through 2017 or so, with a variety of customers. They have set a target to capture 50% of the launch market for Falcon 9 class vehicles and they are well on their way to doing so. What's more, the lower costs they are providing are bringing a lot of previously unprofitable business models out of the woodwork, which become viable as soon as launch costs head downwards. Google's whole Teledesic v2 initiative is enabled by this, and that's hundreds of satellites. Lower costs are changing things, and we can't make the old assumptions any more.

My initial statement was in terms of delta v. LEO from Kennedy Space Center takes ~10 km/s of delta v. Mars from LEO is ~ 5 km/s. So, indeed, you are about 2/3rds of the way to Mars capture once you have reached LEO, in terms of the propulsion required. There are other difficulties, but we know fairly well how to keep humans alive in space for long durations thanks to the ISS (on the scale of many months which will be required for a Mars transfer), and there's good reason to believe that transferring from space to Mars will be less difficult for the body than space to Earth.

With respect to the radiation risk, I will copy something I posted in another reply:

The end result is, there are no deal breakers here, and while I agree that 12 years is aggressive perhaps to the point of folly, I think that the 2040s projections are weakminded and equate to never accomplishing anything, since we've got no demonstrable capability to keep our focus for that amount of time.