Let be salt mass fractions, with reservoir water masses denoted by the corresponding symbols. Let be Atlantic inflow salinity and the Danube inflow salinity, approximately zero for fresh water. With the diagram endpoint convention from part i, instantaneous mixing gives
Every outgoing salt transport uses the salinity of its donor box. The water masses are constant because the water balances are at steady state, even while the salinities evolve. If reservoir water masses varied, the left side would instead be .
Summing yields , a direct whole-system salt check. Fresh water carries essentially no salt, but its dilution effect is still present through the water balance and the resulting transport terms.
There are four well-mixed reservoirs: Mediterranean surface/deep and Black Sea surface/deep . Use the actual drawing’s arrow endpoints: leaves , enters from , and starts in and enters . With as positive water-mass transport rates, the four steady conservation of mass equations are
Adding them cancels every internal transport and gives the whole-system requirement . There is no stated evaporation, precipitation or other external transport to add.
The schematic endpoints are unusual for the conventional two-layer exchange picture: its Gibraltar outflow is drawn in the surface box, and its Black Sea surface inflow descends into the Mediterranean deep box. Moving to , to , and the source of to would define a different, more conventional idealization. The displayed equations consistently follow the supplied drawing; the same endpoint convention is used in the following two parts.
Permitted; returns "C". Both receiver and argument have static type C, so the most-specific applicable overload is show(C). That method is defined in C and returns its own one-letter result without calling super. The six results, in source order, are therefore AB, AB, AB, BC, BC, C.
Permitted; returns "BC". The receiver's static type is C, but the argument's static type is only B. Thus show(C) is inapplicable; among show(A) and show(B), the latter is more specific. Its implementation is C.show(B), whose superclass call returns "B" before "C" is appended. The argument happens to reference a C object, but method overloading uses its static type.
Permitted; returns "BC". Through static type B, both show(A) and show(B) accept an argument of type C; method overloading selects the more specific show(B). The receiver's runtime type is C, so dynamic dispatch invokes C.show(B). Its super.show(o) calls B.show(B), returning "B", and the override appends "C". The show(C) overload is not visible through receiver type B.
Permitted; returns "AB". A receiver of static type B exposes show(A) and show(B), but the argument's static type A is not a subtype of B. Only show(A) is applicable. Its effective implementation on the C receiver is B.show(A), which concatenates the superclass result "A" and "B".
Permitted; returns "AB". Through a receiver of static type A, only show(A) is visible. The argument's static type C is a subtype of A, so it can be passed to that method. Dynamic dispatch selects B.show(A) on the receiver object, exactly as in part (i). The argument's more specific type cannot expose overloads absent from the receiver's static type.
Permitted; returns "AB". The receiver's static type is A, which offers show(A). The argument also has static type A, so that signature is selected. All three variables refer to the same object of runtime type C; the most-derived implementation of show(A) is inherited from B. Its super.show(o) calls A.show(A), producing "A", and it appends "B". C overrides show(B), not this selected signature.
The strongly connected components are
The directed cycle makes its three vertices mutually reachable. Vertex has no outgoing edge. Vertex reaches that cycle but has no return path from it, and vertex reaches the other components but has no incoming path from them. These facts exclude every further merger.
The only possibilities are . Vertex reaches all of . In depth-first search, all vertices reachable from an active vertex must have been discovered and finished before its own finishing event, except for active ancestors. None of these four can be an ancestor of , because none can reach . Thus all four are finished before finishes.
Vertex cannot already be finished at that point: its outgoing edge to would have caused to be visited before it could finish. It also cannot be a descendant of , since cannot reach . Therefore is either still undiscovered or an active ancestor. In the first case the only remaining events are discovery and finishing of , giving . In the second case the only remaining event is finishing of , giving .
Both occur. Starting the outer traversal with leaves undiscovered and gives time . Starting with and taking its edge to first makes an ancestor and gives time . The argument does not assume any particular order on the other edges.
Increment a single clock on each discovery and finish, starting with clock zero. Lexicographic depth-first search gives
The first search tree has discovery edges , , . The edge returns to an active ancestor. Once that tree finishes, vertex is a new root whose neighbour is already finished, and vertex is the final root. This accounts for all twelve events in the DFS discovery and finishing times.
Use source , as in the preceding part. The Dijkstra algorithm extracts vertices in the order . Distances after relaxing the outgoing edges of each extracted vertex are
The shortest path to is , with weight ; the direct route to and the route via are both heavier.
Start with . With in-place edge relaxation, the Bellman-Ford algorithm makes the following changes during its first lexicographic pass:
The next pass makes no change; any remaining fixed-count passes also make none. Thus the final vector is . These are sequential updates within a pass, rather than the simultaneous values of the Synchronous Bellman-Ford recurrence.
Part (a) gives . Therefore the ceiling function and floor function satisfy almost surely. Both are integrable, since and . Thus .
Now take expectations in :
Writing , which ranges over every , and rearranging yields
These are the zeta bounds from rounded Pareto variables: rounding below and above converts one elementary expected value into bounds on an infinite series.
The nonnegative integer-valued tail-sum formula for expectation gives
This is finite because . Here is the Riemann zeta function on its convergent real domain. The floor function is nonnegative on the support, so the tail-sum identity applies directly.
For , the event equals . Integrating the Pareto distribution's density gives
The mass formula follows by subtracting consecutive tail probabilities, or by integrating over . With the paper's convention , include the separate endpoint values and , since almost surely. Substituting into the power expression would be invalid.
The events , for , are pairwise disjoint. Their union is , and the integers form a countable set. By countable additivity,
Countability is the necessary justification: one cannot apply this argument to an arbitrary uncountable union of zero-probability singletons. This is a special case of countable sets have zero probability under a density.

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