dataesr/scientific-paragraphs-categorization huggingface dataset:
Mismatches between Coq and OCaml Though safe, the extractor can be used inappropriately. We have just seen that adding an axiom standing for an OCaml function can, if that axiom is not realizable in Coq, lead to logical inconsistency. Even if the axiom is logically consistent, extraction to arbitrary OCaml code can lead to undesirable runtime behavior. An obvious case is when, in addition to an axiom specifying a constant referring, at extraction time, to an OCaml function, one adds an axiom specifying the behavior of that function, and that behavior does not match the specification. For instance, one can specify f to be a function returning a natural number greater than or equal to 3, then, through extraction, define it to return 0: Unsurprisingly, it is possible to prove in Coq that g always returns true, and yet to run the OCaml code and see that it returns false.
It is similarly possible to write Coq code with impossible cases that the extractor will extract to assert false, and the extracted code will actually reach this statement and die with an uncaught exception-an after all better outcome than producing output that contradicts theorems that have been proved. In the following code, False_rec _ _ eliminates on False, which is obtained from contradiction with x ≥ 3, and is extracted to an always failing assertion. Program Definition h x := match f x with | O ⇒ False_rec _ _ | S O ⇒ False_rec _ _ | S ( S O ) ⇒ False_rec _ _ | S ( S ( S x )) ⇒ x end. Axiomatizing the behavior of externally defined functions circumvents the idea of verified software; nowhere in the CompCert source code is there such axiomatization. An equivalent but perhaps more discreet way of axiomatizing the behavior of OCaml function is through dependent types.
Consider, again, Axiom size : { n : nat | n < 10 }. It is possible, through extraction mechanisms, to bind size to the OCaml constant 11; this is because the type of size is extracted to the same exact OCaml type as nat, the proof component is discarded. It is then possible to similarly lead the OCaml code extracted from Coq to cases that should be impossible. The only case of such axiomatization, in CompCert-KVX, is the previously introduced profiling_id_eq axiom, which is bound to the Digest. equal function from OCaml's standard library, and defined to be string equality. We can surely assume that OCaml's string equality test to be correct, otherwise many things in Coq and other tools used to build CompCert are likely incorrect as well. It is also possible to instruct the extractor to extract certain Coq types to specific OCaml types, instead of emitting a normal declaration for them.
Interfacing External Code as Pure Functions Coq is based on a pure functional programming language; as in mathematics, if the same function gets called twice with the same arguments, it returns the same value. OCaml is an impure language, and the same function called with the same arguments may return different values over time, whether it depends on mutable state internal to the program or on external calls (user input, etc. ). By binding Coq axioms to impure functions, we can, again, lead OCaml code extracted from Coq to places it should not go. For instance, the z Boolean expression extracted from this Coq program is false though it is proved to be true: it calls the same function twice with the same argument and compares the result  15  ; but since that function is impure and returns the value of a counter incremented at each call, two successive calls always return unequal values.
Beyond soundness, a major feature of this approach is to provide "theorems for free" about polymorphic higher-order foreign OCaml code. In other words, this approach ensures for free (i. e. , by the OCaml typechecker) that some invariants proved on the Coq side are preserved by untrusted OCaml code  [7]. While this technique has been intensively applied within the Verified Polyhedron Library  [8] , it is only marginally used within the current CompCert-KVX, only for a linear-time inclusion test between lists. This approach however has two drawbacks. Firstly, despite the introduction of tactics based on weakest liberal precondition calculus, the proof effort is heavier than for code written with pure functions without a monadic style. Secondly, all the code calling impure functions modeled within the may-return monad also becomes impure code modeled within that monad, meaning that a significant part of the rest of CompCert (at least the code calling the sequence of optimization phases and their proofs) would have to be rewritten using that monad.
16 ompCert's Coq code accesses mutable variables storing command-line options through helper functions. This supposes that these variables stay constant once the command line has been parsed, which is the case. In Coq, all functions must be shown to be terminating (because nonterminating terms can be used to establish inconsistencies). Arguments for the termination of a function are sometimes more intricate and painful to write in Coq than those for its partial correctness, and termination is not really useful in practice: from the point of view of the end-user there is no difference between a terminating function that takes prohibitively long time to terminate, and a nonterminating function. For this reason, some procedures in CompCert and forks that search for a solution to a problem (e.
g. , a fixpoint of an operator) are defined by induction on a positive number, and return a default or error value if the base case of the induction is reached before the solution is found. Iteration. PrimIter, used for instance in the implementation of Kildall's fixpoint solving algorithm for dataflow analysis, thus uses a large positive constant num_iterations=10 12. Such numbers are often informally known as fuel. CompCert-SSA takes an even more radical view: a natural number fuel is left undefined, as an axiom, inside the Coq source code, and is extracted to OCaml code let rec fuel = S fuel, meaning that fuel is circularly defined as its own successor, and in practice acts as an infinite stream of successors. Why that choice? num_iterations is a huge constant belonging to the positive type, which models positive integers in binary notation; there is a custom induction scheme for this type that implements the usual well-founded ordering on positive integers.
However, only the former is needed for a symbolic execution engine that checks that two executions are indeed equivalent by structural equality of terms, as in the scheduler in CompCert-KVX  [47]. Having to thread a whole computation through a monad, further adding to proof complexity, for actions that are expected to behave functionally overall, is onerous. One solution is to add hash-consing natively inside the runtime system; for instance, the GimML language, 20 from the ML family  [19, 17, 18] , automatically performs hash-consing on datatypes on which it is safe to do so, which is for instance used to implement efficient finite sets and maps. This can be emulated by a "smart constructor" approach  [10] , replacing, through the extraction mechanism, calls to the term constructor, term pattern matching, and term equality by calls to appropriate OCaml procedures: the constructor performs hash-consing, the pattern matcher performs pattern matching ignoring the internal-use "unique identifier" field used for hash-consing, and term equality is defined to be pointer equality; appropriate OCaml encapsulation prevents manipulation of these terms except through these three functions, and in particular prevent them from being constructed by other methods than the smart constructor.
Assuming that this OCaml code is correct, this is indeed sound, due to the global invariant that there never exist two distinct yet structurally identical terms of the hash-consed type currently reachable inside memory. Because terms can only be built using the smart constructor, and that hash-consing ensures that pointer equality is equivalent to structural equality, pointer equality can indeed be treated as a deterministic function, without need for a monad. This approach has the benefit of an easy-to-understand interface and simple proofs; this was the second approach experimented within CompCert-KVX and was used for the HashedSet module  [39]. This second approach adds significantly more OCaml code to the trusted computing base than just assuming that pointer equality implies structural equality.
Most of them are unverified, but trusted. There are two important exceptions: significant parts of the parser and the typechecker of CompCert C are formally verified. The formally verified parser is implemented using the Menhir parser generator, and there is a formal verification of its correctness with respect to an attribute LR(1) grammar  [23]. It relies on an unverified "pre-parser" to distinguish identifier types introduced by typedef from other identifiers (a well-known issue of context-free parsing of C programs). It produces an AST which is then simplified and annotated with types, by another unverified pass, called "elaboration". Finally, the resulting CompCert C program is typechecked, by the formally verified typechecker. This is where the fully verified frontend of CompCert really starts.
the ISO C11 standard in Coq. This development is unrelated to the formalization inside CompCert. 22 See an example on http://www. open-std. org/jtc1/sc22/wg14/www/docs/dr_260. htm. 23 This should not be confused with syntactic associativity, which is fully defined by the standard. Some deviate from the standard's mandated behavior in some respects. 24  Many programs, be them applications, libraries or system libraries, rely on the behavior of the default compiler on their platform (e. g. , gcc on Linux, clang on MacOS, Microsoft Visual Studio for Windows). 25 If compilation just fails, then issues are relatively easy (though maintaining support for multiple compilers, often through conditional compilation and preprocessor definitions, is error-prone); subtler problems may be encountered when software compiles but has different behavior with different compilers.
26 It may be difficult to narrow differences in outcomes to a bug (including reliance on undefined behavior) or to a difference in valid implementations of unspecified behavior. The only semantic issue that we know of regarding CompCert's forthcoming version 3. 10 is with respect to bitfields. A write to a bitfield is implemented using bitshift and bitwise Boolean operations, and these operations produced the "undefined" value if one of their operands is "undefined". Writing to a bitfield originally stored in an uninitialized machine word or long word, which is the case for local variables, thus results in an "undefined" value, whereas the bits written to are actually defined. Reading from that bitfield will then produce the "undefined" value, as can be witnessed by running the program in CompCert's reference interpreter, which stops complaining of undefined behavior.
Fixing this issue would entail using a bit-wise memory model (issue 418). 27 It may be possible to write and prove correct a phase that would replace this "undefined" value by an arbitrary value and thus result in miscompilation. We do not know, however, of any phase that would produce this in CompCert or variants. CompCert-KVX's test suite includes calling compiler fuzzers CSmith 28  and YarpGen: 29  random programs are generated, compiled with gcc and CompCert-KVX and run on a simulated target-an error is flagged if final checksums diverge. Due to possible semantic differences for the subset of the C language between the tools that they use for their formal proofs and CompCert, Gernot Heiser, lead designer of the seL4 verified kernel, argues that translation validation of the results of black-box compilation by gcc is a safer route: [.
generators, is to replace CompCert's frontend by a verified a code generator for that language, directly targeting one of CompCert's intermediate representations (e. g. , Clight) and semantics, as done for instance for Velus  [9]  for a subset of the Lustre synchronous programming language. Some features of the C programming language are not supported by Com-pCert's formally verified core, but can be supported through optional unverified preprocessing, chosen by common line options: -fstruct-passing allows passing structures (and unions) as value as parameters to functions, as well as returning them from a function; 30 -fbitfields allows bit fields in structures. 31  Preprocessing implements these operations using lower-level constructs (memory copy builtin, bit shift operators), sometimes in ways incompatible with other compilers-CompCert's manual details such incompatibilities.
Assembly back-end issues The verified parts of CompCert do not output machine code, let alone textual assembly code. Instead, they construct a data structure describing a set of global definitions: variables and functions; a function contains a sequence of instructions and labels. The instructions at that level may be actual processor instructions, or pseudo-instructions, which are expanded by unverified OCaml into a sequence of actual processor instructions. The resulting program is printed to textual assembly code by the TargetPrinter module; most of it consists in printing the appropriate assembly mnemonic for each instruction, together with calling functions for printing addressing modes and register names correctly, but there is some arcane code dealing with proper loading of pointers to global symbols, printing of constant pools, etc.
Pseudo-Instructions In addition to instructions corresponding to actual assembly instructions, the assembler abstract syntax in CompCert features pseudo-instructions, or macroinstructions, most notably: allocation and deallocation of a stack frame; copying a memory block of a statically known size; jumping through a table. The reasons why these are expanded in unverified OCaml code are twofold. First, the correspondence between the semantics of such operations and their decomposition cannot be easily expressed within CompCert's framework for assembly-level small-step semantics, especially the memory model. CompCert models memory as a set of distinct blocks, and pointers as pairs (block identifier, offset within the block); 34 stack allocation and deallocation create or remove memory blocks by moving the stack pointer, which is just a positive integer.
A refined view, with a correctness proof going to the flat addressing level, was proposed for the x86 target  [55]  but not merged into mainline CompCert. Loading Constants Certain instructions may need some expansion and case analysis, and possibly auxiliary tables. For instance, on the ARM architecture, long constants must be loaded from constant pools addressed relatively to the program counter; thus emitting a constant load instruction entails emitting a load and populating the constant pool, which must be flushed regularly since the range of adressing offsets is small. Getting the address of a global or local symbol (global or static) variable may also entail multiple instructions, and perhaps a case analysis depending on whether the code is to be positionindependent, and, in CompCert-KVX, whether the symbol resides in a threadlocal program section.
The scratch registers may be different in each case, and this case analysis must be replicated in the specification; alternatively, the specification may contain a upper-bound on the set of clobbered registers, but in any case no clobbered register should be forgotten. There may also be a complicated distinction of cases regarding which source register is alias to which other source register, or which scratch one. A bug in that builtin, which did not check alignment and generated improper offsets for load instructions, was found in CompCert on AArch64; the assembler would reject the generated code (commit c8ccecc). Another bug in the same builtin, on four architectures (ARM, AArch64, PowerPC, RISC-V), due to an incorrect test about register aliasing, resulted in successful compilation, assembly and linking with incorrect code being emitted (commit c2c871c).
One bug was found in the CompCert-KVX stack frame allocation code, which had no adverse consequence unless a very large stack frame or many parameters were used, which explains it was not detected earlier (commit fccfa9). Clobbered Registers Expansions of pseudo-instructions and builtins often use scratch registers. The registers that are clobbered by each pseudo-instruction and builtin are defined in the Coq file (Asm. v) giving the semantics of the abstract assembly language. Thus, changes to expansions must affect coherently both the Asm. v specification and the AsmExpand and/or TargetPrinter OCaml module. In the last few years, several specification bugs about registers clobbered by pseudo-instructions and builtins were found in CompCert, on several architectures. Commit 0df99dc4 fixes several wrong specifications of clobbered registers on AArch64; commit a4cfb9c2 on ARM;commit 39710f78 on RISC-V.
It seems that none of these bugs could result in the generation of incorrect code, for the registers that were wrongly specified not to be clobbered were not used by the CompCert code generator to store persistent data. The problem is that it was possible to modify the code generator with full correctness proof, and have CompCert generate incorrect code. For instance, some pseudo-instructions would use the return address register as a scratch register, not specified as clobbered. Some compilers perform leaf function optimization: the prologues and epilogues of functions that never call other functions do not save and restore the return address. CompCert applies this optimization only on the PowerPC architecture, and even then only partially; if one had added this optimization to AArch64 or RISC-V, incorrect code would be generated in leaf functions using the wrongly specified pseudo-instructions, though all proofs would go through.
Assembling and Linking CompCert produces assembly code in textual form, which must then be assembled and linked using another toolchain, such as gcc (the GNU Compiler Collection) or clang (LLVM). This toolchain is thus within the TCB. Absint GmbH, which sells the commercial releases of CompCert, also sells for certain architectures the Valex tool which matches the CompCert code to the binary code  [35, 25]. An alternative is direct generation of machine code, as in CakeML  [29] ; CompCertELF extends CompCert with a verified assembler for the x86 target  [56]. 37 Tristan & Leroy  [54]  had developed scheduling for CompCert but their developments were not made publicly available, let alone integrated into CompCert releases. 38 The CompCert-KVX team had private documentation on the KVX; despite that, due to the tedium of building tables, they had a few bugs, as shown by commit logs.
Foreign Function Interface CompCert's application binary interface (ABI) is not specified in a single point in CompCert: it comprises the calling convention, the value conventions implicit in the choice of instructions, etc. The correctness theorem of CompCert relates the execution of a C program, started from the main function, to the execution of the assembly program produced by its compilation, also started from the main function. It does not discuss functions compiled with other compilers calling a function compiled using CompCert. It also assumes that functions called from Some natural questions about "verified" software is: how truly safe is it? What kind of constructs should we be considered as suspicious? As more designs come with some formal proofs of correctness, even regulatory agencies have had to provide guidelines  [45].
T, P: mean annual temperature and annual precipitation based on annual climate data were obtained from meteorological weather stations near each plot. When local station data were not available, or observations did not cover the studied period, gridded data provided by national meteorological services or the Climatic Research Unit (CRU) Time-Series (TS) Version 3. 10 database  (Harris et al. 2020)  were used. MA: For characterizing the climatic conditions in the last 30 years before the plot establishment, we used the de Martonne aridity index (M = P/(T + 10))  (Martonne 1926). We selected these annual climate variables as it describes in a simple way the large variability of climates covered by study sites, from Mediterranean to boreal climates, and is related to productivity variation at large scales (Huang and Xia 2019) (Table  1 ).
With ε ik ∼ N(0, σ 2 ) we denoted independently and identically distributed errors. In all equations a 0 , …, a n are the fixed effects parameters. For all calculations, we used the libraries nlme  (Pinheiro et al. , 2021 ) and lme4  (Bates et al. 2015)  within the statistical software environment R 4. 1. 0 (R Core Team, 2021).
The initial size distribution was generated by random numbers from Gaussian normal distribution with a defined tree number, mean stem diameters and standard deviation using the R routine rnorm (). The whole model was developed as a script in R. We used realistic start parameters extracted from the empirical dataset of the 90 Scots pine plots. For the growth partitioning, we used equation (3), which estimates the annual stem diameter growth depending on the stem diameter at the beginning of the period, the quadratic mean stem diameter, and the site index, SI. The mortality was modelled in two steps; first, we estimated the number of dropout trees based on the selfthinning line and second, we selected the dropout trees from the size distribution. As the self-thinning line, we applied the equation ln(N) = 12 -1.
Acknowledgements This study was supported by the  ERA-Net COFUND programme SUMFOREST , with the national funding organization  Federal Ministry of Nutrition and Agriculture (REFORM , grant # 2816ERA02S ). The project has also received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement  No952314  and under the  Marie Skłodowska-Curie  grant agreement No  778322 , and the 2017 -2018  Belmont Forum and BiodivERsA joint call  for research proposals, under the  BiodivScen ERA-Net COFUND  programme, with the national funding organization  Federal Ministry of Education  and.
Live-cell 3D SRM also generally requires a considerably higher illumination dose than two-dimensional (2D) super-resolution images. A feature that severely compromises cell health and viability  41. Simultaneous multi-axial imaging when combined with super-resolution techniques, stands as an attractive alternative due to its capacity for near-instant volumetric imaging without discarding fluorophore https://doi. org/10. 1038/s41592-023-02057-w improvement in image quality (Fig. 1c ). Although these new implementations make eSRRF processing computationally more demanding, the implementation of OpenCL to parallelize calculations and minimize processing time allows the use of all available computing resources regardless of the platform  47. To evaluate the fidelity and resolution of eSRRF with respect to the underlying structure, we performed analysis of a DNA-PAINT dataset with sparse localizations.
For DNA-PAINT, standard SMLM localization algorithms applied to the raw, sparse data can provide an accurate representation of the underlying structure. By temporally binning the raw data, we generated a high-density dataset comparable to a typical live-cell imaging acquisition. Figure  1c  shows the comparison of the ground-truth (SMLM), eSRRF, SRRF and equivalent WF data. eSRRF is in good structural agreement with the ground truth and shows a clear resolution improvement over both the WF and the SRRF reconstruction. Line profiles reveal that eSRRF resolves features that were only visible in the SMLM reconstruction (Supplementary Fig. 1 ). We also estimated image resolution by Fourier ring correlation (FRC)  48  and decorrelation analysis  49. Both provide a quantitative assessment of the resolution improvement of the different image reconstruction modalities (Supplementary Table  4 ).