Not sure if this counts as a positive post but at least it seems balanced and informative.
3,470 karma · joined November 18, 2009
Bubble cursor:
https://codepen.io/anon/pen/bjwKdX
Not sure if this counts as a positive post but at least it seems balanced and informative.
The above article recently posted to HN doesn’t fall clearly into “steals IP” or “can’t invent their own stuff”.
https://news.ycombinator.com/item?id=29790830 This one is also related to primes.
This has library contents: it’s a mix of various utilities - type conversion, data structures, memory management, random numbers, concurrency, etc.
I've still had some issues with some applications not scaling their widgets properly, but it's mostly ok.
I'm not familiar with the Eurovision show you mention, so not sure of the relevance.
The paper does actually seem readable, especially at the beginning, but it's dense and long. Somewhere between the article and the paper in terms of complexity and technicality would definitely be interesting to me, although I realise it's a lot of work to produce something like that.
Interestingly the paper acknowledges collaborators who have helped via MathOverflow. I wonder if a collaborative site for explaining maths papers in more detail could be viable. After all, even xkcd.com has explainxkcd.com. Like you, I am not sure what this would like, but it would be fun to find out.
I guess I'm just greedy for more of the same.
Helfgott and Radziwiłł’s solution to the logarithmic Chowla conjecture marked a significant quantitative improvement on Tao’s result. They could sample over far fewer integers to arrive at the same outcome: The parity of the number of prime factors of an integer is not correlated with that of its neighbors.
It would be really interesting to have a commentary to go along with the proof to help bridge this gap. This could explain why choices are made in the proof and help to visualise the implications.
This article comes close in some ways, for example with the examples regarding multiplicativity of the Liouville function. OK, it is a 100 page paper, so understanding the details of the proof is going to be tough. It would still be fun if there was a way as an interested reader to step up from reading this type of article to at least understanding the abstract of the paper.
https://steamcommunity.com/app/333300/discussions/0/26463606...
Relevant Wikipedia page
There is a link in the description of the video you shared to an extended version showing more how the animations were created from videos.
Maybe two VMs, identical program loaded on both, pick a leader through synced messages. You can't do this unless there is something different about the VMs. If one VM goes first it's easy (just use its suggested color), if there is a hardware RNG, easy (iterate until one VM rolls higher than the other, then use the last suggested color from that VM).
If the programs are different (as "maximally logical" is vague), then it comes down to some kind of analysis of the output of an arbitrary program, which is impossible in the general case. You then have to assume some kind of shared knowledge (red most likely, rgb averaging is most likely way to blend, known mots likely ordering of colors such as alphabetical) to make progress.
You have two VMs, VM one has a program pre-loaded that takes an optional tuple (bool endGame, rgb agreed_color, string message) and emits a tuple in the same format. The message from the emitted tuple is used as input to a similar program on the second VM, the output message of which is passed as input to the first VM.
Both VMs also send their output to a judge which decides the next stage of the game as follows:
The game ends with a win if the output from both programs includes endGame set to true and agreed_color set to the same as the other program. If endGame is set to true by either program then the game is lost unless the win condition is true. Otherwise the game continues.
You need to write the program on the second VM without knowing the program on the first VM. However you can assume a "logical" program is loaded. If we assume this means you can send code through to execute on the other machine: eval(message), then we can simplify the problem to loading the same program on both VMs and executing it.
This is easy as is, program both machines to output (true, red, ""). So to make it interesting there needs to be some complications.
Effectively there is some hidden state on the first VM. Maybe this could be modeled as a random permutation of the color space on the first VM such that any reference to a color is first permuted before being output, including within messages.
This would mean the initial program above could now produce (true, blue, "") on the first VM. However, the programs are identical and don't know which VM they are running on.
Is this a good model for the problem? How could we improve it to add a solution?
No harm to step down or out for a bit and come back to it when you're ready if you're burned out. Rotating the management and developer duties might reduce your pressure if it makes you feel you've got more back up.
Consider pair programming if you're doubting yourself, maybe with both weaker and stronger developers to help benchmark your skills more accurately.
External training or mentorship might help you to get another perspective on your skillset.
Also consider whether there are any external factors such as your upstream management, clients, or the market that you are in that are stressing you out. It may be that the worries about development skills are symptoms of another issue.
As a senior team member, you should have a lot of scope to choose the work that you think is the best fit for you. Taking some time to think about this is part of being a manager, and as a senior developer your development skills are not something you need to worry about too much - you can bring these up quickly if you need to, and you probably don't need to right now. You've gone through a stage of worrying about what you can bring technically to the table, and that's not your focus right now, which feels uncomfortable. It's OK to follow the flow of your career and see what happens, you can reset down the line if needed.