Yeah and this is a much more intuitive way of generalising from the n = 2 case. Weights are proportional to inverse variance even for n > 2. Importantly this assumes independence so it doesn’t translate to portfolio optimisation very easily.
It’s fine to be non-rigorous as long as you’re not a jerk and treat your own conclusions on relatively little data as preliminary.
Sometimes it’s good to have some information with relatively large error bars and be willing to update quickly rather than ignore information because the error bars are large.
From the article it doesn’t become apparent that the author wouldn’t update her views quickly as new information comes in (eg by talking to someone).
So yes the observations in the post are not scientific, but there’s nothing preventing them from being the starting point of rational reasoning and behaviour.
Conditional on “the study being published and getting attention” the real effect is likely smaller and not larger.
Eg if you assume there is a real effect plus a lot of noise, given the study has been published etc the noise will have more likely acted in the favourable direction.
IMHO given the relatively large size of the effect it seems quite likely that the noise part is in fact potentially large (this is much more subjective) which makes is less clear that there is measurable signal at all here. I’d have to see a lot of replication or a very strong explanation of the underlying mechanism to believe the magnitude of the effect, but will very easily believe the sign (with a small magnitude).
This is very common in finance. Knowing when finance research that made right predictions with good justifications falls into the "Gettier category" or not is extremely hard.
There are many people in group 1 in academia eg in physics and maths that are comfortable with latex and scripting languages but mostly use email to share files.
Anything that helps them organise their collaborative work better without having to deal with git helps (eg see eg success of overleaf).
Part of the problem is that git is a fairly poor fit for these workflows.
I spent time getting some mathematicians working together via version control rather than email, it was a bit of a mixed bag even using something simpler (e.g. svn). Eventual we moved back to email, except the rule was email me your update as a reply to the version you edited, and I scripted something to put it all into a repo on my end to manage merges etc. Worked ok. Better than the version where we locked access for edit but people forgot to unlock and went off to a conference...
If I was doing the same now, I'd probably set up on github, give each person a branch off main, and give them scripts for "send my changes" and "update other changes" - then manage all the merges behind the scenes for anyone who didn't want to bother.
I think expecting everyone in a working group to acquire the skills to deal with merge issues properly etc. is too far if they don't do any significant software work already. In the latter case., teach them.
Surely you've worked with other traders who get confused by import statements. Whole point of this file is to provide a common interface for common math operations that might be exposed by either plain python or pandas/numpy functions.
You're obviously not the target market if you're able to review good and bad code.
https://github.com/mscroggs/realhats
reply