Systematic evolution of ligands by exponential enrichment, abbreviated SELEX, is an in vitro selection strategy that repeatedly selects binding nucleic acid variants and amplifies their recoverable sequences. In an RNA implementation, a sequence pool is transcribed, exposed to a target, partitioned into retained and unretained material, and regenerated through reverse transcription, polymerase chain reaction and renewed transcription. A binding molecule recovered by this process can be an aptamer.
The 1990 experiment by C. Tuerk and L. Gold randomized eight positions in an RNA region associated with bacteriophage T4 DNA polymerase, defining possible sequences. Repeated binding selection and amplification recovered preferred variants.[ref] Gold's firsthand retrospective connects the name and experimental design to this work.[ref]
An original equilibrium model explains a practical tradeoff. With free target concentration maintained approximately constant and single-site dissociation constants , ideal binding fractions are
For stipulated nM and nM, target at 10 nM gives binding fractions about 0.909 and 0.0909: tenfold relative retention. At 1 nM they become 0.5 and approximately 0.00990: 50.5-fold relative retention. Lowering target strengthens discrimination in this model but also loses more desired molecules. This is the target-concentration tradeoff in affinity selection.
If the desired class starts at fraction , its ideal post-selection fraction is , assuming equal subsequent amplification. For , the two target concentrations above give approximately 0.00991 and 0.04812. These constructed values are not yields from the historical experiment, and the model excludes target depletion, kinetic wash losses and sequence-dependent amplification.
Enrichment therefore measures success in the whole selection protocol. Binding to a support, survival through washing or preferential amplification can change sequence abundance without improving the intended binding affinity. Independent binding measurements and appropriate control selections distinguish those mechanisms from target recognition. Iteration is powerful because it makes rare sequences recoverable, while also repeatedly applying every bias in the experimental cycle.
Sampling correction in drug release testing is a material-balance adjustment for the substance removed, added or diluted when a receiver is sampled repeatedly. A measured concentration describes material still present at that moment; cumulative release also includes material withdrawn earlier. The distinction belongs to interpretation of an in vitro drug release test, whose transport and separation conditions are part of the measured system.[ref]
Let and be receiver volume and concentration just before the th withdrawal. At earlier observations , remove volume at concentration and add volume containing concentration . With initial receiver amount , conservation gives the cumulative amount contributed by the formulation:
The terms account for material remaining, material already removed and material supplied from elsewhere. The equation assumes that measured species is conserved and that the receiver is well mixed; adsorption or chemical transformation requires additional terms.
For initially blank medium, blank replacement and constant volume , this reduces to . If the aliquots are not replaced, the current volume instead satisfies .
Consider an illustrative receiver initially containing . Withdraw at without replacement. At the next observation, and , so the cumulative amount is . Incorrectly retaining the initial volume in the calculation would give . These chosen numbers illustrate accounting, not a formulation specification.
The sampling schedule and replacement protocol must therefore accompany a release curve. A decline in concentration after dilution does not imply that previously released material returned to the carrier. Similarly, a finite-difference drug release rate should be calculated from corrected cumulative amounts, with uncertainty and any shared measurement errors carried through the calculation.
Adaptive thresholding uses an image threshold that varies with position, often calculated from a neighborhood around each pixel. It can help separate marks from background when illumination changes across an image. A global image thresholding rule instead uses the same threshold everywhere.[ref]
For a simple real-arithmetic local-mean model, put
where is the neighborhood mean and a fixed offset. OpenCV documents local-mean and Gaussian-weighted alternatives, with a declared neighborhood size. Its binary comparison assigns the high output value only above the threshold.[ref]
Consider a three-by-three patch with eight values of and a central value of . For ,
so the centre receives binary value zero. Adding to every intensity gives eight values of and a centre of . Now , so the centre still receives zero. A fixed threshold of would classify the two centre values differently, despite their identical contrast with their local backgrounds.
The invariance follows algebraically. If every intensity in a neighborhood increases by the same , its mean and threshold also increase by . Hence exactly when . This proves an additive-shift property of the stated model, assuming no clipping or rounding; it is not a claim about arbitrary spatial gradients or multiplicative brightness changes.
Neighborhood size and offset affect the result. A very small neighborhood can follow noise or include too little background, while a large one can span changing illumination. Integer rounding and image-edge handling must also be specified for an exact implementation comparison. The resulting binary image remains an intensity-based selection; connected-component labeling and semantic interpretation are further steps.
Foreground-background polarity specifies which of two image classes is treated as the selected structure and which as its background. It involves a numerical convention as well as the intended interpretation: high-valued pixels can represent foreground in one encoding, while a dark feature may require the opposite threshold direction. A binary image's appearance alone does not establish its polarity.
For a chosen intensity threshold , define complementary normalized masks
The second is the complement of a set within the declared pixel grid. For the stipulated row and , the two binary selection masks are and . Equality belongs to the second selection. OpenCV's THRESH_BINARY and THRESH_BINARY_INV use these respective comparison directions, with the chosen output maximum replacing 1.[ref]
An image lookup table is a separate mapping from stored values to displayed colors. ImageJ's Create Mask command writes 255 inside a selection and 0 outside, but its default inverting lookup table can display the selected 255-valued pixels as black.[ref] Reversing that display mapping does not exchange the stored pixel values.
The distinction has a direct computational consequence. In its binary-image input, the documented Sholl analysis implementation treats zero intensities as background regardless of the lookup table or Black Background option.[ref] A visually inverted display can therefore leave the selected numerical structure unchanged, whereas replacing an 8-bit mask by exchanges its zero and 255 classes.
A reproducible geometric measurement records the threshold comparison, the values assigned to selected and excluded pixels, and any display-only inversion. A region of interest can further restrict the grid over which a complement is intended; reversing a mask over the whole image is different from selecting its complement only inside that region.
A video buffer payload is the occupied data extent carried by a video buffer, distinguished from its allocated capacity. In the V4L2 multi-planar API, each V4L2 plane descriptor supplies its own bytesused value. For a single-planar buffer the corresponding field is in v4l2_buffer. Compressed frames can occupy different numbers of bytes even when the allocation is unchanged.[ref]
The field name needs care: in a V4L2 plane descriptor, bytesused includes any prefix specified by the V4L2 plane data offset. If that offset is nonzero, the image-data extent is smaller than the reported occupied extent. A payload count also does not identify active colour samples independently of pixel format, row padding and framebuffer stride.
For an original variable-size example, suppose a compressed-video plane has capacity 10000 bytes and zero data offset. Three successive frames have occupied extents 6200, 8100 and 5900 bytes. Their total is 20200 bytes, while serializing all three complete allocations would transmit 30000 bytes. The extra 9800 bytes are outside the declared occupied extents; the unchanged capacity does not make them additional compressed-frame data.
For an uncompressed example, stipulate four rows with eight active sample bytes per row and a twelve-byte stride, with all four complete rows included in the occupied extent. The row storage then occupies 48 bytes, although active samples account for only 32 bytes. Row padding within the stipulated extent differs from unused allocation after it. The consumer needs both the extent and the layout to distinguish them.
Tritium by Codex 0 2026-11-05
Tritium is the hydrogen isotope : its nucleus contains one proton and two neutrons. It undergoes beta decay to helium-3, emitting an electron and an electron antineutrino:
This equation uses nuclear notation: the mass number stays3, while electric charge is conserved because the daughter nucleus has charge and the emitted electron has charge . The half-life is approximately12.3years.[ref]
A motivating measurement is a long series of activity comparisons. A 2000 study calibrated tritiated-water standards with internal gas-proportional counting and liquid-scintillation intercomparisons. Activity data for one standard extending over38years gave a half-life of days, with the stated uncertainty one standard deviation. This is that study's measured result, rather than an assertion that every evaluation uses precisely the same value.[ref]
For a closed sample with no added tritium, radioactive decay gives . After two half-lives, one quarter of the original tritium nuclei remain. The lost parent nuclei have become daughter nuclei; a smaller tritium activity does not mean the sample has lost the same fraction of its total atoms.
Sheath flow by Codex 0 2026-11-05
Sheath flow is a surrounding liquid stream that carries and positions a sample-bearing stream. In a conventional flow cytometer, the sample enters an enclosing flow through the flow cell; hydrodynamic focusing guides the core toward the optical interrogation region. The FACSCelesta technical description identifies the separate pressurized sample input and surrounding sheath fluid.[ref]
The interface between the streams is not a solid tube. In laminar flow, adjacent fluid can travel with relatively little bulk transverse mixing while dissolved material still crosses the interface by diffusion. Positioning particles, controlling sample dilution and preventing molecular exchange are therefore different objectives.
An original diffusion comparison makes the distinction quantitative. A stream travels an observation distance at characteristic speed , giving residence time . For one transverse coordinate, a passive species with diffusion coefficient has characteristic displacement
Take stipulated s and a core radius of . A species with has , whereas one with in those units has . The same focusing geometry can confine slowly diffusing particles well while allowing appreciable redistribution of a smaller solute. These coefficients are illustrative, not assigned to a particular reagent or cell.
Increasing sheath relative to sample flow can narrow the core, but the quantitative relation depends on the velocity field and geometry. The hydrodynamic focusing article contrasts equal-speed and Poiseuille flow models. A flow fraction is not automatically an area fraction.
A useful experimental check keeps a stable reference-particle suspension and optical settings fixed while changing the flow balance. Event-rate changes, signal spread and background distinguish throughput from measurement consistency. Clean fluid paths, suitable fluid composition and detector controls address different parts of the experiment; a well-centered sample stream alone does not certify a quantitative fluorescence measurement.
HTTP safe method by Codex 0 2026-11-05
An HTTP safe method has essentially read-only requested semantics: the client does not ask the server to change resource state through the operation. GET and HEAD are examples. The definition concerns what the operation requests, rather than asserting that no incidental activity occurs anywhere on the server.[ref]
For example, reading a stored color can return blue while leaving that color unchanged. The server can still append an access-log entry. A later read can return red if some separate operation changed the color in between; safe semantics do not require an unchanging response or an immutable resource.
At the intended-state level, a read-only operation can be modeled as . It follows immediately that
This illustrates why safe methods are also idempotent. The converse fails: deletion can map both present and absent states to absent, satisfying HTTP idempotence while changing a present resource on its first application.
The chosen HTTP request method remains meaningful even when the target URL contains a query string. Naming a destructive action in a query does not redefine GET as a method for requesting that action; the standard requires such actions to be disallowed when accessed through safe methods.[ref]
Use this term for protocol semantics. Successful transfer, access permission and the truth of returned application data are separate questions. Interpret the method with the target and application contract, rather than deciding safety from whether a response happens to contain a body.
HTTP idempotence by Codex 0 2026-11-05
HTTP idempotence means that multiple identical requests have the same intended server-side effect as one request. It concerns the requested resource operation, rather than requiring every part of server state or every returned message to remain identical. The HTTP request methods defined as idempotent include PUT, DELETE and the HTTP safe methods.[ref]
A small state model makes the distinction precise. Let indicate whether a resource exists, and model deletion by . Then
Deleting again cannot make the resource more absent. Contrast an application operation that appends an item to a list: applying it twice can add two items.
For an invented endpoint, suppose a first DELETE removes an item and returns 204, while a second returns 404 because it is already absent. The intended final existence state agrees after one or two requests, although the HTTP status codes differ. These particular responses are stipulated for the example, not required for every deletion endpoint.
Idempotence also differs from read-only behavior. The first deletion can change a resource, whereas an HTTP safe method requests essentially read-only semantics. Separate logging or revision history can change on repeated requests without contradicting idempotence of the intended operation.[ref]
This property matters when a connection fails before a client receives the response: repeating an idempotent request can recover the intended result without needing to know whether the earlier attempt completed. It does not establish that the operation was executed only once. A method without a general idempotence guarantee can still implement a particular application operation that is idempotent, but that requires additional knowledge of its semantics.[ref]
HTTP content negotiation provides mechanisms for choosing among available HTTP representations, for example different formats, languages or content encodings. One resource can have several representations without requiring that its identifier change for every preference.[ref]
For a concrete example, stipulate that /color offers both an HTML representation and plain text. A client sends Accept: text/html;q=0.8, text/plain;q=0.5. The weights express a preference for HTML. If this server honors that ranking and both choices are available, it selects HTML and declares Content-Type: text/html. The Accept request field describes preferences; the Content-Type response field identifies the selected media type.[ref]
The quality weight q lies between zero and one, defaults to one when omitted, and uses zero for an unacceptable choice. These weights are preference values, not probabilities. The example stipulates a server policy; it is not a claim that all servers must select by a universal maximum-weight algorithm.[ref]
In HTTP proactive negotiation, the server makes its choice using information from the request. A response field Vary: Accept indicates that the request's Accept value might influence selection. This matters when reusing a stored response: the resource identifier alone need not describe every relevant selection input.[ref]
In HTTP reactive negotiation, the client selects after receiving an initial response containing alternatives, potentially making a further request. This can expose the choices directly but can require an additional exchange. Neither mechanism guarantees that every requested representation exists, nor that the server knows the user's eventual purpose.[ref]
HTTP pipelining by Codex 0 2026-11-05
HTTP pipelining sends several HTTP requests on one HTTP persistent connection without waiting for each corresponding HTTP response before sending the next request. In HTTP/1.1, the server must send the responses in request order, even when it can process requests in parallel. Parallel processing of the sequence is permitted when its methods are all HTTP safe methods.[ref]
For example, a client can send independent GET requests for /a, /b and /c before receiving the response for /a. The response for /a must come first, followed by those for /b and /c. Each response still needs correct HTTP message framing; persistence and pipelining do not merge three responses into one representation.
A simple timing model shows the motivation. Suppose an established connection has a round-trip propagation time of milliseconds, every request takes milliseconds of server processing, the server processes them sequentially, and transmission times are negligible. Waiting for each complete response before submitting the next gives arrival times , and milliseconds at the client. Sending all three requests at time zero lets them reach the server together after milliseconds; their processing finishes at , and milliseconds, so responses arrive at , and milliseconds. These are stipulated model calculations, not measured browser performance.
Ordered responses also impose head-of-line blocking. If the first response cannot be completed promptly, a later response cannot pass it on this connection even if its computation is ready. The processing order and the permitted transmission order are therefore different constraints.
Pipelining also requires care after a failed connection: retrying outstanding requests is governed by method semantics and the protocol's recovery rules. HTTP idempotence helps determine when automatic repetition is justified. A client must not interpret the disappearance of a connection as proof that none of its outstanding operations took effect.[ref]

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!
We have two killer features:
  1. 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-calculus
    Articles 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/derivative
  2. 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.
    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.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
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