Yes, I am aware it has been 'superseded' but in my experience for lossless compression it's still usually better.
4,235 karma · joined March 27, 2013
QOI_DIFF24 {
u8 tag : 4; // b1110
u8 dr : 5; // 5-bit red channel difference: -15..16
u8 dg : 5; // 5-bit green channel difference: -15..16
u8 db : 5; // 5-bit blue channel difference: -15..16
u8 da : 5; // 5-bit alpha channel difference: -15..16
}
E.g. some file formats may be row-major, others column-major, some block-based (like JPEG) or a fancy interleaving scheme (like Adam7). Some might store the channels interleaved, others separate the channels. If any of these choices doesn't match the desired output format, it breaks streaming.
1. The name isn't particularly catchy or descriptive. It is the correct name for the data structure, but not too many people know the data structure.
2. People don't even know what they're missing. It's not a very Google-able problem to begin with. Slotmap provides an interesting solution to (circular) ownership and safe allocator / weak pointer design problems, but people don't recognize that they're having them or that slotmap could help.
As an example of this, the doubly linked list example (https://github.com/orlp/slotmap/blob/master/examples/doubly_...) can safely remove nodes from the linked list given their handle, in O(1), even from the middle, completely safely and correctly, even in the presence of double deletions or ABA memory re-use. You can't replicate this with just pointers, without introducing heavy refcounting solutions.
DenseSlotMap sort of can. It still can't reclaim the memory used by empty slots for the same reason (at a cost of 8 bytes per slot), but can reclaim the memory used by the actual elements stored.
So if you store 1 million items at one point in a DenseSlotMap, and then clear them all and then shrink to fit (which is actually missing from the API, but I'll fix that soon) you will waste 7.6 megabytes on the empty slots but nothing on the actual data that used to be stored.
For iteration however, there can be holes that need to be ignored, if the current number of elements in the slotmap is significantly lower than the the maximum capacity. If iteration needs to be very fast (for e.g. game engines) I do have a solution for that, which is the DenseSlotMap. It uses one extra layer of indirection for random access, but stores the actual data values contiguously in a vector, thus iteration is always fast.
Actually, since CPUs are so fast and disk IO is so slow, it is essentially impossible to beat a properly tuned program that reads data from disk and decompresses it on the fly using one that doesn't use compression at all.
The paper (https://journals.plos.org/plosone/article?id=10.1371/journal...) [does not mention the sensitivity or specificity of the model at all, only mentions a '91% accuracy' number]* on a biased dataset (where the number of suicidal cases is oversampled and non-suicidal cases are undersampled), without even mentioning exactly how much they over/undersampled.
* I missed the ROC curve on page 7. However it's not clear if this ROC curve was computed on the under/oversampled dataset or the original.
If you zoom in further, you'd soon realize your screen is nothing but pure red, green and blue subpixels at varying intensities.
Not proving, conjecturing. It's not proven until this day: https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
The hypothesis 'the dog can differentiate between A and B' is very hard to falsify. Because the dog could differentiate, but choose to not act. You would need a fairly complete understanding of the dogs mental workings, and scanners to study them.
On the other hand, 'the dog can't differentiate between A and B' is much easier to falsify. If you repeat an experiment a sufficient amount of times and the dog consistently has different behavior between A and B, you can rule this null hypothesis out.
That is the real reason we always 'assume the worst'. Because 'assume the worst' is the easiest to scientifically rule out.
EDIT: I would suggest this video by Veritasium, which also touches on this, at a very fundamental level: https://www.youtube.com/watch?v=vKA4w2O61Xo.
Repeated exposure also reduces skepticism. The writing world has already long known this, you can not proofread your own work. You will read 50 times over a silly mistake without ever noticing it. Software engineering is understanding this more and more through code review as well, but academia is slow on the uptake. Groups or individuals will spend months on their work without anyone else to check on it.
The young are not yet cursed with knowledge. They can look at things with a fresh look. They can poke holes in stuff others are 'reading over', and find completely new approaches.
E.g. you have to navigate through this garbage: https://i.imgur.com/W1txUAK.png to find the one link (named "Sound Control Panel", hidden somewhere down the page) that opens the actual useful config panel: https://i.imgur.com/zDnnMPE.png
> In the future Nuitka will be able to use type inferencing based on whole program analysis. It will apply that information in order to perform as many calculations as possible in C, using C native types, without accessing libpython.
I believe the difference with PyPy is that PyPy tries to do this using just-in-time compilation and nuitka uses ahead-of-time compilation.
Interfaces and functionality keep being dumbed and locked down like they are on tablets and phones. Microsoft and Apple are watering at the mouth for the day when the true personal computer is gone and every computing device is a walled garden where every user uses their pre-approved apps doing only the pre-approved tasks, preferably as thin clients into their controlled cloud.