omegalulw

Other than normal CDN stuff, are REST APIs even common today? IMO everyone wants to track users, sell targeted ads etc which requires maintaining state and eventually you diverge from REST.

Fair enough, and you seem to know more about character encoding than I do so I won't argue lol. I'm standing on a glass house anyway as I use password less sudo haha.

But why? Unless you are targeting Linux users or devs in general, nobody will obfuscate like this. And to decode this you (your bot) need to run untrusted code. The upside has to justify the work securing your bot.

This is just saying "do not run untrusted code" with extra steps. If you don't trust the source the code came from you should not executed any line.

I mean is file size really a concern? I would rather have a 300 GB game with something like quixel megascanned assets than procedurally generated crap.

The latter sounds nice but in practice game execs just use that to cut corners and you end up with an unrewarding grirnd fest of a game.

While this is true, it's also more of a crutch. You should practice to predict, before your rebase, what conflicts your are gonna hit. And aborting a rebase is a significantly safer option. I would only recommend reflog when you rebased (on) the wrong commit and you want to undo a successful rebase.

> If the test suite is ten hours and you have ten commits on a branch then it quickly becomes silly to bog down your build servers

That's a fair point, but I would say that if you encourage your devs to make each commit logical, meaningful and self contained, this is worth the extra cost.

Also, you don't need to run ALL unit tests - just the ones affected by commit you are testing. This of course requires a build system with good dependency analysis.

Wouldn't it be better to run the experiment longer _and_ discard the data from initial few weeks?

> If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits.

+100. Though every time this comes up on HN you would be surprised by how much some people just vehemently disagree.

I will also add another requirement - all unit tests should pass at each commit in the PR. That way, you can use the rebase strategy to merge and you would still be able to bisect.

It doesn't seem to cover contextual word embeddings though which are all the rage since BERT came in.

Saw the article later, they use monkey type too. I would love to see them in the 30s test.

Yup, having to type unseen text makes a lot of difference.

Here's what I personally use to test my keyboard setups: monkeytype.com.

My best is ~95 WPM and 100% accuracy.

> the universe is younger than we thought,

Not really. Don't we estimate the age of the universe by estimating how redshifted the CMB is compared to what we would expect given initial conditions?

> But this suggests a real breakthrough is needed to keep pace with future requirements.

Not necessarily. Look at papers like the lottery ticket hypothesis - big ML models may be doing better simply because gradient descent just isn't doing a good enough job. Better optimizers would go a long way than just throwing compute at the the problem. Even if you can, it's impractical to use something like GPT-3 all the time.

I guess that link will underestimate the number of near misses but looking at https://en.m.wikipedia.org/wiki/List_of_asteroid_close_appro... the number of 100m+ objects isn't that common?

But if you want to "nudge" an otherwise near miss asteroid you gotta wait till however long till it comes around, which can be 1000+ years?

From https://www.britannica.com/science/Earth-impact-hazard/Frequ...:

> Because there are far fewer large NEOs and long-period comets in space than smaller ones, the chances of a collision decrease rapidly with increasing size. The impact-hazard community—primarily scientists with an interest in the issue—has defined a global catastrophe to be an impact that leads to the death of one-fourth or more of the world’s population. An impact by a 1-km- (0.6-mile-) diameter NEO, the smallest believed capable of causing such a catastrophe, is estimated to occur about once per 100,000 years on average, based on the assumed population in space of such objects. On the other hand, an impact by a 100-metre (328-foot) NEO, the smallest believed capable of causing regional devastation, is estimated to occur about once every 1,000 years on average.

I mean not really? That scene [SPOILERS AHEAD] always seemed like a plot hole to me - you need massive Delta V to change trajectories of objects in space to hurl them towards earth and you need them to be massive to not burn up in the atmosphere. That takes a loooot of juice.

It's much easier to use the "Rods from God" idea - that is more precise and minimizes collateral damage.

Try torch normalize "-1" 1

It gets me to https://pytorch.org/docs/1.9.1/generated/torch.nn.functional...

Note that that will only normalize to (-inf, 1]. Tweaking the formula on that page You want (v - vmin) / (vmax - vmin + eps) with vmin and vmax produced along th dimensions you care normalizing against.

I'm curious if you have examples to back up your claims?

> I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict.

Not really?

With git you just keep track of three things:

1. The actual committed code 2. Code that's in the staging area 3. Code on disk right now

(git has official names for these but I forget)

Then during a rebase, if there a conflict, the base comes from the parent of the commit (in 1) you are applying the new commit on top of and the conflict is basically how the new commit makes changes w.r.t to the latest commit in 1. This conflict is written to 3 for files that are in conflict (and to 2 for files that aren't) and then you can resolve the conflict in 3, move the new code to 2 and commit that to 1. You can think of all of it in terms of diffs.

Isn't this a trivial example though? You require bucket size >= 10 say.

Full on differential privacy is meant to address harder problems. For example, if you assume that there was a minor bug and people were asked to take the mandatory yearly survey again in a week.

Now if you assume that the responses of people who responded before will stay the same when they re-respond, then by taking the difference between both results you can identify some specific people by looking at which bucket counts changed - this would be how the new guy who joined in that week voted.

Differential privacy techniques are meant to anonymise data in way that you can't even do this.

I'm confused about the first point. Is it simply restating that Fourier coefficients are complex numbers?

The goal is to produce real valued noise - you won't get that if the spectrum is not mirrored.

> it inevitably fails on large projects.

This is not even REMOTELY true. Plenty of companies use massive pure C++ projects.

Sry, I had a brain fart again. My solution won't work, it's for a different problem. I can't delete comments from my phone and I think for the addition problem it's a reasonable solution so I'll just leave it.

Thanks! Reading my comment again it's clear I had a brain fart during writing the comment but I was indeed trying to solve: find b such that (a + b) % n == 1.

Of course, assume a and n are relatively prime.

Then this is equivalent to finding a b such that (a % n + b % n) % n == 1.

We already know that 0 < a % n < n so simply picking b = n + 1 - a % n works. In fact, b = zn + 1 - a % n for any positive integer z works.

Your solution makes sense to me too but I wonder if I'm missing something obvious above?

Is finding b such that (a * b) % n really that much work?

It's (a % n + b % n) == 1. So pick b = a + 1 - a % n and you are done?

> Please stop suggesting that SQL Injections are a sanitization problem. They are a problem of escaping in the application constructing the query, not a problem with whatever the user has typed in.

How are they different?

> They're deliberately optional so device manufacturers aren't forced into a ridiculous all or nothing situation.

Thats so anti consumer.

I agree and disagree.

When you are familiar or at lease somewhat familiar with a code base printf + careful thought is King. It also has the added benefit of forcing your to think through related edge cases you are missing or will miss if you fix the bug in a certain way.

But when you are working on a massive codebase with significant state being maintained, a debugger will go a looong way.