2 ms·

Okay, ZFS also does that - ZFS Deduplication keeps an index of each block by it's checksum, and when it detects a collision, it re-uses the existing block, redu

Okay, ZFS also does that - ZFS Deduplication keeps an index of each block by it's checksum, and when it detects a collision, it re-uses the existing block, reducing the number of copies - https://docs.oracle.com/cd/E36784_01/html/E39134/fsdedup-1.html https://docs.oracle.com/cd/E36784_01/html/E39134/fsdedup-1.h... I'm not arguing at all that the analogy is a poor fit. Just that there are several instances of that kind of technique in CS. See also: Compression algorithms that include backpointers, so that medium-sized repeated runs (like common parts of filenames or fileheaders) can be represented by saying "The next 8 bytes are the same as the 8 bytes 32 bytes ago".

otherme123 4y ago
The whole point of an analogy is to make it easy to understand some complex idea using another simple concept. I would use instead this analogy: "alternative splicing is like having a box of Legos (exons) which you can choose in different order and quantities to get different objects (proteins)." I find it more clear than "alternative splicing is like ZFS deduplication and collision detection algorithm, where blocks can be reused if they are identical". Introns are not for space saving or for efficiency. They provide variability. Is like ZFS could give you slightly different files from what you initially save. E.g. you store feral_cat.jpg spanning a number of blocks, and then just skipping blocks you can get back: feral_cat.jpg, persian_cat.jpg, egyptian_cat.jpg, russian_cat.jpg, alien_cat.jpg, tabby_cat.jpg... You never store "persian_cat.jpg" and try to save some genome space reusing blocks. persian_cat.jpg is just a possible useful image that appears magically from the original feral_cat.jpg.