Highend displays with display port definitively exist. I'm not sure about beamers, though.
1,687 karma · joined February 7, 2015
Highend displays with display port definitively exist. I'm not sure about beamers, though.
Yes, "size_t" should be just about right for everybody except the guys who _need_ to program in C/C++ and Assembler due to the hard requirements of their systems. Not very many people but very important systems.
For 255 characters you lose 9.4 bits which is bigger than the cost of an 8 bit size field.
For 65535 characters you lose 378 bits which is much bigger than the cost of a 16 bit size field.
On the other hand you have only one string type for arbitrarily sized strings and most strings are short.
What would really be needed to be more space efficient for short and long strings is a size field with a variable length encoding. E.g. 1 byte for string lengths up to 64, 2 bytes for string lengths up to 8k, etc.
1) No protection exists there.
2) Abstraction costs too much.
3) Store it in Flash.
4) Be happy your characters may even use the 8th bit.
As far as I understood this, they are building a whole operating system to be run in a VM like QEMU which then acts like a Node.js-instance - except that it's programmed in C++ and linked as one whole exeutable which also is a complete OS.
I wonder how this compares to Docker or Sandstorm where the existing kernel API is used in a virtualized container instead of emulating a whole machine.
But this is not the case if they stack the flash chips with the controller chips. Then only a few external pins are needed for communication and power. But the flash chips actually need the silicon area for all those tiny flash cells.
"Stealing" happens when the ownership of the money gets transferred to a third party without consent of the lawful owner.
This is what happens when bitcoins get stolen. They get transferred to somebody else and the global blockchain takes note of this. Yes you still have "your bits" but they are now worthless because nobody will accept them anymore.
What you really want are confidence intervals which show what would be a significant change. You can calculate that from your A-data and from your B-data. If they overlap you probably aren't quite there yet.
Comparing A/A vs. B or A/A/...A/A vs. B/B/...B/B is a poor man's approach to visualize the distribution of the mean values.
Things get further complicated when doing a lot of tests. If you do hundreds of A/B-Tests and a handful show a weakly significant result that may actually be a statistical fluke. The likelyhood that a wrong seemingly significant result is present when doing hundreds of tests can actually be pretty high. You should rerun these tests with fresh data and check for consistency, which in itself is some kind of A/A/B/B-test.
The reasoning is that you don't know how much data will arrive in the next 100ms and if you sleep either a buffer could overrun or something else could block. Therefore you need to flush the buffer either when enough data has accumulated or if a timeout has occured.