dataesr/scientific-paragraphs-categorization huggingface dataset:
Among these, 189 bugs were confirmed and 176 bugs were fixed. Most notably, Generative Type-Aware Mutation found 18 soundness bugs in CVC4's default mode alone. Several of them (7/18) are at least 2 years latent and predated all previous SMT solver fuzzing campaigns. • We examine Generative Type-Aware Mutation in comparison to the two closely related approaches, type-aware operator mutation and FuzzChick, theoretically and practically through code coverage comparisons. Organization of the Paper. Section 2 describes Generative Type-Aware Mutation using an illustrative example. Section 3 introduces Generative Type-Aware Mutation formally and describes the implementation of TypeFuzz which realizes Generative Type-Aware Mutation. Section 4 presents the evaluation of our approach. In Section 5, we present several bug samples and their root causes.
ILLUSTRATIVE EXAMPLE This section gives a brief introduction to the SMT-LIB language  [Barrett et al. 2010 ] and illustrates Generative Type-Aware Mutation on an example. SMT-LIB Language. We consider the following subset of statements: declare-fun, assert, check-sat and get-model. Variables are declared as zero-valued functions. For example, the declaration "(declare-fun x () Real)" declares a variable of type Real with name x. An assert statement specifies constraints. The predicates within the constraints have different types, e. g. , the constraint "(assert (<= (/ x 4) (* 5 x)))" includes predicates of Real and Bool types. Multiple constraints can be viewed as the conjunction of the constraints in each individual constraint statement. The "(check-sat)" statement queries the solver to decide on the satisfiability of a formula.
If all constraints are satisfied, the formula is satisfiable; otherwise, the formula is unsatisfiable. We can obtain a model, i. e. , a satisfiable assignment, for a satisfiable formula by the "(get-model)" statement. Generative Type-Aware Mutation in Steps. The key idea of Generative Type-Aware Mutation is mutating expressions in the AST of an SMT-LIB script by newly generated expressions of the same type. Let  be a seed formula (see Fig. 2 ). Step 1 Choose a random expression: We first choose a random expression expr 1 from the set of 's expressions expr (). Say we have picked the expr 1 = x. The expression is of type String and will serve as the replacee (i. e. , the candidate to be replaced) for the newly generated expression. Step 2 Choose a random operator: Next, we choose a suitable random operator.
Generative Type-Aware Mutation We first introduce Generative Type-Aware Mutation as regular tree grammar and then show under which conditions generative type-aware mutants are well-typed. Regular Tree Grammar. A regular tree grammar  = ( , Σ, , ) consists of a finite set of nonterminals  , a ranked alphabet Σ, a starting nonterminal  in  , and a finite set of productions. Each symbol in Σ has an associated arity, and the productions in  are of the form  →  where  ∈  and  ∈  Σ with  Σ being the set of all trees composable from symbols Σ ∪. The language () generated by  describes any tree that can be derived from  using the rule set. Definition 1 (Generative type-aware mutation). Let  GTA = ( , Σ, , ) be a regular tree grammar and  a formula: • 𝑁 = types • Σ = expr (𝜑) • 𝑆 = skeleton(𝜑) • 𝑃 = 𝑃 expr ∪ 𝑃 gen where ś 𝑃 expr = {type → expr | expr ∈ expr (𝜑) ∧ type(expr) = type} ś 𝑃 gen = {type → (op arg_types(op)) | op ∈ ops type } We say a formula 𝜑 mutant is a generative type-aware mutant of 𝜑 if 𝜑 mutant is in 𝐿(𝐺 GTA ).
A generative type-aware mutant  mutant of  can be conveniently fabricated by replacing an expression expr 1 within  with an expression expr 2 which is either another type-conforming expression from expr (), or rooted with a new operator of type-conforming return type and typeconforming arguments from expr (). Generative type-aware mutations will by design not lead to type-incorrect replacements, e. g. , replacing an integer expression by a string expression. However, as the following example illustrates, they also do not guarantee well-typed mutants. Consider the following formula in SMT-LIB language:  = (and (> x 10) (forall ((z Int)) (< z y))) We choose expr 1 = (> x 10), expr 2 = (< z y) and replace expr 1 by expr 2 in. The resulting formula  mutant is by definition a generative type-aware mutant of : 𝜑 mutant = (and (< z y) (forall ((z Int)) (< z y))) However,  mutant is not well-typed since the variable z is out of the scope of the quantifier.
Relationships to FuzzChick and Type-Aware Operator Mutation This section clarifies the relationships between generative type-aware mutation and two related techniques that have been used for stress-testing software, FuzzChick and type-aware operator mutation. We adapt them to the formal setting of this paper. Type-Aware Operator Mutation  [Winterer et al. 2020a ]: OpFuzz embodies type-aware operator mutation and is an effective technique for SMT solver testing. The key idea is to mutate operators of the same type. Let  be an SMT formula and let op 1 of type type 1 be one of its operator and op 2 of type type 2 be an operator of the SMT-LIB specification. 𝜑 mutant = 𝜑 [op 2 /op 1 ] is a type-aware operator mutant if type 2 is a subtype of type 1. Let formula  be a formula and  GTA = ( , Σ, ,  gen ∪  expr ) the regular tree grammar specifying generative type-aware mutations for.
We have reported this bug to the CVC4 issue tracker. The developers promptly fixed this four-year longstanding soundness issue in CVC4. Type-aware operator mutation cannot generate this bug since the number of operators has increased from  to  mutant. Differences in Practice. As a key difference to FuzzChick, generative type-aware mutation can leverage all available operators from the SMT-LIB specification for the types in its skeleton. In contrast, FuzzChick is limited to the operators occurring in the seed formula. If the seed formula contains all operators from the SMT-LIB specification for all the types in its skeleton, the two techniques are identical, i. e, the grammars ( GTA ) and ( FC ) would induce the same language. However, in practice, this is rarely the case. In contrast to type-aware operator mutation, generative type-aware mutation can generate expressions rooted by operators from the SMT specification with type-conforming terms from the seed file as its arguments while type-aware operator mutation can only mutate operators.
TypeFuzz Based on Generative Type-Aware Mutation, we have engineered TypeFuzz, a bug hunting tool for SMT solvers. This subsection details the underlying procedures of TypeFuzz. Main Process. Algorithm 1 presents the parameterized pseudocode of TypeFuzz. The main process takes a set of seed formulas, seeds, and a set of SMT solvers, solvers under test. First, the algorithm reads a configuration file (Line 2). The configuration file (see Fig. 4 ) contains all signatures of SMT-LIB operators and can be customized by the user. The list triggers is used for collecting the bug triggers and is initialized to the empty list (Line 3). The body of the while loop is executed until a termination criterion is met. This could be a timeout or an interruption by the user. We first randomly chose a formula  from seeds (Line 5).
Implementation. We have implemented TypeFuzz on top of the SMT solver fuzzer yinyang  [Winterer et al. 2021]. For that matter, we implemented the generative type-aware mutation as a mutation strategy (260 LoC) and augment the yinyang framework by a type-checker (790 LoC). TypeFuzz's mutations can be customized with a configuration file. We have used the configuration file from Fig. 4. Its syntax is similar to the meta-language of SMT-LIB theory specifications. 3 We hope this will facilitate SMT developers and practitioners to run customized configurations and have released our tool on GitHub 4. The tool can be installed via pip install yinyang.
• Invalid model bug: Formula  triggers an invalid if the model returned by the solver does not satisfy. • Crash bug: Formula  triggers a crash bug if the solver throws an assertion violation or a segmentation fault. TypeFuzz detects soundness bug triggers by comparing the standard outputs of the solvers. TypeFuzz detects invalid model bug triggers by internal errors using the model of the SMT solver. Crash bug triggers are detected whenever a solver returns a non-zero exit code and no timeout occurs. Bug triggers. Dozens of sizable bug triggers usually point to the same underlying bug. Hence, we need to de-duplicate and reduce the bug triggers. For bug reduction, we use two reducers with complementary strengths: pydelta  [Kremer 2021 ], a domain-specific reducer for the SMT-LIB language and C-Reduce  [Regehr et al.
2012 ], a C code reduction tool that also works for the SMT-LIB language. TypeFuzz collects bug triggers that may stem from the same underlying bug. Hence, we de-duplicated the bug triggers after each fuzzing run with TypeFuzz to avoid duplicate bug reports on the GitHub issue trackers. Crash bugs are either assertion violations or segmentation faults. We de-duplicate assertion violations via the location information (file name and line number) printed on standard output/error. For soundness and invalid model bugs, we first categorize the bug triggers by theory. We do this because bug triggers in different theories are likely to be unique bugs. Then, we select one bug trigger per theory at a time for reporting. If the bug was fixed, we check the remaining bug triggering formulas of the same theory.
5a ). As for the duplicates in Z3, their main developer followed a rather aggressive approach by categorizing every bug as duplicate  RQ3: Are Generative Type-Aware Mutation and operator mutations orthogonal? To answer this research question, we have run an experiment to measure the code coverage of TypeFuzz compared to its seeds, the state-of-the-art fuzzer for SMT solvers OpFuzz  [Winterer et al. 2020a ]. We have sampled 100 files from all test seeds and then ran the following four configurations: A run on each seed from the chosen set with Z3 and CVC4 (Seeds), the state-of-the-art fuzzer OpFuzz, our tool TypeFuzz, and the sequential combination of OpFuzz and TypeFuzz, all with the initial set of seeds. The number of mutating iterations for each seed is 10 and the timeout for each solving query is 8 seconds.
For all coverage measurements we used gcov 6  from the GCC suite. Fig. 7  shows the cumulative coverage data. We first observe that both OpFuzz and TypeFuzz cover strictly more code than the seed set on Z3 and CVC4 respectively. From the first three rows Seeds, OpFuzz, and TypeFuzz, we deduce that both OpFuzz and TypeFuzz can cover additional code as compared to the seeds. For OpFuzz, this increase is rather low (+0. 6% LoC in Z3 and +0. 8% LoC in CVC4) confirming previous experiments  [Winterer et al. 2020a ]. For TypeFuzz, the increase is significantly higher in Z3 (+2. 2% LoC) and slightly lower in CVC4 (+0. 7% LoC). Looking again at the first three rows, we can also deduce that TypeFuzz covers code that OpFuzz does not, since TypeFuzz's percentage is higher than OpFuzz's (17. 8% vs 19.
4%). From the third and fourth rows, we deduce that OpFuzz also covers different code regions than Typefuzz since there is an increase in code coverage, i. e. , 19. 7% for TypeFuzz + OpFuzz versus 19. 4% for TypeFuzz alone. This indicates that OpFuzz and TypeFuzz are complementary in terms of code coverage. Limitations. Generative type-aware mutation has been demonstrated to be effective for SMT solver testing. Naturally, it also comes with some limitations. First, generative type-aware mutation cannot add new assertions to the seed formula. Second, it cannot mutate unseen constants. For example, if a bug would be triggered by a term (= (str. len x) 5) and all but the constant "5" would occur in the seed formula, generative type-aware mutation could not generate the term and may miss the bug.
Generative fuzzers  [Hanford 1970 ] synthesize test inputs from scratch using a language grammar or a (language) model. Csmith  [Yang et al. 2011]  generates random C programs through repeated application of rules from the C grammar. Similar to generative typeaware mutation, Csmith relies on differential testing to cross-check the generated seeds. Csmith has found 300+ bugs in the compilers GCC and LLVM. A recent follow-up work to Csmith is YarpGen  [Livinskii et al. 2020 ] which additionally prevents generating C programs with undefined behavior. Another recent generative fuzzing approach is pivot query synthesis (PQS)  [Rigger and Su 2020]. It synthesizes specific SQL queries on random databases. Unlike Csmith and YarpGen, PQS's is a metamorphic testing approach. Moreover, researchers have adapted generative language models  [Godefroid et al.
ACKNOWLEDGMENTS We thank the anonymous SPLASH/OOPSLA reviewers for their valuable feedback. Our special thanks go to the Z3 and CVC4 developers, especially  Nikolaj Bjùrner ,  Andrew Reynolds ,  Haniel Barbosa ,  Andres Nötzli  for useful information and for addressing our bug reports. Chengyu Zhang  was partially supported by the  NSFC  Projects No. 61632005  and No. 61532019.
Zoological nomenclature, the discipline of taxonomy responsible for managing the scientific names of animal taxa, takes its roots in the work of Carolus Linnaeus, and has been governed by an international Code since the beginning of the 20th century. Like any other scientific discipline, it has developed its own vocabulary, which has gotten increasingly complex with time. However, it sometimes lacks clarity in its terminology. New terms have been defined by various authors to reduce ambiguity or replace existing problematic terms. To make these new terms, but also terms used by the International Code of Zoological Nomenclature (the Code), accessible, an electronic Simple Knowledge Organization System (SKOS) thesaurus was created, called Zoonom.
Zoonom was built using an open-source thesaurus-making software, Opentheso. Opentheso complies with the most recent standards i. e. , ISO 25964-1 (International Organization for Standardization 2011) and ISO 25964-2 (International Organization for Standardization 2013). The thesaurus is shared online through the LOTERRE platform (Linked Open TERminology REssources). SKOS is part of the Semantic Web family of standards and a World Wide Web Consortium (W3C) recommendation for controlled vocabularies and thesauri. It is itself based on the Web Ontology Language (OWL). See some applications of SKOS and semantic web for biodiversity in  Larmande et al. 2013. Zoonom contains 920 terms (excluding terms from the same word families, like plurals), distributed within 794 concepts, 404 etymologies and 58 references.
It is divided into 20 collections and covers every aspect of zoological nomenclature, from theoretical nomenclature to taxonomic publications. Find the link to a downloadable file in the description of Zoonom. The thesaurus can be used as a classical glossary, using the search bar, or in alphabetical order, but this is not its only feature. Gathering different terms under a single concept also offers the possibility of refining the terminologies, and thus accessing a less ambiguous equivalent term. A richly developed vocabulary enables better labeling of particular names or situations in databases, software, or in the context of Semantic Web. As an example, let's focus on the concept of nomen dubium. It is defined by the Code as "a name of unknown or doubtful application" (International Commission on Zoological Nomenclature 1999).
A better description of the scientific names in databases is beneficial both for information retrieval and intercommunication. Zoonom is destined to be updated at least once a year. Any relevant propositions of new concepts are highly welcomed. We are especially looking for terms widely used in a part of the taxonomic community, or associated with a particular taxon, but unknown or obscure outside of these applications. Crosslinking the common concepts with the NOMEN OWL ontology  (Yoder et al. 2017 ) and Wikidata might be implimented in the near future. In conclusion, Zoonom should help provide a better understanding of zoological nomenclature and assist in the curation and management of databases by offering improved tags and definitions.
 EMBER is a new, freely available, GUI software that models magma ascent rates for basalt to rhyolite with H2O, CO2 and S diffusion profiles  EMBER was validated by reproducing previous published literature data  For mafic eruptions, we found a notable correlation between maximum recalculated decompression rates and eruption magnitude or plume height ABSTRACT Magma decompression rate is one of the most important parameters in controlling eruption dynamics. One way to determine decompression rate is by fitting a volatile elements diffusion profile to a concentration gradient in crystal-hosted embayments. Previous studies have used a variety of diffusion models, limiting the possibility for inter-study comparison. Here, we introduce EMBER (EMBayment-Estimated Rates), a standalone versatile tool that models diffusion of volatile elements along melt embayments.
