Mathematicians aren't forced to take IQ tests. This could cause self-selection bias.
123 karma · joined March 4, 2014
== 10 ^ 38
== (2 * 5) ^ 38
== 2 ^ 38 * 5 ^ 38
== 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5 * 5
Are 2 and 5 not prime?
It's much easier to read than you might think.
The easiest examples of unit tests are math functions, since they're so well-behaved.
Here is a square root function in Javascript:
function sqrt(n) {
guess = n/2;
while(Math.abs(guess*guess - n) < 0.00001) {
guess = (guess + n/guess)/2;
}
return n;
}
assert_equals(4.0, sqrt(16));
The call to assert_equals there is a unit test. (Also, keep in mind that assert_equals is a glorified if statement)
"well, what isn't a unit test??"
Since we can call anything we want a unit, the answer is "whenever we say we aren't doing a unit test". But a more practical answer is: whenever you're testing the interaction between two or more units (where a unit is a function/method).
If you're making a video game, you might have enemies who can jump, and guns that can fire. It would be a unit test to check if enemies jump correctly, and it would be a unit test to see if guns fire correctly. It wouldn't be a unit test to see if guns fire correctly from a jumping enemy, since this is the combination of two pieces.
Another way to (sort of) define a unit test is to say "how does this behave assuming that the rest of the system is correct"? That is, we aim to check the behavior of our code in isolation from the rest of the system.
This is important when something is wrong, because if we know what is behaving correctly, we don't have to waste time checking if it's the cause.
If you run `vim -u NONE` and then open a file, is it still slow when you hold j?
It will increase the cost of labor, and result in fewer, more expensive goods and services.
We can both claim things all day.
The opportunity cost of a service is the limit for which one would be expected to pay for it. If forced to pay $1,000,000 to have someone clean your bathroom, you'd end up cleaning it yourself.
Claiming that I'm too unreasonable to debate with won't win you any points.
> Also it sounds weird to talk about people's labor as if they were potatoes
It's not weird since it's something that has a market value. People are not their labor. Someone's labor can be bought and sold, and the availability and price of labor is subject to the same economic laws as potatoes.
Some potatoes are worth $0.60 but not $0.80, and if the price of potatoes were dictated to be $0.80, the $0.60 would go in the trash.
I don't want potatoes or people's labor to go in the trash.
If it was just the mechanical switch, you can always desolder out the old one and solder in a new one.
Once I understood this, things like merging and shallow clones made a lot more sense.
Although it makes rebasing more confusing. What's happening there is that git is creating patches on the fly, and then applying them to the new base, and creating new commits. But the resulting commits are snapshots of what the files would have been had you applied the patches yourself.
Of course, there can still be "merge conflicts" since both branches might make changes to the same place in the same file. But since everything is a snapshot, if you have no pending changes in your working directory, hopping around the commit history is a safe action, so long as you have a branch pointing to where you left off.
If you go into `.git/objects` and find the file whose name is the hash of your most recent commit, you can decompress it (zlib inflate) and the first few characters of the file will be something like "commit 485\0tree 6f3eeb2952a...". This tell us that this object is a commit object of size 485 bytes, and then after the null character is the commit itself. If you then take that tree hash and do the same thing, you'll see a list of blob hashes next to filenames, and tree hashes next to directory names (in a tree object, git stores the hashes as the raw bits, instead of ascii encoded, so if you want to follow the hash list, you'll have to convert the hashes to their ascii equivalent to find the appropriate object in the object store).
You are correct that git uses deltas, but it doesn't use them for commits, it uses them when it recompresses your objects into a packfile (which happens when there are too many loose objects or when you pull and push).
Every commit can reconstruct the state of your project at the time the commit was made. Each commit can do this without the help of any other commit.
man git-commit
Record *changes* to the repository
It's no wonder people get confused, if the docs do nothing to alleviate confusion. A commit is a snapshot of a directory, not a list of changes.
Even if it was, does it make Airbnb wrong? Should people not be able to freely make living arrangements with whom they choose for arbitrary amounts of time?
You can't just say that women's contributions fell and then not show the comparable male change.
For example:
This is a string of text.
This is a string of text.
This is a string of text.
This hello string of text.
This is a hellong of text.
This hello string of text.
This is a hello text.
This hello string of text.
I think you want "dispersed" here.