They will just put a ruler on the ground. If earth was perfectly round, then the ruler would only touch the ground in exactly one point. But the entire ruler touches the ground. Hence, the earth cannot be perfectly round, so it must be flat. QED.
Undefined is not part of JSON specification. It’s also not a thing in Java.
I would think it was a weird photoshop job.
The lighting doesn’t feel very natural. It’s inconsistent.
Her hair and face suggest a direct sunlight from the left, but the environment suggests indirect sunlight. The background trees should have more direct sunlight to the left.
The tentfire should also spill out some light to the environment.
The tent also suggests the sunlight comes from the right.
Consistent lighting is something AI is currently struggling with. It gives off a Photoshop edit vibe.
There’s still something uncanny about it.
Still incredibly impressive. I wouldn’t believe this was prompt generated just a few years ago.
The numbers I can find of Master System is that it sold between 10 to 13 million units worldwide, so not that much better compared to the short lifespan of Dreamcast.
Mega Drive’s sales numbers isn’t too far off from SNES.
Sega’s only console success was Mega Drive/Genesis. Probably because “Sega does what Nintendon’t”. Sega managed to sell themselves as the alternative for the kids who were too cool for the SNES.
They couldn’t compete with Sony on that front. Sony was the new cool guy. Dreamcast failed because everybody was waiting for PS2.
So I’d say failed marketing killed Dreamcast.
It’s not that funny.
Docker is like a virtual machine, but you only run one specific program in it. About exactly what the meme describes.
GNU’s Not Unix Isn’t Much Pretty
That’s fair enough. The common misconception is that waterfall is great for space missions, when in reality NASA is doing agile.
I agree that not everybody is NASA, so what works for them doesn’t necessarily work for everyone.
NASA also successfully flew a helicopter on Mars first try.
It’s barely waterfall planning either. Often there’s no planning, at least no coordinated one.
Currently at my current workplace we lack coordinated planning between teams. It seems like everybody is working in their own directions and it can take months until we get feedback from other teams. Mostly a product management problem.
The author is also hyping up waterfall too much. Agile was created because waterfall has its shortcomings (e.g. the team realizes too late that what they’re building isn’t what the customer wants).
But I also think it also represents how poorly implemented these ideas are. People say they do agile/kanban/scrum, but in reality they do some freak version of these.
I think this is a bit disingenuous. There’s no customer interaction in these panels.
So waterfall would be:
Customer says they want to go to Mars.
You spend years building a rocket capable of going to Mars, draining all the company budget in the process.
Customer then clarifies they actually meant they wanted to go to Mars, Pennsylvania, USA - not the planet!
Omg
Force Awakens will be closer to Revenge of the Sith next year
It has been a pleasure having this internet argument with you. I learned a bit, and you learned a bit. It’s a win win :)
My implementation: https://pastebin.com/3PskMZqz
Results at bottom of file.
I’m taking into account that when I update a hash, all the hashes to the right of it should also be updated.
Number of hashes is about 2.71828 x n! as predicted. The time seems to be proportional to n! as well (n = 12 is about 12 times slower than n = 11, which in turn is about 11 times slower than n = 10).
Interestingly this program turned out to be a fun and inefficient way of calculating the digits of e.
So in your code you do the following for each permutation:
for (int i = 0; i<n;i++) {
You’re iterating through the entire list for each permutation, which yields an O(n x n!) time complexity. My idea was an attempt to avoid that extra factor n.
I’m not sure how std implements permutations, but the way I want them is:
1 2 3 4 5
1 2 3 5 4
1 2 4 3 5
1 2 4 5 3
1 2 5 3 4
1 2 5 4 3
1 3 2 4 5
etc.
Note that the last 2 numbers change every iteration, third last number change every 2 iterations, fourth last iteration change every 2 x 3 iterations. The first number in this example change every 2 x 3 x 4 iterations.
This gives us an idea how often we need to calculate how often each hash need to be updated. We don’t need to calculate the hash for 1 2 3 between the first and second iteration for example.
The first hash will be updated 5 times. Second hash 5 x 4 times. Third 5 x 4 x 3 times. Fourth 5 x 4 x 3 x 2 times. Fifth 5 x 4 x 3 x 2 x 1 times.
So the time complexity should be the number of times we need to calculate the hash function, which is O(n + n (n - 1) + n (n - 1) (n - 2) + … + n!) = O(n!) times.
EDIT: on a second afterthought, I’m not sure this is a legal simplification. It might be the case that it’s actually O(n x n!), as there are n growing number of terms. But in that case shouldn’t all permutation algorithms be O(n x n!)?
EDIT 2: found this link https://stackoverflow.com/a/39126141
The time complexity can be simplified as O(2.71828 x n!), which makes it O(n!), so it’s a legal simplification! (Although I thought wrong, but I arrived to the correct conclusion)
END EDIT.
We do the same for the second list (for each permission), which makes it O(n!^2).
Finally we do the hamming distance, but this is done between constant length hashes, so it’s going to be constant time O(1) in this context.
Maybe I can try my own implementation once I have access to a proper computer.
It has been known for centuries that you see a different night sky depending on how far north or south you are. A flat earth model has to explain why northern pole star is only visible in some parts of the world, while southern cross is only visible in other parts.