Why bother asking? Is a recruiter going to fly out to my high school and see if they can get records? Interview a teacher that still works there?
You also are likely selecting not for high school calculus geniuses, but for people willing to lie. Presumably they ask because there is a more desired answer, so if you want to get a job you should provide the more desirable answer.
I've spent very little time on ao3, but I imagine it's slightly better than RR where seemingly a mark of value is "huge length (word count and chapters)" with weekly updates.
The metro is a much less stressful experience for me with noise cancellation on. Without them the noise in tunnels just makes me anxious. The outside tracks are all fine without them though.
And for walking around - it's the traffic noise that bothers me, not people. Traffic noise can just be so loud along some roads (and at certain times of day) that it makes me not want to walk at all.
> I was also confused why commit and push are different steps
I think most people think about file access in the word processor terms, like you mentioned. You "edit," "save," "upload," and "download." Actions like that.
Then they have to use git for the first time and the terms/actions are really foreign. It's likely made worse if they have experience with auto-syncing file software, since that software does the whole remote management process for them.
These criticisms of git always seems so shallow to me.
'add' tells git to start tracking some file(s)
'commit' tells git to save the currently tracked files
'push' says "upload my changes to some other location." Git isn't dropbox magically 'rsync'ing the directory to some server.
'pull' says "download any changes from some other location." Same deal as push.
That should satisfy the majority of git casuals that get frustrated with it. You should learn the tools of your trade, and version control (specifically git) is one of the tools of the software trade. If you work adjacent to software why is it so hard to learn a little about git?
Because the same reasoning behind that statements implies that certain races are innately inferior to others. You chose to write "Asians" and "whites" here - why not make the same statement with "whites" and "blacks?"
Saying "Asians" are intellectually superior to "whites" is a thinly veiled way to say "and whites are superior to all other non-Asian/white races."
And the claim that "Asians" are intellectually superior to "whites" isn't even correct "because of race." I'm not aware of any real study that attributed racial identity to measure intelligence. Cultural differences? Socioeconomic differences? Country of origin? Sure. Race? Used as a proxy for the former.
It seems really the problem is twofold: the reference is from 1992 and cites a 1981 publication's reference to an unpublished 1958 generator. Not to say that being old makes the algorithm bad, but it's a bad implementation of an algorithm that already is questionable given more recent research.
I'll go section by section:
> //Apparently the range [1..55] is special (Knuth) and so we're wasting the 0'th position.
This is a silly comment. Knuth explicitly states that "24 and 55 in this definition were not chosen at random; they are special values that happen to define a sequence whose least significant bits, {Xn mod 2), will have a period of length 2^55 - 1. Therefore the sequence (Xn) must have a period at least this long."
Then you have the initial seeding of the LCG with with a = 21 and m = 55, which is interesting. Numerical Recipes uses those values, but Knuth whom they got the algorithm from does not suggest them. The closest Knuth suggests is 24 and 55. This suggestion is from 1981, so the viability is questionable (and Knuth clearly states that this is an unpublished algorithm from 1958 - Numerical Recipes itself questions the quality).
Then they use 21 for inextp - this is wrong. Numerical Recipes uses 31, and that is significant per the period length quote above. The use of 21 should measurable lower the period.
So the implementation is a questionable algorithm from 1958, and it's done incorrectly. Numerical Recipes opens the chapter on randomness almost immediately with: "Now our first ... lesson in this chapter is: be very, very suspicious of a system-supplied rand()," and then the authors of the .NET random package show exactly why that is.
As somebody who regularly reads translated works, including the occasional machine translation (MTL), they (MTL) suck. You got a hugely biased result, which you recognize.
Translation is hard. If you're familiar with reading translations from specific languages MTL works have a very specific smell to them, it's a bit hard to describe but it's there. A good translation is miles (kilometers, for those outside of the US) above MTL.
That's not to say that perhaps the latest LLMs will have better translation abilities, but that they are generally crap currently. Maybe they are fine for something very short, but absolutely not for longer content.
Look at basketball in the US. The best players will tell you all they did as a kid was play basketball. You can go to anywhere somewhat populated and the outdoor courts are in use almost all the time school is not in session for pickup play. Outside of structured practice (if they are on a team), many kids are still playing pickup games or shooting casually.
Soccer fields rarely get use outside of structured play. Kids that play soccer in the US just don't play as much, so their skills are (on average) much worse.
> There isn’t much of a way I can see to remove data centers from the technological progress we’ve benefited from over the last couple of decades.
That's not really the argument.
The problem with the tweet is that the chart kind of sucks, and it isn't immediately obvious. The category cited is "Computer Software and Accessories" which is under "Information Technology, Commodities"
A more interesting category is "Video and Audio services," specifically the live streaming subcategory. People don't buy software anymore, they pay for subscriptions to services.
So IT price index is down, frankly to a huge degree. But that includes hardware, so it's hard to draw conclusions about software pricing from that specific chart. But Video/Audio services have seen a fairly sizable increase in index in the last decade.
But that's not really very important. We are talking about price indexes, which do tell us roughly how expensive something is over time, but who cares about the price of basketballs unless that's something I plan on buying as a consumer? The BLS charts give a relative importance which we can use a proxy for "how much a price change would affect the consumer." The relative important of the IT category (linked) is 0.745, but the software subcategory is 0.029. Video/audio and live streaming are 0.595 and 0.185, respectively.
Consumers do not purchase software. Companies don't even bother trying to sell software to consumers. The chart linked is tracking a metric that doesn't matter, because it's not important to consumers.