nightcracker
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.
You can create an enumeration over all Turing machines, and run each of them on the problem, 'diagonally', so we perform one step of computation on machine 1, then 1, 2, 1, 2, 3, 1, 2, 3, 4, etc. This will eventually run each Turing machine for an arbitrary amount of steps. As soon as one of the Turing machines accepts, we also accept.
Suppose the nth Turing machine is our poly time machine we have proven to exist (although we don't know n). It takes n steps of our meta algorithm to run this machine 1 step, then n+1 metasteps for the next step and so forth. In total it takes n + n+1 + ... + n+k = O(k^2 + kn) metasteps to run the nth Turing machine k steps.
But here's the crux... n does not depend on the input size, only on our problem! Thus it is a constant. In other words, this meta algorithm is quadratically worse (due to k^2 steps) than the optimal algorithm, but it is poly time.
Note that the above algorithm doesn't work for co-NP, in which we require that the "no" instances get solved in poly time (in NP we only require the "yes" instances to get solved in poly time).
For example, in Rust 2018 and earlier calling arr.into_iter() on an array type would result in an iterator over references of elements of arr (which is the expected result of .iter(), but not .into_iter()). In Rust 2021 this is fixed and arr.into_iter() will take ownership of the array and return an iterator over the values themselves. But old crates that are specified to compile using Rust 2018 will still work, and you can still call them from Rust 2021 without problems.
If the C++ committee ever wants to fix its language it must introduce such backwards-incompatible changes. With the advent of modules this should be possible, you could compile each module using different editions yet still call each other.
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.