877 karma · joined February 26, 2015
Venting refrigerant is illegal in most of the world but it's almost impossible to enforce and compliance is typically quite low (good data is, as you can imagine, difficult to find). CARB in California now requires owners of large refrigeration systems (>250 lb of charge IIRC) to report all refrigerant recharge to the state so at least there's some efforts underway.
The beliefs of professional traders about whether a stock will go up or down is already baked into the price. If you believe a stock is going to go down, and you are right, you can make money by shorting it.
While this is unrelated to the core security of the application from a technical perspective, to me it seems shockingly sloppy and evidence of a severe lack of security mindset within the development organization.
For comparison, gmail sends a confirmation code to the destination inbox that must be entered into the source email account.
Has anyone come across other good implementations?
As a side note, I've been doing more probabilistic programming with pymc3 recently, and it's pretty incredible how leaky the abstractions can be. I'm not saying there's a way to do better, just that at present there's a huge gap between the beautiful vision of "the inference button" and the current tools.
1. Structures knowledge about common statistical tests, the assumptions they need to satisfy, and the kinds of problems for which they are appropriate.
2. Models this as a constraint satisfaction problem.
3. Creates a DSL to write specifications for statistical testing.
4. Develops an output format for statistical testing based on (3).
5. Provides a python package that implements the above.
IMO (1) is by far the most fundamental of these, but the paper spends most of its time describing (3). I'll admit to not fully understanding (2), what the alternatives were, and why it's an appropriate choice - I wish there were more on that in the paper as well.
If the approach to (1) were described in more depth and published in a usable way outside of the implementation in (5), I could see it being broadly useful and leading to an ecosystem of different (competing) implementations. As it stands, the work on (1) is spread across a few functions in solver.py.
Looking more broadly, statistics-as-an-HCI-problem is fascinating, and I think this is a promising start. I'd also love to see more attention paid to (4), the output format. Most "doing harm with statistics", I believe, comes from misunderstanding/misapplying results, so looking at the full workflow / user story is critical. The focus of this paper is instead making the input easier, which is also obviously important.
emjun, so glad to see you in the comments here! What's the best way for interested folks to contribute to this project?
> although I don't have any statistics to back me up, I'd guess that most events happen in clusters
More seriously, yes, before you apply this rule you should think about whether "each event has the same probability of error" is appropriate for your situation.
* a rental vacancy rate of 4.2% (8th lowest out of the 75 largest metro areas)
* a homeowner vacancy rate of 0.7% (11th lowest)
The rates were similar for the San Jose-Sunnyvale-Santa Clara metro area. It's possible there are issues with this data, or that it's not measuring the phenomenon you're discussing, but this certainly seems to suggest that SF doesn't have a ton of vacant properties.
I also don't think our only alternatives are "trust these companies to self-monitor", or blockchain.
I'm thinking about 2 kinds of solutions: 1) technical solutions which would improve the current chain-of-custody tracking (this could involve blockchain, but it doesn't have to). 2) policy solutions which might involve something like "less frequent, but more rigorous testing, with stronger penalties".
And I'm confused by your statement "Requiring submission of soil samples is rather expensive, and fairly strong control, because cheating is a very deliberate act." - but what these instances prove is that corporations will cheat anyway.
"Separately, FDA chemist Narong Chamkasem found “over-the-tolerance” levels of glyphosate in corn, detected at 6.5 parts per million, an FDA email states. The legal limit is 5.0 ppm."
Here[2] are the FOIA documents they're citing.
The original article does link directly to an email with the 6.5 ppm figure[3].
[1] https://www.theguardian.com/us-news/2018/apr/30/fda-weedkill...
[2] https://usrtk.org/pesticides/fda-foia-documents-regarding-gl...
[3] https://usrtk.org/wp-content/uploads/2018/04/Over-the-tolera...
http://blog.danieldavies.com/2004/05/d-squared-digest-one-mi...
This reminds me of the ongoing Tetra Tech/Hunter's Point scandal [1], where the US Navy paid $300M to a contractor to clean up a development site. The contractor was required to submit samples from the site to prove they had cleaned it up. Instead, they just pulled soil from known clean places and submitted for testing.
How much of the ongoing monitoring activity that our government does relies on good faith from companies? Is this the tip of the iceberg, or do the fact that these cases get caught prove that the meta-monitoring is working well?
How can we improve this state of affairs?
[1] https://sf.curbed.com/2018/1/26/16916742/hunters-point-shipy...
"the name, address, length of service, and electronic communications transactional records for all services, as well as all accounts, provided to the individual(s) or identifier(s) listed below."
The letter explicitly says not to provide information "that would disclose the content of any electronic communication".