Who is "we"? If you had maybe five other studies replicating that second result about stress and sexuality from the past 20 years, I might find it credible. I don't find one study on this topic from 1974 credible enough to believe it.
2,196 karma · joined June 28, 2020
Two reminders are worth repeating:
1. Renaissance isn't unique because of Medallion's returns, it's unique because it achieves those returns on a very high AUM. Other firms consistently hit that kind of return, but they may only do it on an order of magnitude or two or three lower than RenTech can do it. This contributes to returning outside capital. A lot of prop shops set a goal to hit 200%+ and consider it a bad year a failure if they don't hit at least 100%. But they're working with like $10 - 100M total capital.
My personal hypothesis is RenTech's research talent spends a significant amount of time specifically focused on novel ways to scale strategies beyond capacity constraints.
2. It's important to consider fund performance against their own benchmarks on a risk-adjusted basis. Beating the market is great, especially with absolute returns, but it's not the only rational pursuit for an investment. Reasonable investors have different goals. I haven't actually checked, but the non-Medallion funds might still be desirable from this perspective.
Incidentally, 2020 was a great year for a lot of funds. There were a bunch that returned 70%+ on the high volatility.
But I also don't think their predictions have sufficiently precise timing to beat the market. I agree with the thrust of your point, and I probably wouldn't invest my money with them. I think of GMO a lot like AQR in that sense.
A 7% average annual return over 24 years is not necessarily bad. On an absolute average basis that trails the market by 3%. [3] That return could still be legitimately superior to investing in SPY, depending on risk goals, if its volatility and beta exposure is sufficiently low that it beats SPY on a risk-adjusted basis. Then you may even be able to beat the S&P on a total basis, safely, with leverage, depending on the volatility ratio.
Therefore the point you're trying to make would be better construed with an analysis of the beta, volatility and Sharpe of GMWAX. By definition the beta of SPY is 1, and the historical Sharpe is around 0.72. It's correlation with the market is about 1 and it has (again, almost by definition), 0 alpha.
GMWAX has close to total correlation with the market, with a beta of 1.02 and negative alpha less than that of SPY. It has a Sharpe ratio of only 0.34. That means this GMO asset allocation fund is not beating the market, even on a risk adjusted basis. Moreover the explicit mandate of the fund, to avoid market downturns but otherwise track the market's upswings, is not being met. It is both underperforming the market and highly correlated with the market.
1. https://www.schwab.com/public/schwab/investing/investment_he...
Do you have a source for this? It looks like they've been hovering at $64B discretionary AUM since 2014, and that hasn't changed through 2020. [1][2]
All I could find was this article, which I think might be misleading. [3] It seems like it might be conflating GMO's total AUM with the AUM of its asset allocation business, but I'm not sure.
1. https://web.archive.org/web/20150408043537/http://www.gmo.co...
2. https://www.gmo.com/globalassets/documents---manually-loaded...
3. https://www.google.com/amp/s/www.marketwatch.com/amp/story/i...
Sometimes it's also not resume-driven development, at least not intentionally. Sometimes it's because the engineers just want to work on overcomplicated shit. For example I have my personal blog running on half a dozen AWS features - S3, Athena, Cloudfront, Cloudwatch, Lambda, SNS, SES, ...
I don't need any of that for a simple blog, and I write on it like once a year. And the site is still slow as shit (relatively) even though it's static because I haven't optimized the font and script loads to be non-blocking. But it was fun to set up!
Sometimes this is implementation specific, and is numerical instability. Sometimes this is endemic to the algorithm regardless of implementation, like Runge's phenomenon. Often there is no fix, or the fix would be inordinately complicated or only generalize poorly, etc.
In this situation scipy should probably just pop a warning.
1. Mining the users' traffic and reselling it as market research, or
2. Using the users' computers as a pool for a residential proxy service, or
3. Replacing and inserting ads into users' browsers.
This is unfortunately quite common.
There's a lot of jumping around at the 3-year mark, especially for people who want to cash in their FAANG brand for a similar package somewhere else. But once you get to E5 and higher there is significant financial incentive to stay with FB for longer than the initial four years.
Every large security organization requires scanning tooling like Coalfire, Checkmarx, Fortify and Nessus, but I've rarely seen them used in an actionable way. Good security teams come up with their own (effective) ways of tracking new security incidents or vastly filtering the output of these tools.
The current state of CVEs and CVE scanning is that you'll have to wrangle with bullshit security reports if you run any nontrivial software. This is especially the case if you have significant third party JavaScript libraries or images. And unfortunately you can't just literally ignore it, because infrequently one of those red rows in the dashboard will actually represent something like Heartbleed.
Sorry, is this a reference to something?
If you really want a lark, read the typical HN subthread on a topic involving trading, finance or economics. It's like watching the YouTube-educated spar with the Wikipedia-educated. Commenters with real world experience are downvoted just as often as they're upvoted when they try to earnestly correct mundane misconceptions.
Likewise you can't have a bug bounty story on HN without someone repeating the farce that web app vulns have some sort of shadowy black market. There is invariably a comment near the top claiming the security researcher could have received so much more money by selling it to criminals. It is amazing that something so wrong gets repeatedly so carelessly and easily.
These are a substantial number of people here who think they can confidently talk about anything if they just deconstruct it to first principles and treat it like something else they know about.
Why would the burn rate make the results unimpressive? The author just made a comparison to MIT, which has a burn rate 3 times as large, and no one questions if their results are impressive or not each year.
It also seems like a cheap criticism of AlphaFold to say it hasn't solved protein folding by citing the NP-hardness of the problem. There's widespread expert consensus that DeepMind made a spectacular advance in the area, and the author characterizes it by saying, "well, they didn't solve an NP-hard problem..."?
The author seems pretty abrasive to be honest. This is a disingenuous "AI Update" for 2020.
I don't see this changing any time soon. I think Excel was always strongest for last-mile use. Excel is extremely powerful when you know how to use it correctly, and I routinely see people match or exceed the productivity of programmers using it for specialized use cases.
A short article from inequality.org [1] suggests that most of the richest people in the world (Forbes 400) were born with significant financial advantages, if they weren't already wealthy.
Since there are many more rich people than the Forbes 400, that doesn't seem too representative of the usual rich person. It's hard to find anything conclusive - there are a few research memos put out by what seem to be wealth management firms claiming that most rich people are actually self-made. There's a clear conflict of interest here, so I'm not sure we can trust those results.
It seems understudied, and will take a lot more than 10 minutes of searching for relevant results.
1. https://inequality.org/research/selfmade-myth-hallucinating-...
They could have also offered nothing, which was common up until a decade ago or so. Moreover there isn't a market for security bugs like this, so it's not like Google is underpaying relative to some independent valuation.
The only reason to pay more is out of some ethos that the reporter "deserves" more, but that's not how business works. The value Google obtains by finding any given vulnerability approaches 0. This is why, among other reasons, good product security teams spend most of their time doing things other than searching for vulnerabilities in existing code.
Aside from the ethical considerations you'd have to navigate, there isn't a market for vulns like this outside of bug bounties.
People on HN always cite Zerodium or whatever but don't realize those markets exist for vulns with a long half life. The expected return on a vuln which exists in one website is quite bad.
Only if exposure to each scam is independent! I wouldn't expect that to be the case. I hypothesize people prone to falling for scams get exposed to comparatively more scams, and people resistant to scams get exposed to relatively fewer over time.
So your main point stands: delivery of scams has been thoroughly optimized to saturate a vulnerable population and not waste time on a resistant population, compared to a few decades ago.
2. Access control policies which minimize privileges to only those which are needed.
3. Put everything behind corporate SSO instead of per-account passwords and login pages.
4. An authenticating proxy that enforces policies on each individual machine using something like webauthn.
The first recommendation limits the extent to which accounts can be compromised if users mistakenly enter their passwords. The second limits the damage which can be done when accounts are compromised. The third limits the general attack surface of passwords entirely, as does the fourth. In particular: the fourth also allows you to remove your corporate VPN while leveraging SSO. It also makes it easier to enforce the granular access control policies.
These things can be a heavy upfront technical investment, but there are off the shelf solutions and products for each of them. They're also easier than trying to train humans to be superhuman.
No, that's not why it's dismissed. Security experts don't advocate for PGP for two reasons:
1. It requires constant vigilance. If humans en masse were capable of constant vigilance in a security context, we wouldn't really have a problem with phishing in the first place.
2. PGP uses relatively old cryptography which is easily misimplemented and doesn't feature forward secrecy. So again to maximize security you have to rely on your users doing something manual: in this case, generating and sharing new keys at some interval, which then need to be verified on the other end etc.
Speaking to the more general point on phishing: people on HN are usually very overconfident in their ability to spot phishing emails. It's easy to spot simple ones reliably. It's fairly easy to spot pretty good ones when you're expecting it. It's functionally impossible to consistently spot very good phishing emails. I say this as someone who has run simulated phishing email campaigns on software engineers in a large tech company. Even many security engineers would get caught out by the best phishing emails, and what's worse: the set of engineers who would be fooled would change depending on the day you ran it.
Humans are fallible. Attackers do not need to compromise most people in your org. They need just one person with privileged credentials to have an off day and not run through an unrealistic checklist, in an organization with hundreds to tens of thousands of people. The best phishing emails will combine excellent social engineering with a legitimate technical break that privileges them to send email on behalf of a domain. You will not spot this reliably, no matter how technically savvy you are. It will pass the technical checks you have.
The best approach to mitigating phishing campaigns is endpoint security. You should obviate the need for employees to even use passwords in a corporate context, and you should use authentication systems which aren't phishable.
Negotiation is an adversarial game played between humans. Therefore there can't be any simple advice except to get better at the things that make you more competitive at negotiation itself. Instead of subscribing to basic rules like, "never give the first number!", put yourself in a position of being well networked, well informed and experienced. Then you can decide how to negotiate well on the fly according to the context. You will probably earn vastly more by focusing on those areas than you will by diligently following simple rules of thumb.
For example: I received an offer from Stripe and got them to add a $100k sign on bonus to it even though I previously gave the first number. Which party gives the first number doesn't matter.
I'm not usually a fan of interactive plots but I think the one in this article works. It's cool to hover over individual areas and see the significand, exponent and sign bit listed for different values.