Our model relies on the pdepe function of MATLAB to calculate diffusion profiles of H 2 O, CO 2 and S through the finite difference method. EMBER uses a grid search seeking out the best fits for decompression rates, initial dissolved concentration of each studied volatile and initial exsolved gas content, while setting three constants: temperature along the ascent and pressure at the beginning and end of the ascent. Our model can compute the rate for basaltic, intermediate, and rhyolitic compositions. We applied EMBER to previous studies to evaluate and validate our model. We then re-processed "homogeneously" the raw data from the literature for a comparison. In other words, the same protocol was used for each diffusion profiles removing the literature-specific strategies used to constrain unknown parameters.
Existing embayment volatile diffusion models Several such numerical models have been developed in the last decades (Table  1 ). The first published code was developed in FORTRAN 77  [Liu et al. , 2007]. Assuming a certain temperature, pressure, initial concentration, exsolved gas, degassing path and decompression rate, the code generated time-dependent profiles of H 2 O and CO 2 concentrations until the fragmentation pressure is reached. The process was repeated several times with different decompression rates to find the best fit. A second model was presented by  Humphreys et al. , [2008]  using the COMSOL multiphysics software to model only H 2 O profiles. Their model imposes the final concentration at the mouth of the embayment from the start of the calculation and allows the software to run the diffusion calculation.
Lloyd et al. , [2014]  developed a model calculating simultaneously, for a range of decompression rates, three volatile element profiles at once: H 2 O, CO 2 and S. In a following study, an improved development of a MATLAB code by  Ferguson et al. , [2016]  took H 2 O, CO 2 and S into account and considered not only a range of decompression rates but also the initial concentration of each volatile element as well as the exsolved gas content at the beginning of the ascent (M 0 ) for basaltic compositions. The addition of this new parameter: (M 0 ), the preexisting (already exsolved volatile content in equilibrium with magma at the onset of a magma ascent), proved to have a significant impact on the modelled profile and made the grid search more complex and the result better constrained  [Ferguson et al.
, 2016]. Another study subsequently build the FORTRAN 77 model from  Liu et al. , [2007]  in MATLAB with updated diffusion coefficients for rhyolitic compositions and a best fit search algorithm  [Myers et al. , 2018]. This code was later updated taking the pressure at which degassing stops as a free parameter  [Myers et al. , 2021]. Another code, written in Rstudio and restricted to basaltic melts, took into account all the aforementioned parameters with fixed inputs and was made openly available  [Moussallam et al. , 2019]. One of the most recent model is tuned to intermediate magma compositions, contains a specific S solubility relation and a general H 2 O diffusion coefficient relation for intermediate magma, and looks for the decompression rate and initial pressure  [Newcombe et al. , 2020].
The latest model to date is written in Matlab and uses grid searches to find decompression rate, initial concentration of H 2 O and S and exsolved gas content  [Moussallam et al. , 2021]. At present, seven different data processing methods to model volatile diffusion profiles in embayments exist; each published study uses its specific model written on four different platforms  (FORTRAN 77, COMSOL, MATLAB and RStudio). Other than the code of  Moussallam et al. , [2019] , none are directly downloadable without a specific request to the authors. Each code considers different input parameters, different volatile species and is tuned to a specific melt composition. This lack of consistency is an issue for inter-study comparison and the lack of open software access can be an impediment to a large number of new studies on natural products.
The aim of this article is to provide the community with a user-friendly and crossoperating system MATLAB code that is able to constrain decompression rates from volatile diffusion in melt embayments for rhyolitic to basaltic melt compositions, and for as wide a range of starting conditions as possible. We then retroactively analyze all volatile diffusion profiles from the literature using EMBER. Our results help identify potential discrepancies in published decompression rates, notably for the Mt St Helens 1980's eruption, and provide an easily comparable, self-consistent summary of decompression rates obtained from volatile element diffusion in melt embayments published to date. Our software, EMBER, calculates results likely comparable to those by the DIPRA software  [Girona and Costa. , 2013] , which can extract timescales from diffusion zoning in olivine crystals, and is also a widely distributed MATLAB program.
Best fit determination The second part of the code compares a measured concentration profile to a series of calculated ones (with N set of parameters) to find the best fit and its associated parameters (i. e. grid search). EMBER favours the grid search over other more efficient optimization methods (e. g. gradient search method), because with the mixture of diffusion of dissimilar species, it is not clear a priori if there will always exist a unique solution. While computationally intensive (and inefficient), we consider it is more suitable to take an approach of "calculate-all". The best fit is determined by comparing the dimensionless normalized residual square error (  ) for each  of N sets of parameters, 𝑁𝐸𝑟𝑟 𝑗 = ∑ 1 𝑢 𝑗 2 𝑖 (𝐶 𝑖𝑗 -𝐶𝑠 𝑖𝑗 ) 2 (9) where   is the analytical measurement uncertainty applied at the highest volatile concentration measured in the embayment; usually at the interior of the embayment (i.
Propagation of errors The uncertainties on the fit parameters ,    0 (   ) are assessed by the statistical distributions of the parameters that are extracted from the calculated profiles  that satisfy the following condition (Figure  1. Step 3): Pr(𝑎 -𝜎 1 ≤ 𝑦 ≤ 𝑎 + 𝜎 2 ) = 68% (10) Here,  is the value for which _ is the smallest, and  1   2 respectively the lower and upper boundaries of the confidence interval, calculated using the prctile MATLAB function. For every j calculated profiles (with a set of parameters), there is a corresponding. Equation (10) states that there are cases of calculated profiles for which  is within the expected uncertainty. EMBER extracts the corresponding parameters (dPdt and C i ) and report the distribution of values as mean and 1-σ confidence interval, which are the best fit parameter and an associated uncertainty (Figure  1.