dataesr/scientific-paragraphs-categorization huggingface dataset:
To ease the visibility and understanding of the resulting formula, a generalized splitting transformation is typically applied, so as to decompose such a VC into a set of simpler VCs for specific properties to check, e. g. checking if an array index is in bounds, checking the preservation of a loop invariant, checking the pre-condition of a sub-procedure called, etc. Figure  2  presents a screenshot of Why3's graphical interface (Why3IDE) when given our toy program as input. The left part of that window is the proof task tree. The current selected line is for the proof task after applying the transformation named split_vc which implements the generalized splitting transformation mentioned above. Indeed the role of transformations is two-fold. The first role is to simplify the given task (such as the splitting above).
Adding Interactive Proving in SPARK Although the SPARK verifier, called GNATprove, is based on Why3 for generating VCs and proving them, there is a large gap between the SPARK and WhyML programming languages. Therefore, the interactive proof features of Why3 cannot be used directly by SPARK users. The same issue arose in the past with the counterexample generation features of Why3, which required translation back to SPARK for use inside GNATprove  [9]. That issue also involved interactions with users inside different IDEs, Why3IDE for Why3 users and GNAT Programming Studio for SPARK users, but that interaction was one-way only: the counterexamples output by provers were translated back to either Why3 or SPARK syntax and displayed in their respective IDE. Here, we need a two-way interaction where users can input commands (possibly with elements of the code as parameters) and Why3 returns a modified set of proof tasks.
We start by presenting a simple SPARK program that cannot be proved with automatic provers in Section 3. 1. Then we describe in Section 3. 2 the client-server architecture that we have adopted for twoway communication between the IDE for SPARK programs and Why3. We detail in Section 3. 3 how we translate back and forth between user-level names in SPARK and internal names in Why3. Finally, we explain in Section 3. 4 how to complete the proof of our example.
Unprovable Code Example The code in Figure  4  is a simplified version of an excerpt from a bounded string library. This code contains a post-condition that cannot be proved today by any prover available with SPARK (Alt-Ergo, CVC4, Z3). The reason for this unproved property is characteristic of the kind of problems faced by users of a technology like SPARK. It is in the class of problems called quantifier instantiation already presented in Section 2. The code in Figure  4  computes the location of a sub-list of integers within a list of integers, when the sub-list is contained in the list. Lists are implemented here as SPARK arrays starting at index 1 and ranging over positive indexes. The post-condition of function Location introduced by Post states the following properties: the result of the function ranges from 0 to the length of the list; a positive result is used when the sub-list is contained in the list, and value 0 is used as result otherwise.
For the sake of sages attached to program lines. Between these two instants, GPS called GNATprove; GNATprove translated the SPARK program into an equivalent WhyML program w. r. t. axiomatic semantics for generation of VCs; an internal program using Why3 API successively generated VCs by calling Why3 VC generator and dispatched VCs to provers; this internal program collected the output of provers and returned the overall results to GNATprove; GNATprove generated and adapted results for GPS, that displayed these results to the user. All this work occurred transparently for the user, who never had to see the generated WhyML code in Why3IDE, or to launch Why3 commands in a terminal. A less-than-ideal process for completing the proof of the post-condition would consist in asking the user to open the session file generated by Why3 in Why3IDE to complete the proof using the interactive proof feature described in Section 2.
While this would work, this is not a suitable solution in an industrial context. Indeed, asking users to interact directly with a generated artifact in a different language (the Why3 file) is akin to asking them to debug their programs at assembly level. While this is possible and sometimes useful, it is best left to rare occasions when this is really needed, and instead interaction should be done as much as possible at source code level. Most modern IDEs like GPS provide client-server interfaces with various tools such as debuggers or, in the context of formal verification, with proof assistants such as Emacs Proof-General support for Coq, Isabelle, Lego, HOL, etc. We have adopted a client-server architecture to allow two-way communications between the interactive proof module (acting as a server) and the client IDE, which can be Why3IDE or GPS here.
Client-Server Architecture For the integration in GPS, we developed both a wrapper in OCaml for the underlying service to act as the server, and a plugin in Python to communicate with the server from GPS. The server takes the session file as initial argument, gets its input in JSON format on standard input, calls Why3 core services, updates the session file accordingly, and returns its output in JSON format on the standard output. The plugin modifies GPS interface to add a console window for command-line interaction, a window to display VCs and a window to display the proof task tree. The plugin translates requests made by the user on the command-line interface into JSON requests that are sent to the server, and translates back the server notifications into updates of the graphical user interface (adding nodes in the proof task tree, changing the VC, etc.
The same windows are present but they are not located at the same place. From left to right, we can see the SPARK code window, the proof task window and the proof task tree window. The command-line console is displayed as a bottom panel sharing its window with other panels for Messages (tool output) and Locations (tool messages). The user can type commands for applying transformations and calling provers inside the command-line console, similar to what we saw for Why3IDE. One can observe that the VC from Figure  6  is much more complex than the simple VC we generated with Why3 in Figure  2. This is mainly a consequence of the complexity of the WhyML code generated from SPARK. Simple data structures and control flow in SPARK are modeled with much more complex data structures and control flow in WhyML to encode the semantic features of SPARK.
Printing of Proof Tasks and Parsing of Transformation Arguments In order for users to be able to relate the proof task to their code, it is necessary to use the names of source SPARK entities in the proof task instead of the generated Why3 names. This is achieved by creating a mapping from Why3 names to their source SPARK name during the generation of Why3 code from SPARK. This mapping is embedded in the WhyML code using labels, a generic mechanism in Why3 to attach strings to terms. For example, in the following code snippet the label "name:Not_y" is attached to the identifier y: let f (a:array int) (x:int) : int ensures {result = 20} = let y "name:Not_y" = 2*x+1 in y*y Labels on terms are preserved by VC generation and transformations. For example, the label "name :Not_y" remains attached to the constants derived from y in the final VC obtained after VC generation and transformations.
Application to the Unprovable Code Example With the interactive proof interface in GPS, we complete the proof of the post-condition of Location from Section 3. 1. For the sake of simplicity, we only describe the proof part of the then branch in this subsection, shown in the screenshot in Figure  6. The root of the proof task tree is green, showing that the initial VC was fully proved. The interactive proof proceeds by deriving a contradiction from the loop invariant property in the last iteration of the loop and the condition of the then branch Contains (Within, Fragment). This requires unfolding the definition of Contains and finding suitable instances of quantified properties. In this case, the proof task tree is linear and a complete proof script is the following: instantiate contains__def_axiom Within,Fragment rewrite Hinst in H16 destruct H16 destruct H destruct H instantiate H18 k The intuition of the proof is that we need to explain to the tool how to combine the hypotheses coming from the loop invariant and the definition of Contains.
Conclusions and Future Work We brought interactive proving features to the SPARK verification environment for Ada. This was done by conservatively extending the intermediate Why3 tool by allowing to pass arguments to proof task transformations. The design is generic enough to allow simple addition of new transformations via Why3's API. The proof session mechanism and the graphical interface have been extended to allow simple user interaction and facilities for proof maintenance. A few program examples were re-proved, showing that former external interactive proofs using Coq can be substituted with light interactive proofs in our new setting. The user interface of Why3 was redesigned under the form of a generic client-server architecture, allowing to bring interactive proving features to the SPARK front-end inside the regular GPS graphical interface.
Parameter Setting To select the best combination of RACO parameters, the irace package was used  (López-Ibáñez et al. , 2016). The irace package is an iterated racing procedure that was designed to automatic algorithm tuning. It is a generalisation of the iterated F-race procedure  (Birattari et al. , 2010). Irace executes an iterative process that starts with a finite set of candidate configurations, compares the performances of the initial configurations on training instances and selects the best among them. The best configurations are then used in the next iteration to generate more configurations for the parameters. The procedure is repeated until the tuning budget, which is given by the maximal number of configurations to be examined, is reached. The appropriate parameter settings are then returned.
, 15 times denser A T and C T compared to direct measurements). At the same time, they give access to the complete carbonate system. This potential is demonstrated by an observation-based global analysis of the Revelle buffer factor, Bittig et al. Robust Estimation of CO 2 Variables and Nutrients which shows a significant, high latitude-intensified increase between +0. 1 and +0. 4 units per decade. This shows the utility that such transfer functions with realistic uncertainty estimates provide to ocean biogeochemistry and global climate change research. In addition, CANYON-B provides robust and accurate estimates of nitrate, phosphate, and silicate. Matlab and R code are available at https://github. com/HCBScienceProducts/.
, 2015). These changes are, however, quite variable regionally and with depth  (Orr et al. , 2005). Elucidating the biological, ecological, biogeochemical, and socioeconomic consequences of ocean acidification  (Kroeker et al. , 2013; Gattuso et al. , 2014)  therefore requires a fine resolution of ocean CO 2 data in space and time. Until recently, there was no reliable sensor to assess the chemistry of the carbonate system and discrete samples collected by ships were therefore needed. Two databases compile these historical data. The Global Ocean Data Analysis Project version 2 (GLODAPv2,  Key et al. , 2015; Olsen et al. , 2016)  provides a quality-controlled, internally consistent data product for the world ocean that includes key variables of the carbonate system such as C T and total alkalinity (A T ).
We validate CANYON-B and CONTENT against bottle data from both a GLODAPv2 subset not used for neural network development and recent GO-SHIP cruises not included in GLODAPv2, as well as against Argo profiles of sensor data for pCO 2 and pH. Moreover, we explore the boundaries of such mappings by discussing surface pCO 2 estimates compared to 6 underway pCO 2 cruises where calibrated O 2 data were available, and surface pCO 2 derived from profiling float pH data, as well as surface seasonality. Finally, the potential of such mappings is explored (1) by illustrating how they can be used to combine different observing systems on the global scale, e. g. , using O 2 data collections from the World Ocean Database (WOD13,  Boyer et al. , 2013; accessed Mar 6, 2018) , GLODAPv2 or Argo to complement SOCAT data, (2) by showing how they can serve as transfer functions and go beyond existing data, e.
The day of the year was removed as an input variable, as the underlying GLODAPv2 bottle data are not adequately seasonally resolved in most areas. In regions where seasonal resolution and variations exist, they can be represented by other, co-varying inputs such as temperature. In addition, we use a decimal year as year input for the CO 2 variables (01 Jul. 2005 is 2005. 5), whereas CANYON used only an integer year causing Jan. 2005 and Dec. 2005 to be more similar than  Dec. 2005 and Jan. 2006. Finally, we adopted a stepwise training approach: Each network topology was first trained on a climatological dataset  (Lauvset et al. , 2016)  and then on GLODAPv2. The weights of the climatological networks were used to initialize the weights for the subsequent networks. This provides adequate starting points for the network training on the potentially scarcely distributed bottle data in multidimensional variable space.
GLODAPv2 Validation Data and Post-GLODAPv2 GO-SHIP Cruise Data We use the 20% of GLODAPv2 data set aside for validation to assess the neural network training success of CANYON-B. For pCO 2 , we compare the neural network results both against pCO 2 calculated from A T and C T (as for the training) and against pCO 2 calculated from combinations of A T , C T , and pH (as with CONTENT). The same data are used to compare CANYON-B results with CONTENT, CANYON  (Sauzède et al. , 2017) , and LIR (locally interpolated regressions,  Carter et al. , 2018)  results. They are assessed by the metrics above. For LIR and CANYON, part of the 20% CANYON-B validation data may have been used for training/algorithm development so their results might be too optimistic, but we believe them to be nonetheless in a realistic range.
Since the completion of the GLODAPv2 collection, a number of GO-SHIP repeat hydrography cruises were completed. Their data are likely of as high a quality as possible (albeit not yet made internally consistent) and they provide a completely independent validation set. As pCO 2 is not a measured variable, it was calculated from the combinations of A T , C T , and pH to arrive at the most likely value of pCO 2 given carbonate system constraints (i. e. , comparable to the CONTENT approach). In total, this validation set encompasses 19 cruises between 2012 and 2017 that cover all ocean basins. As part of these cruises has been included in the pH dataset of  Carter et al. (2018) , only the 6 more recent cruises (18MF20120601, 29AH20120622, 320620170703, 320620170820, 49NZ20121128, 49NZ20130106) were used for the pH comparison.
Surface Underway Observations of pCO 2 While surface underway observations of pCO 2 (by research or voluntary observing ships) are comparatively abundant and feed the majority of the data compiled in SOCAT unfortunately only very few obtain O 2 data of high accuracy in parallel. This hinders a direct comparison of surface pCO 2 estimates with pCO 2 data on a global scale, so that we had to limit our comparison to the six cruises described below. As part of the OCEANET project, surface underway measurements of several dissolved gases were performed onboard R/V Polarstern on six transects across the Atlantic Ocean in spring and autumn between 2008 and 2010. Cruises were either between Bremerhaven/Germany and Capetown/South Africa (ANT-XXV/1, ANT-XXVII/1) or Bremerhaven/Germany and Punta Arenas/Chile (ANT-XXIV/4, ANT-XXV/5, ANT-XXVI/1, and ANT-XXVI/4), with Apr.
/May cruises heading north and Oct. /Nov. cruises heading south. Surface O 2 was measured using a fully submerged oxygen optode (Aanderaa Data Instruments AS, Bergen, Norway; models 3830 or 3835) in a thermally insulated flow-through box (50 or 80 L volume). Seawater was continuously pumped through the box from the ship's keel intake (at 11 dbar) with a flow rate of ∼12 L min -1. Optodes were laboratory multi-point calibrated and sensor drift between deployments was checked against in-situ bottle observations. The pCO 2 measurements were done using different instruments, all of them following the same principle where water is led through a gas-water equilibrator with subsequent measurement of the xCO 2 in the dried, seawater-equilibrated air. During all cruises, an infrared sensor was used for CO 2 detection (either LI-6262 or LI-7000, LI-COR Biosciences, Lincoln, NE) which was calibrated every 3-4 h using three non-zero standard gases between 200 and 700 ppm, traceable to WMO scale.
After each calibration run, atmospheric air was measured for ∼10 min. The sea surface temperature (SST) and sea surface salinity (SSS) were recorded by the ship's thermosalinograph (SBE21, Seabird, Bellevue, WA). Atmospheric pressure was taken from the ship's weather station that is maintained by the German weather service. The data reduction for all cruises included the correction to SST and was done following the recommendations given in  Dickson et al. (2007)  and  Pierrot et al. (2009). As an additional reference, discrete water samples were taken up to four times a day during all cruises. The samples were analyzed for C T and A T in the laboratory at GEOMAR, Kiel. For the first cruise, ANTXXIV/4, water was pumped to the instruments using the ships rotary pump (installed at a depth of 11 m).
A custom-built underway pCO 2 system with a combined laminar flow/bubble equilibrator was used, which is described in detail in  Körtzinger et al. (1996). The resulting accuracy was estimated to be ±3 µatm. For the second cruise, ANTXXV/1, water was drawn from two different inlet points (5 and 11 m) using a membrane pump. The infrared analyzer was coupled to a small (0. 5 L) equilibrator. Due to the different inlets and resulting different intake temperatures, the dataset was treated carefully for the different settings. The resulting accuracy is ±5 µatm. For the remaining cruises, ANTXXV/5 -ANTXXII/1, water was pumped to the instruments using the ships rotary pump (installed at a depth of 11 m). A commercially available pCO 2 instrument was used (GO, General Oceanics, Miami, FL) which uses a shower head equilibrator and is described in  Pierrot et al.
(2009). The resulting accuracy was estimated to be ±2 µatm. pCO 2 /O 2 Profiling Float Observations To date, only one experimental Argo-type float was deployed with a pCO 2 sensor  (Fiedler et al. , 2013) , so opportunities for an on-platform, depth profile validation of pCO 2 are very limited. Nonetheless, this float provides a unique data set since it was recovered and redeployed several times, thus providing insight into sensor drift thereby allowing drift and other corrections. A HydroC pCO 2 sensor (Kongsberg Maritime Contros GmbH, Kiel, Germany) and a battery/buoyancy container were mounted on the float's side. Profile data were acquired on the float's ascent. Details about the float, the pCO 2 sensor, and data treatment can be found in  Fiedler et al. (2013)  and  Fietzek et al. (2013) , respectively.
In addition, its O 2 optode data were recalculated according to most recent knowledge, including drift behavior, pressure compensation, response time correction, and in-air calibration  (Bittig et al. , 2018). The float was deployed four times (D4-D7) between Nov. 2010 and Jun. 2011 near the Cape Verde Ocean Observatory (CVOO) in the eastern tropical North Atlantic. It performed a total of 123 profiles (111 with pCO 2 data) between 200 dbar and the surface. The float was lost and could not be recovered at the end of deployment D7, which means that only low-resolution HydroC data transmitted by satellite are available. This limits the potential of post-correction of the pCO 2 data, notably the sensor's time lag correction (see  Fiedler et al. , 2013, for details) , and so we group D4 -D6 separately from D7.
Transfer Data Set of Quality-Controlled O 2 Profiles Quality-controlled and calibrated data of O 2 profile data were compiled using both shipboard hydrographic stations (WOD13 and GLODAPv2) as well as Argo-O 2 profiles accessed from various sources. WOD13 data are Northern hemisphereand coastal ocean-focused, while GLODAPv2 O 2 profiles have a globally balanced distribution (Figure  1 ). Ship-based observations cover mostly the decades before 2010, and are strongly biased toward summer in both hemispheres while Argo-O 2 float data have a focus on the Southern Ocean and the subpolar North Atlantic. They are mostly limited to the last decade and they are seasonally unbiased. In order to exclude coastal/shelf stations we used all O 2 profiles from WOD13 after Jan 1, 1945 that sampled to at least a depth of 250 m.
Data were additionally quality controlled for reasonable ranges of T, S, and O 2 , which leaves a total of 383 465 profiles between  Sep 4, 1945, and Apr 21, 2017. From GLODAPv2, only those data were used where salinity and oxygen had both a good primary QC (WOCE-type flag 2 meaning "acceptable") as well as where they had been made internally consistent by a crossover analysis (secondary QC flag 1). In the Mediterranean, only one zonal repeat hydrography section exists that does not intersect with any other sections, which prevents a crossover analysis there. Therefore, the second condition was relaxed (secondary QC flag 0) for the two cruises in GLODAPv2 across the Mediterranean. Moreover, there had to be at least 5 samples per profile. These criteria matched to 31 980 profiles from 521 cruises between Jul.
24, 1972, and May 20, 2013. For Argo, a total of 262 floats with adjusted and quality controlled O 2 data were obtained from the Argo Global Data Assembly Centre (GDAC) at Coriolis (ftp. ifremer. fr/ifremer/ argo/) on May 15, 2018  (Argo, 2000). They encompass 38 622 CTD-O 2 profiles between Feb. 24, 2005, and May 14, 2018. In addition, calibrated data of 84 Argo-O 2 floats deployed by the University of Washington (http://runt. ocean. washington. edu/o2/) were included in the transfer data set. This excludes floats with a calibration accuracy estimate larger than 5 µmol kg -1 as well as floats covered by SOCCOM, which are already included in the GDAC data. This adds a total of 14 347 profiles between Oct. 26, 2005, and Aug. 24, 2015. Moreover, data from 2 floats consisting of 401 calibrated O 2 profiles between Sep.
27, 2013 and Dec. 6, 2016, (see  Bittig and Körtzinger, 2017)  as well as from 12 floats deployed as part of the remOcean project with 2 253 profiles  (Oct. 24, 2012 -Apr. 13, 2018)  were added. The Argo-O 2 data set contains 360 individual floats with 55 623 calibrated profiles  (Feb. 24, 2005 -May 14, 2018)  with global coverage and a focus on the Southern Ocean and the North Atlantic. For comparison, there are 13 916 profiles with concurrent A T and C T observations in GLODAPv2 within the three decades it covers. The GLODAPv2 O 2 data set encompasses 31 980 profiles for the same period, which represents already a densification by a factor of 2. 3. The complete transfer data set contains about 470 000 O 2 profiles distributed over 7 decades, i. e. , an average densification by a factor of 15.