On multiple occasions I’ve seen noticeable accumulated rounding error crop up by the end of a cumprod over very long timeseries of floats.
But in my cases it has just been a minor nuisance that I have to double check whether a mismatch came from float-related quirkiness or a code mistake.
I got into the habit of just using integers where applicable for cases that need to match down to the last bit, and numpy.isclose() for inherently floaty cases where it’s anticipated and reasonable.
Only speaking from my own experience, which doesn’t involve chaotic systems or anything like that. I’m curious to hear from people in other domains who may have more exciting stories.
This is a really neat idea! I never thought about taking emissions into account when provisioning infrastructure. Only a small subset of my cloud workload is performance sensitive. For the majority of tasks (tests, background ETL processing, etc) I wouldn't even notice small latency increases.
Interesting. Hmmm, I have to think this through. I believe that if the game followed normal chess rules, except for replacing the pieces with queens, then games where the captures are all even trades would result in draws, but if one side could come out ahead with K+Q vs K, then there would be the usual mate sequence.
HOWEVER the rule OP added that "a piece may only move if it is adjacent to another piece of either color" slightly complicates the endgame. My normal tendency would be to put the queen far away from the action to avoid blundering it, but here that would instantly deactivate it. It's kind of funny to picture the kings racing across the board to capture or reactivate the last inert queen.
I think one can still get the usual style of mate in this variant, you just have to walk the king and queen together, and pay extra attention to avoiding stalemate. For example, imagining white king on e1, black king on e3, black queen on d3. If white to move then Qb1# or Qe2#, fairly standard maneuvers (though if black to move that's a stalemate).
This is an interesting modification to the game, I'd play a few rounds...
I use a few different distros on a routine basis. Out of those, Ubuntu would probably be the best fit - it generally works right out of the box, the UI is intuitive for day-to-day use, there's plenty of information online about how to install/use/troubleshoot it, and the App center has an open source alternative for anything and everything. Mint might also be a good fit - I had a very positive experience last time I used it, but that was a few years ago so I haven't tried the newer releases.
> I suspect what's happening is they've got some rule against the word "spectrum" or something
I've avoided this by using only the first few and/or last few letters of the service in the email tag (e.g. "HaNe" instead of "hackernews"). It's an easy filing system for me, doesn't trigger concerns about phishing, and makes for shorter handles.
I have a personally-owned domain name connected to my [paid] account with a smaller email provider.
The domain is managed at a large well-known registrar, I keep it paid up 3+ years in advance, and make sure to keep my contact information up to date.
If anything goes wrong with the email provider (including going out of business), I will just redirect from my DNS settings. If I get locked out of my domain for some reason, there are clear next steps for me to open a ticket with the registrar and move towards resolving the issue.
I got it all hooked up in an afternoon, many years ago, and it was completely set-it-and-forget-it, besides logging into the registrar occasionally to extend the domain ownership.
(continuous backups are another matter - mine aren't fully automated yet)
You might enjoy learning Lean, which is a functional programming language specifically for theorem proving. You can tackle interesting types of questions, and it is actively used in mathematics research.
Back in 2018 I spent a week or two messing around with this idea, and produced a hacky proof-of-concept.[1] It's not intended for real-time or production use, I just made a prototype to see if it could be done.
The README explains the method: once the contaminating song is identified, it syncs up the recordings in time with a correlation analysis, adjusts for frequency-dependent gain effects, then subtracts the undesired content.
Warning: I'm not an audio engineer, the output sound quality is NOT good! This was just a toy project in my early days of learning to code. I assume there are much better ways to approach this that would yield significantly better results.
For personal correspondence, I've exclusively used Proton Mail for the last 7 years or so. I have been happy with it, no plans to change. I migrated from Gmail, and initially set up message forwarding so that I would still receive emails from old contacts. A few years ago I connected my personal domain with Proton so that I can send and receive from @mydomain.com - their setup wizard was quite helpful.
I've also used the calendar, drive, and VPN products. They all seem to work well in my experience of light day-to-day personal use. For the email and calendar products, I interact with both other Proton users and people using other providers (Google products, company-administered systems, etc) and it seems to integrate seamlessly. If you use Google docs/sheets/slides, it can be convenient to set up a Google account tied to your Proton Mail address, with no associated Gmail addresses.
In addition to what others have mentioned, I find it really helpful to temporarily switch my IDE to high-contrast light mode, when working outside in bright conditions. Otherwise I prefer dark mode.
A larger and/or high-contrast mouse cursor can be helpful too.
Politely mentioning that you don't want to work on holidays could be a great answer if they ask why you're looking to change companies. You could just say something like: "I'm looking for a job that allows me to spend holidays with my family." (and leave it at that)
It's a totally normal expectation, the explanation doesn't reflect poorly on you or your past employer, and it sounds like it is genuinely important to you.
On multiple occasions I’ve seen noticeable accumulated rounding error crop up by the end of a cumprod over very long timeseries of floats.
But in my cases it has just been a minor nuisance that I have to double check whether a mismatch came from float-related quirkiness or a code mistake.
I got into the habit of just using integers where applicable for cases that need to match down to the last bit, and numpy.isclose() for inherently floaty cases where it’s anticipated and reasonable.
Only speaking from my own experience, which doesn’t involve chaotic systems or anything like that. I’m curious to hear from people in other domains who may have more exciting stories.