Topics (384k) Articles (398k) Users (410) Discussions (242) Comments (383) Files (13k) New article
Weather forecasting estimates future meteorological conditions from observations and physical models. Numerical models use an approximate initial condition and equations of fluid mechanics to simulate future conditions; forecasters also compare model outputs and apply experience and research.[ref]
https://www.weather.gov/rah/virtualtourforecast. National Weather Service, The forecast process
The forecast horizon describes how far ahead a prediction remains useful at a specified accuracy; sensitive dependence on initial conditions can limit detailed predictions under deterministic evolution.This model couples deterministic underdominant allele-frequency dynamics in equal-sized habitats by global migration. Starting with pure habitats of one allele and of the other preserves two within-class frequencies , reducing the system to , with . Migration is conservative in the mean, but selection need not conserve global allele frequency.
A G protein-coupled receptor is a cell-surface receptor that relays activation through a G protein on the intracellular side of the cell membrane. The activated G protein can regulate an enzyme or ion channel, so a GPCR supplies a concrete metabotropic receptor example: ligand recognition and the eventual response are connected through distinct components. Different G proteins couple to different targets. See Alberts et al., Molecular Biology of the Cell, 4th edition: signaling through G-protein-linked cell-surface receptors.
Combine a secret randomly selected almost strongly universal hash family member with a fresh secret output mask. An observed message authentication code tag leaves the hash-selection key hidden, and the conditional hash bound controls substitution forgery probability. The message itself need not be encrypted. Mask reuse can reveal hash differences; repeated-use guarantees require fresh masks and an appropriate analysis of verification information. A one-use polynomial construction needs only two secret field elements, even for a much longer message.
A meson with total angular momentum one and negative parity. In the ordinary quark model, a quark-antiquark pair with orbital angular momentum zero and total spin one has these quantum numbers; its neutral self-conjugate states have charge conjugation . The light-flavour tensor product gives an octet and a singlet, forming a vector nonet, just as spin-zero negative-parity pairs form a pseudoscalar meson nonet. Nonzero orbital excitations can also produce vector states.
The omega meson is an isospin-zero vector meson with charge conjugation value minus one and consequently G parity minus one. Three-pion decay is compatible with the isospin-symmetric strong interaction, whereas two-pion decay violates its G-parity rule.
For an ordinary quark-antiquark meson, opposite intrinsic parities and orbital parity give . For a self-conjugate flavor state, charge conjugation exchanges the two constituents. Reversal of their relative momentum gives , spin exchange gives , and reordering the two fermionic creation operators gives one extra minus sign. Their product is . Electrical neutrality alone does not imply that a state is an eigenstate of charge conjugation; charged mesons have no individual C eigenvalue.
An isospin-zero quark paired with or gives a meson isospin doublet of charges . Spin addition at zero orbital angular momentum gives both pseudoscalar mesons and vector mesons. Pairing the new antiquark with gives the charge-conjugate doublets. For strange or charm flavour these are the kaon or D-meson families and their vector partners.
There are two distinct questions: whether another operating-system process can observe shared contents, and whether those contents survive a crash. In the timeline, persistent storage deliberately remains while the shared page cache contains . No background page writeback occurs in this toy interval. Real page writeback may persist some contents earlier; shared visibility alone cannot tell the reader which contents are durable.
For the covered shared range,
msync(base, length, MS_SYNC) requests page writeback and waits for completion; check its return value. MS_ASYNC is not a durable completion acknowledgment, and on modern Linux kernel versions it is a no-op because dirty contents are already tracked. The address must be aligned, so synchronizing our changed second page uses base + 4096, length 4096, rather than base + 4133. Unmapping alone is not a guarantee of completed writeback.[ref]msync(2) — Linux manual page by Linux man-pages project. DESCRIPTION, RETURN VALUE, ERRORS and VERSIONS: covered range, MS_SYNC versus MS_ASYNC, page-aligned address, and Linux MS_ASYNC behavior since 2.6.19
For persistence of the file and associated file metadata, fsync on an open file descriptor is a broader interface; a new directory entry needs separate synchronization of its file-system directory. Retain a suitable file descriptor if the persistence protocol needs it after mapping. Successful storage completion still relies on the file system and device honoring their persistence contracts.[ref]
fsync(2) — Linux manual page by Linux man-pages project. DESCRIPTION, RETURN VALUE and ERRORS: file data and metadata, directory entry, completion and reported failures
Neither fsync nor msync supplies mutual exclusion, an atomic storage write for several memory pages, or an application-wide file-system transaction. Stop or coordinate writers before deciding which update a completion acknowledges. A crash during page writeback can leave a mixture of old and new contents unless a separate recovery protocol provides file-system crash consistency. The last timeline row assumes successful synchronous completion, honored storage flush semantics and no subsequent writer; it illustrates a persistence boundary, not a promise about arbitrary hardware failures.
With
MAP_PRIVATE, copy-on-write initially reuses backing page cache contents. In our model, a private store raises a protection page fault, copies the affected memory page to a private page frame, installs a writable page table entry and retries. The other memory page can remain shared. This page fault needs no storage read.In B's private file mapping, storing copies relative page 1, including its neighbor . Next, A stores through its shared file mapping. After coordination outside the mapped data, B's shared reads give , while its detached private page gives . The untouched first memory page remains backed by the file; this is not a frozen snapshot of the whole file. Neither page writeback of shared contents nor msync publishes B's private 99. To save those private contents, the application needs a separate explicit file update.
Toy shared file mapping and copy-on-write timeline: visible shared changes precede the chosen durable completion; private changes remain separate
. Details. Let be the memory page size, the aligned starting file offset, the mapping length and its base virtual address. A valid displacement with corresponds to file offsetHere is the relative memory page index, the floor function selects its integer part, and Euclidean division gives the within-page displacement . The backing page begins at . This identifies file contents; the page table separately selects a resident page frame and enforces permissions.
Take , and bytes in a file of at least 12288 bytes. A has a shared file mapping at . B has a shared file mapping at and a private file mapping at . These bases are illustrative chosen results, not requested fixed addresses. All three mappings cover the same two backing pages: file offsets 4096–8191 and 8192–12287. Displacement selects relative page 1, within-page displacement 37 and file offset . Thus A's
0x10001025, B's shared 0x20001025 and B's private 0x30001025 initially identify the same byte. The adjacent displacement 4134 identifies file offset 8230. Different virtual addresses can reach the same backing contents.Two operating-system processes map two backing pages at different virtual addresses; displacement 4133 identifies file offset 8229
. Details. To access a requested file offset that is not aligned, choose and displacement . Mapping enough bytes to cover that displacement plus the requested length makes the desired data start inside the aligned mapping. Do not pass the unaligned directly as the Linux kernel
mmap offset. For example, uses and displacement 37; that one-page start differs from our two-page mapping's .The POSIX mapping interface. Ordinary Linux kernel file mappings require a positive length and an aligned file offset. A null address lets the operating-system kernel choose an aligned base; length need not be aligned. Check for
MAP_FAILED. After success the file descriptor may be closed without invalidating the mapping; munmap or process termination removes it.[ref]mmap(2) — Linux manual page. DESCRIPTION: address, length, offset and descriptor lifetime; munmap; RETURN VALUE
Mapping does not extend the backing file. Under POSIX, for an initially partial last memory page, the tail beyond the file's end is zero-filled and is not written back as file data; accesses to whole mapped memory pages beyond the end raise
SIGBUS. POSIX leaves access to portions added or removed by later resizing unspecified. Establish the required file size first and coordinate resizing with readers; a mapping's length is not proof that those bytes exist in the file.[ref]mmap — POSIX.1-2024. POSIX.1-2024, DESCRIPTION: partial end page, whole pages beyond the object, and changed file size; RATIONALE: references beyond the end do not extend the object
The Linux kernel documents a tail-cache exception: modified beyond-end bytes can survive in the page cache and appear in later mappings, although never written to the file. Do not use that tail as reliable storage.[ref]
mmap(2) — Linux manual page. BUGS: modified contents beyond the object end can remain in the page cache
The file supplying a memory-mapped file's initial contents. Its logical file offsets identify data independently of the virtual addresses chosen by different operating-system processes. Modified private file mapping contents have private storage; they are not updates waiting to be written to the backing file.
The arithmetic mean of memory access latencies. Suppose each read completes before the next begins, every cache hit costs , and every cache miss costs , with the same additional cache miss penalty . If is cache hit rate and is cache miss rate, the weighted arithmetic mean isThe common lookup cost is paid on both outcomes. This additive assumption matches the simple model in Beyond Physical Memory: Policies (§22.1, equation 22.1, pp. 1–2), where main computer memory acts as a memory cache for memory pages backed by disk; here the same accounting is applied to a toy data memory cache.
Assign synthetic values and . The twelve-read, two-slot fully associative cache example has five cache hits and seven cache misses, givingWith four cache slots, its four compulsory misses instead give . This comparison holds the timing costs fixed as capacity changes, which is a model assumption rather than a hardware promise.
If a problem supplies a total miss time , use ; adding to again would count lookup twice. Variable cache miss penalties, multiple consulted levels, or overlapping requests require a richer timing model. Real CPU work can overlap a pending read, so this arithmetic mean cannot by itself predict program speed or stall time. [ref]
A memoization cache lifetime is the interval over which retained entries are available and valid. One table per top-level request shares recursive subproblems within that request; keeping a table between requests also allows the warm and incremental examples. Clearing it loses those savings. Evicting a correct answer can preserve correctness for a terminating pure function, while forcing recomputation; changing an input without invalidating an obsolete answer can break correctness.
Specify who owns the table, when context changes invalidate it, and how long keys and results occupy computer memory. In a concrete implementation, retained references can keep arguments and answers alive until removal or clearing.[ref]
functools — Higher-order functions and operations on callable objects (Python 3.14 documentation). Python documentation, functools.lru_cache: cache_clear and retention of argument and return-value references until eviction or clearing
The memoization promise is conditional reuse of valid completed answers, not an automatic guarantee of freshness, termination or bounded computer memory.// Target: computer-science.bigb
A memoization key identifies all information that determines a reusable answer. Write for explicit arguments and for relevant context. For a function and key function , the necessary value condition isThis implication need hold only for contexts in which the entry can be reused. The condition concerns key equality, not merely equality of hash function outputs: a hash table must resolve hash collisions by comparing complete keys. Include the identity or version of the procedure if one table stores results for several procedures or changing implementations.
For an original toy example, let . Caching only by after incorrectly returns for , whose answer is . The pair is complete for this function. If is hidden in mutable configuration, either freeze that configuration for the memoization cache lifetime, include a reliable version in the key, or invalidate affected entries before reuse. A version is sufficient only if every relevant change updates it. Object identity alone is likewise insufficient for a mutable list whose contents determine the answer.
Endocytosis takes material into a biological cell by inward budding and separation of part of its cell membrane. At a chemical synapse, it helps recover membrane and proteins after synaptic vesicle exocytosis. This recovery is distinct from uptake of individual neurotransmitter molecules through membrane transport proteins.
Pinned article: Introduction to the OurBigBook Project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
Intro to OurBigBook
. Source. We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivativeVideo 2. OurBigBook Web topics demo. Source. - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 2. You can publish local OurBigBook lightweight markup files to either OurBigBook.com or as a static website.Figure 3. Visual Studio Code extension installation.Figure 5. . You can also edit articles on the Web editor without installing anything locally. Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension. - Infinitely deep tables of contents:
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact







