Are you going to cite facts to back up your claims of a $100,000 university? You roughly doubled the tuition, room and board, and required fees of NYU, commonly cited as the most expensive private U.S. university.
Begrudgingly, I agree. I don't consider a patent holder to be a troll unless they're clearly not the first party to develop said technology. If there's clear prior art, only then would I consider someone a troll.
Unfortunately, patents are becoming more commoditized than healthcare in our country. It seems silly to me that someone is permitted to sue on the basis of patent violation when a) they weren't the original inventor, b) they bought the patent for the entire reason of profiting from litigation, or c) they're suing people who 'violated' their patent prior to the time they purchased it.
As long as the files aren't being removed and marked inaccessible by the owner, I see no malicious intent by Dropbox here. I'm sure they were pressured by the MPAA and other similar organizations to actively remove/refuse to host these files, and Dropbox implemented this instead.
The game is arbitrarily winnable now. Press down until you get rows of 2-4-8-16, then collapse all the way to the left. Repeat this procedure until you get to 256/512.
That doesn't work, you get to 128 with some nice patterns and then the algorithm fills the screen. Maybe some clever play from then on would work, but the random pieces always mess with your strategy.
Buggy; Got some sort of JS alert error that stopped my game short: "GG 308", "GG -1". I'm guessing you're reporting my score here, but there are still MANY valid moves left on the board. For example, start the game, and hold the down arrow until the alert pops up saying "GG [score]" -- There's almost guaranteed to be 4-5 possible moves left on the board this way.
How does he explain storing simple integers in a reasonable amount of space? Any decent programmer will avoid using too many bits for a variable that never exceeds a certain value (short, int, etc). It seems rather foolish and arrogant to claim this one half-implemented number type can satisfy everyone's needs in every programming language.
Next week he'll have a number format with 48 mantissa bits, 8 exponent bits and 8 unsigned base bits to define a base value between 0 and 255. Look at all the performance and simplicity involved!
"Any decent programmer will avoid using too many bits for a variable that never exceeds a certain value (short, int, etc)."
Why? Why aren't you use half-bytes also?
If all your pointers are 64-bit aligned, all your variables are 64-bit aligned and your processor isn't any faster processing 16-bit numbers - if it even have instructions to process those - than 64-bit numbers?
All your variables are not 64-bit aligned. An array of 16-bit integers will generally use 16 bits (2 bytes) per integer. So will two or more subsequent integers in a struct. In general, variables smaller than the alignment of the CPU (but still power of two sizes) only need to be aligned to their own size.
I actually use half-bytes when it makes sense; my language of choice has bit-vectors so I can use exactly the number of bits I desire.
> If all your pointers are 64-bit aligned, all your variables are 64-bit aligned and your processor isn't any faster processing 16-bit numbers - if it even have instructions to process those - than 64-bit numbers?
Maybe I have an array with at least 4 16-bit numbers? If I'm counting bits, then it already means I have a lot of numbers. If I have 2 billion numbers in the range [0,15] Then I can easily represent them in an array of 4 or 8 bit values, but will run into performance issues trying to do so (if I can at all) using a similar array of 64 bit values.
> If all your pointers are 64-bit aligned, all your variables are 64-bit aligned and your processor isn't any faster processing 16-bit numbers - if it even have instructions to process those - than 64-bit numbers
Memory bandwidth. If the processor can read a single 64-bit integer in a clock cycle, it can read 4 16-bit ones just as well. Memory is slower than the core.
As an example with AVX instructions you can process 8 floats at the same time, compared to 4 doubles. So if float is enough for you you can expect double performance in either memory transfer bound or ideally vectorizable algorithms.
And in mobile computer graphics 16bit values are common.
