You may want to look into pandas as a middle ground. It's great for sucking in tabular or csv data and then applying statistical analysis tools to it. It has a native "dataframe" object which is similar to database tables, and has efficient merge, join, and groupby semantics. If you have a ton of data then a database and SQL is the right answer, but for a decent range of use cases in between pandas is extremely powerful and effective.

Python has the default implementation CPython which compiles python to an interpreted bytecode; there's also Jython which compiles to JVM, and IronPython which compiles Microsoft's CLR. There's also Cython (which requires extra annotations) which compiles to C and thence to machine code, and numba which does compilation to LLVM. Finally there's Pypy which is a python JIT compiler/interpreter written in a restricted subset of Python.

This is interesting. I was just discussing this with my friend last night, and proposed this exact solution. However, it's still a reactive solution. It will detect that you may be the victim of a stingray attack, but it won't stop your phone from connecting in the first place. But there is another potential solution, I just don't have enough experience developing android roms to say how it would have to be implemented. The idea is this: maintain a database of all know cell towers (your link to OpenCellID would do nicely, they offer their DB for download). Using a rooted or fully custom ROM, such as cyanogenmod, have the phone compare any new tower to the database prior to connecting. If it doesn't exist in the database, red flag it and don't connect.

The question is, can this be done on the OS level, or does it have to happen on the driver level? If it can be done at the OS level, easy peasy, just modify the code to establish tower connections to include this check. If it has to happen on a driver level, it gets trickier. Most phones use proprietary binary drivers for their cell radios, so they couldn't be readily modified. However, it may be possible to load an intermediate driver, which in turn loads the proprietary driver. If it could be determined which driver calls involved connecting to a new tower, you could just pass through everything else, and only pass through calls to the tower connect function if they passed your database lookup. Trickier, but doable. Because really, you want to avoid connecting to these things at all. Nice though it is to see you're being attacked, it's better to stop the attack before it starts.

Do you live in the area? I do. The cabs here can suck. A cab in the middle of summer that smells of old smoke, with no AC, in 95F and 10% humidity in the middle of summer is a not good thing.

That said, there are some amazing cabs too - but it's a guessing game. I've been (illegally) kicked out of cabs because my destination was too far or too "dangerous". Cabs get very picky during peak hours on who they pick up and in what neighborhoods they pick up in. Only this year do DC cabs take credit cards reliably, and only because of much-hated and delayed regulation changes based on Uber entering the game.

Do I think Uber/Lyft/etc. need to join in to regulations? Sure. That's a good direction. But sorry D/M/V cab industry, maybe you should have upped your game a long time ago. I have much respect for a good cabbie, but not much for the industry.

A government's just a body of people. Usually, notably ungoverned.

Episodes I through III are only on here so our wise poll overlords can track down anyone who clicks on them, freeze them in carbonite, and ship them off to re-education camps.

Rigorous testing is helpful, but I think it's the wrong approach. The problem here was lack of requirements and/or rigorous design. In the physical engineering disciplines, much effort is done to think about failure modes of designs before they are implemented. In software, for some reason, the lack of pre-implementation design and analysis is endemic. This leads to things like Heartbleed - not language choice, not tools, not lack of static testing.

I would also go as far as saying if you're relying on testing to see if your code is correct (rather than verify your expectations), you're already SOL because testing itself is meaningless if you don't know the things you have to test - which means up-front design and analysis.

That said, tools and such can help mitigate issues associated with lack of design, but the problem is more fundamental than a "coding error."

They are memes in the sense that they are specifically finding words and phrases that are frequently inherited by papers (where "descendant" is determined by citation links), and rarely appear spontaneously (i.e. without appearing in any of the papers cites by a paper). An important feature is that their method used zero linguistic information, didn't bother with pruning out stopwords, or indeed, do any preprocessing other than simple tokenisation by whitespace and punctuation. Managing to come out with nouns and complex phrases under such conditions is actually very impressive. You should try actually reading the paper.

Actually no, they are not. By using citations to create a directed graph of papers they are specifically looking for words or phrases that are highly likely to be inherited by descendant documents and also much less frequently spontaneously appear in documents (i.e. not used in any of the cited documents). They really are interested in the heritability of words and phrases.

I'll stick with my Sirius Cybernetics Happy Vertical People Mover, thank you very much. It may be a bit unhinged, but damnit, it gets me where I need to go (well, when it's not sulking in the basement, anyway).

Wow, I actually didn't notice that until I saw your post. Total deal breaker, which is tragic, I was all about this phone up until the moment of realization. I constantly walk around with at least 2 64GB cards in my wallet, Get a phone with large internal storage, keep all my apps on the internal, have bulk data and media on the cards. Without a slot, my entire mobile storage strategy goes right out the window. This seems like an incredibly foolish design decision, and one that will turn away a large part of the phone's potential market, namely people like me who actually store lots of data (video, mostly, people always trip when you connect your phone to their TV and start playing quality HD movies instead of the trifling low-bitrate shit they're used to from Netflix and the like). The ones most likely to miss this feature are probably the same kind of folks who've been playing with Cyanogenmod for years, too (again, me). And seriously, what would a slot have done to the price of the phone? I'd happily pay the extra to have an SD slot.

Mine is similar - I have a GE AM/FM alarm clock radio with red LED segmented display, but mine is a bit newer - I got I think in 1993. 21 years is pretty good - 100% fully functional (go go pre-ROHS analog radio!) and still keeps accurate time. Only thing wrong with it is the tab on the 9V backup battery compartment broke, so the door falls off if you lift the thing off the nightstand. I refuse to keep my phone by my bedside, so I still use the alarm function.

Contrast to a new one - it was either Emerson or Panasonic, can't remember which - I bought while on an extended work trip where I was put up in an apartment. This was in 2008, and the clock was so inaccurate it would gain 15 minutes a month.

I'd rather choose "Make it easier for people to make their own widgets or form companies to make widgets."

IP laws, some zoning laws, licensing laws, tax laws, accounting laws, and the like all make both making your own stuff or forming companies difficult; limited availability of low-cost machine tools and education makes it difficult to do stuff yourself. These are the things I would reform, not minimum wage or windfall profits tax.

I was trying to avoid being specific about which "things" needed to "cost less" - because any specific list tends to have more problems than a blanket statement like "things"...