dataesr/scientific-paragraphs-categorization huggingface dataset:
This is discussed in more detail in section 3. 1. The software options filled in grey highlight any default settings in the software. What is immediately clear is the significant difference in complexity between the three software packages. The NPL software is the simplest of the three. Once the file is input, there are only two sections to the software: λc Filter and Parameter Calculations -all that is required according to ISO 5436-2. The NPL software has no user options; once the file is chosen, the process is autonomous and the parameter values are calculated. This simplicity keeps the software package streamlined; its scope is accurately defined to match the requirements of a type F2 software measurement standard according to ISO 5436-2, and the software avoids the added complexity of additional features that can introduce further error or ambiguity.
Following the filtration, the choices become more limited. Users are able to select which parameter values are exported, along with certain inputs such as height/spacing discrimination values. The user can also choose the algorithm with which to calculate the material ratio parameters, which are not included in the NPL software. Following these parameter choices and their calculation, the results can be exported in. CSV file format and a. PDF report. During the filtration step of the software, the data is shown to the user visually, along with all obtained profiles. A visual representation of the data is a useful addition, as seeing the data allows for a much better understanding, compared to a long dataset of raw values. The NIST software at first looks highly complex, however, closer inspection reveals that the choices available to the user are relatively simple; there are instead more optional steps following the parameter calculations.
First, the user has the option of not only choosing their own data file to run through the software, but also a reference data file from NIST's database. The ability to load files straight from the NIST database makes it easier for users who are using a NIST type F1 data file with their own software, as they can run the same file through the NIST software without having to download the file first. The user interface for the NIST software uses click-able tabs along the top of the window for selecting different sections of the software, allowing user control over which operations are performed. Additional sections in the software include power spectral density calculation, autocorrelation/cross-correlation and bearing-areacurve determination. Each of these additional sections come with simple choices to the user, such as the profile on which to operate and which method to use.
As with PTB, NIST includes optional form removal and λs filtering. For λc filtering, the choices are more limited than those given by PTB. The user can choose between Gaussian or 2RC filter methods; 2RC choices are between recursive and convolution methods, whereas Gaussian methods are between convolution, 'Fast Gaussian' and fast Fourier transform. For the Gaussian methods, the user can also choose whether to use a ±0. 5λc or ±λc Gaussian window, which dictates how large the cut-off regions are for the roughness and waviness profiles. Similar to PTB, the NIST software also shows the input data visually, albeit at a lower resolution.
If possible, no additional steps shall occur. For point four in the list above, the discrimination values of 10% of Xz and 1% of the sampling length are taken from sections 4. 1. 4 and 4. 3. 1 in ISO 4287. This definition presents some ambiguity, as it can be interpreted as ±5% around the mean line, ±10% around the mean line, or 10% of the peak-to-valley height in a profile element. It is unknown how each of the NMIs have interpreted this definition, and so the Xz discrimination value may be a source of potential differences in the parameter results. The closest routes through the NIST and PTB software are shown by the thick lines on the flow diagrams in Figures  12  and 11. For both NIST and PTB, it was possible to avoid extra steps, such as form removal and λs filtering. The NIST software, being tabular in nature, allowed the selection of only the λc filtering and parameter calculation steps.
The PTB software is more sequential than the NPL software, forcing users to go through all steps of the software including material ratio parameter calculations, which are not required in this comparison, as the NPL software does not calculate them. However, while material ratio parameter calculations added time to the processing of the data files, it did not affect the filtration or values of the other parameters. Both software packages allowed the selection of a Gaussian convolution as the λc filter, matching that used by NPL. The NIST software also allowed the use of a ±λc Gaussian window, leading to a cut-off length of λc from each end of the filtered profiles, matching that of NPL. Both NIST and PTB also allowed the selection of the same ISO 4287 parameters that NPL calculates. Combined, these options allow for pathways through the software packages that are sufficiently close to allow a meaningful comparison.
Sampling length ambiguity ISO 4288 defines the evaluation length for the roughness profile to be built from a total of five sampling lengths, where each sampling length is equal to the length of λc. However, ISO 4288 does not specify from where the sampling lengths will be taken if the profile length is longer than 5λc. The NPL software chooses to take the five sampling lengths from the centre of the profile, but it is not known whether NIST and PTB choose to do the same. This lack of guidance in the specification standards is another source of ambiguity than can lead to different parameter results, as the NMI software packages may be calculating the parameter values from sampling lengths with different starting points.
g. polished, ground. • Simulated profiles -Profiles that are numerically generated and present as simple shapes, e. g. sinusoids, steps, squares. • Profile amplitude -The height values of the peaks and valleys. • Profile source -The location from which the profiles were obtained. The test files used were type F1 reference data files taken from both NPL and NIST. Taking files from NIST and NPL type F1 databases ensures the test files used come from reliable sources, and allows the test to be repeatable by anyone. In order to comply with the input requirements of NPL, primary profiles must be used. The NPL datasets were assumed to already comply with their own software requirements, however, this proved to be a false assumption, as discussed in section 4. 5. 1. Although the NIST datasets are by default given as total profiles, primary profiles are included in the downloadable.
NIST input file issues ISO 5436-2 defines the standard file-type for profile datasets to be. SMD  [10]. ISO 5436-2 also gives a description of how the file should be structured, including the different records in the file and what they should contain. ISO 5436-2 also defines that each line, record and file should be ended with specific control characters, which are ASCII characters used to give information to the software reading the file, and are not represented by any written symbol. As a result, most common text editors do not show these characters, and a more advanced program is needed to read or write them. It was found that in order for files to be accepted by the NIST software, the. SMD file had to be terminated with the <SUB>, <CR> and <LF> control characters. ISO 5436-2 states 'The last record is further terminated by an end of file (<ASCII 26>)' (<26> is the SUB control character).
While somewhat ambiguous as to what else should go on the final line, the examples given in the document show the <SUB> character should be on its own. Because of this, the NPL files, which terminated with just <SUB> in line with the ISO examples, could not be opened by NIST. It was found that the NIST software would only open the NPL files if the date in the revision number inside record 1 was changed from '2000' to '1999'. Changing this date has a knock-on effect of invalidating the checksum given at the bottom of the file, which is calculated using the ASCII values from the first three records. For the file to be accepted, the checksum needed to be updated. A further error was found in some of the NIST type F1 files. The files used were primary profiles from the total profiles listed in the NIST database.
It appears that in recreating the. SMD files with the primary profile data values, the number of points in the profile were not recounted. For some files, a small number of points had been removed from the profile, perhaps due to an effect of the form removal or λs filter. However, the first record in the. SMD file defines the number of points in the file, and this number had not been updated to the true number for the primary profile, and instead matched the number for the total profile. In order for these files to work, the number of points had to be recounted, and the first record in the. SMD updated.
NPL input requirements Because the NPL software has no user input once the file has been selected, all settings and required information must be included in the. SMD file. The. SMD must include which parameters to calculate, and the λc value for the Gaussian filter. While versions of the NPL datasets could be downloaded with this information already in the. SMD file, the NIST files did not. To make the NIST type F1 files ready for use with the NPL software, each file had to include these NPL software instructions. As including the software instructions edits the characters in the. SMD file; the checksum also had to be recalculated and updated for these files.
Software outputs Each file was processed through each software package using the user options shown in Figures 10, 11 and 12. All files were run with λc = 0. 8 mm. Keeping λc fixed for all files had several benefits; it reduced the complexity of the experiment, was the default setting for the NPL downloaded files, and allowed for potential effects to be seen for test files where λc = 0. 8 mm is outside the optimum value for the cut-off filter. Once all parameter calculations were complete, the next step was to extract the parameter values from the software in order to analyse them. Each software package outputs the parameter values in a different format. The NPL software allows either a. SMD or. HTML file to be saved. The PTB software gave the parameter values in the form of. CSV, and gave a.
As all normalised parameter values for the chosen reference are equal to one, their values are omitted from the graphs. Figure  1  shows that for both files, the Primary and Roughness peak/valley parameters obtained by NPL are around 20% larger than the values obtained by the other two. The overestimations for peak/valley parameters suggest that the interpreted profiles have a larger amplitude in the z-direction than those of NIST and PTB. Both NIST and PTB assess the discrete data points directly, however, NPL uses a cubic spline function to interpolate the data and produce a continuous representation. While interpolation can lead to more accurate parameter calculations for many profile shapes, for very steep steps, as found in both square and steps, the cubic spline can oscillate, causing overestimations of peak and valley values.
After discussions with PTB directly about the large waviness parameter values in comparison with NPL and NIST, it was discovered that PTB treat the ends of the waviness profile differently to NPL and NIST. In order to account for end effects, both NPL and NIST cut off the ends of the profile of length λc, and assess the remaining central portion. PTB, however, does not do this for the waviness profile. This causes the waviness profile to be longer and include more data points in the PTB software than the other two, leading to a greater chance of there being another peak (valley) with a high (low) value and resulting in a larger final parameter. The reason for this difference in software implementation between the NMIs stems from an ambiguity in the ISO definition. The evaluation lengths for the primary and roughness profiles are defined in ISO 4288 section 4.
NIST Wc and WSm failures The NIST software was unable to obtain a value for Wc and WSm for any test file, including its own reference data sets. Due to the nature of the calculation of Wc and WSm, and the low amplitude of the waviness profile for many of the test files, it was anticipated that the software packages would struggle to obtain the values for all test files, however, not being able to obtain any is a notable issue. The result is shown in Figure  4 , where PTB and NPL are shown to obtain values for some files, but NIST obtains none. It should be noted here that it is because of the Wc and WSm failures that there are no results shown for Wc and WSm on any relative parameter value graph for which NIST is the reference NMI. Upon further research into the implementation of these parameters by NIST, it was found in their 'help' documentation that the height discrimination for the Xc and XSm parameters is defined as a user set percentage of Rz.
The ISO 4287 defines the height discrimination to use Xz, e. g. use Wz for Wc/WSm. The description of the height discrimination in the NIST documentation could simply be poorly worded, however, if the documentation truly describes the implementation of the software, the use of Rz instead of Wz could explain the lack of results. As the waviness profiles have a lower amplitude than the other profiles, if the software were to be using 10% of Rz for the height discrimination instead of Wz, the cut-off height would be higher than the majority of the waviness profiles, leading to a greatly reduced number of profile elements and, therefore, no data from which to calculate the parameters.
A good example of this is shown in Figure  6 , where the waviness profiles for the millsim and normrand files are shown. For the millsim dataset, from which the NPL software was able to obtain waviness parameters, at least three crossing points are present for each sampling length. For the normrand dataset, from which the NPL software could not obtain waviness parameters, there are at most two crossing points per sampling length, with one sampling length containing no crossing points. The information obtained from Figure  6  suggests that the NPL software requires a minimum number of mean line crossing points within each sample length to calculate the parameter values. Whether this is the correct approach is up for debate, as an argument can be made that a surface with so few mean line crossing points may not be suitable to calculate parameter values that are meaningful and descriptive of the surface.
NPL reference file form removal As discussed above, part of the investigation into the NPL waviness issue was a test to see whether form was present on some of the input files. Form should be removed to ensure that a sufficient number of points cross the mean line to enable the calculation of meaningful waviness parameters. Interestingly, for just two of the seventeen files, form removal had not been performed. The files with form present were millsim and step, both taken from the NPL database. Originally, millsim was one of the files that failed to obtain waviness parameters, however, once form had been removed, the NPL software was successful and obtained results that showed very good agreement with the NIST software. Upon bringing the issue of two of the files requiring form removal to the attention of NPL, it was discovered although the NPL reference software requires a primary profile as input, it is not necessarily the case that the reference datasets match the input requirements of the reference software.
Height/spacing parameter disagreements As was expected, notable amounts of disagreement between NPL, PTB and NIST were found for the height/spacing parameters, Xc and XSm. As mentioned above, previous work uncovered some ambiguities in the definition of the RSm parameter that led to the potential for different interpretations to obtain different results  [18]. As Xc uses the same discrimination methods as XSm, the same issues are expected to apply. Although  Leach   In addition, the PSm results, shown in Figure  9 , show NPL obtaining significantly larger values than NIST and PTB for seven data files. Such an effect is not observed on the roughness parameters, suggesting the application of the filter removes this issue. NPL's tendency to obtain larger values for PSm could, therefore, be related to the extended length of the profile, as there are no end effects to manage so no ends are cut.
In particular, several conclusions can be made: • The NPL software's choice of spline interpolation leads to overestimations of sharp steps. • The NPL software is unable to obtain waviness parameter values for some files, due to omitting profiles with an insufficient number of mean line crossing points per sampling length. • PTB's alternative interpretation of waviness profile end management leads to larger waviness parameter values. • The NIST software fails to obtain values for Wc and WSm parameters, potentially due to a misinterpretation of the height discrimination definition. • Ambiguities in the height/spacing discrimination definitions cause different obtained results for the XSm and Xc parameters. • Lack of guidance in where the sampling lengths should be taken from a profile may lead to different sampling lengths being chosen, and different parameter values being obtained.
Problems were encountered when dealing with the. SMD files, in which slightly different formats were leading to input failures. Some of the. SMD difficulties were due to poor formatting of the file or limitations of the software on NIST's side, however, it should be considered that those errors are in part due to the convoluted nature of the. SMD file structure, including outdated control characters which are invisible to the user of any mainstream text editor. It comes as no surprise that both NPL and NIST offer the reference data files in a selection of other data formats, as the. SMD format adds an unnecessary additional layer of complexity to the process. Additionally, the NIST and PTB reference software also accepts different file formats as inputs. It is suggested that the. SMD file format be removed from ISO 5436-2 and replaced by a more robust format which does not require such specific use of control characters.
Data Collection / Recording We used one camera set in front of the table to record the tabletop screen, students' interactions, gestures, and postures. We also collected logs to quantify interactions on the tabletop and tablets and complement the videos, e. g. know what was displayed on the tablets of the participants. After the experiment, students were asked to fill in a questionnaire containing 5-point Likert-scale and free-form questions about their perception of learning and their feelings on using the combination of devices to carry out the activity.
Analysis Method We focused our analysis on the four behaviors identified earlier. We used two type of data sources, the recorded videos, and logs. The goal of the analysis was not to provide quantitative data of the activity but to give qualitative insights on how students behaved and collaborated in MSE. We tried to understand how the design of our application impacted activity and device usage, and contributed to the decision-making process. To do so, we defined a coding scheme for the analysis of videos based on the literature presented previously  (Ratcliffe, 1997; Hornecker et al. , 2008; Rogat and Linnenbrink-Garcia, 2011). Two coders analyzed the videos independently on different samples. They did an inter-rater reliability test with the result of 85% agreement. Then one researcher analyzed three groups and the other analyzed one group.
Discussion in survey We counted the number of discursive acts in the survey step and we observed how devices were used during the discussions. Options and criteria were mostly the main focus of discussions whereas discussing the context and comparing options occur few times in this step (Table  2 ). We observed mostly two participants focusing on one tablet during discussions followed by two or three students focusing on the shared display and hybrid chat using both shared display and tablet. Students had most discussions dyadically and used tablets to discuss, especially when the discussions were related to options and criteria. They used tablets to check a specific option, analyzing the data according to the criteria and exchanging ideas. The shared display was often used when students discussed about the context and their preferences (example of a discussion in Table  3 ).
ACKNOWLEDGEMENTS This research would not have been possible without the teachers  Cerise, Pascaline, Xavier, Cécile, Sébastien and Caroline  who participated to the design and made the activity possible, as well as the amazing students from  LPA la Martellière in Voiron. This work was partially funded by the  China Scholarship Council PhD program  and the  ANR  project  JENlab  ( ANR-13-APPR-0001 ).
Automated white-box testing is a major issue in software engineering. In previous work, we introduced LTest, a generic and integrated toolkit for automated white-box testing of C programs. LTest supports a broad class of coverage criteria in a unified way (through the label specification mechanism) and covers most major parts of the testing process -including coverage measurement, test generation and detection of infeasible test objectives. However, the original version of LTest was unable to handle several major classes of coverage criteria, such as MCDC or dataflow criteria. Moreover, its practical applicability remained barely assessed. In this work, we present a significantly extended version of LTest that supports almost all existing testing criteria, including MCDC and some software security properties, through a native support of recently proposed hyperlabels.
I. INTRODUCTION Context. Automated white-box testing is a major topic in software engineering  [1] ,  [2] ,  [3] ,  [4]. Along the years, many tools have been proposed for supporting different parts of the testing process. These tools explicitly or implicitly rely on a code-coverage criterion (a. k. a. adequacy criterion or testing criterion)  [3] ,  [4]  to guide automation. Such a criterion formally specifies what the test objectives are. These can then be used to assess the quality of a test suite and to guide the selection of additional test cases. In previous work  [5] ,  Bardin et al. introduced  LTest, a generic and integrated toolkit for automated white-box testing of C programs. LTest is generic in the sense that it handles a wide set of coverage criteria in a unified way. It is also integrated in the sense that it centralizes heterogeneous techniques to automatize most key tasks in white-box testing.
Indeed, in addition to test replay and coverage measurement, the tool leverages a dedicated version of Dynamic Symbolic Execution  [6] ,  [7]  for providing coverage-oriented test generation  [8]. It also relies on static analyses from the Frama-C  [9]  platform to provide efficient detection of uncoverable test objectives  [10]. Goals and Contributions. While the original version of LTest already supported a large scope of criteria, it relied on a specification mechanism whose expressiveness remained limited with regard to some other exiting criteria. As a consequence, LTest was unable to handle several classes of criteria such as strong variants of MCDC, as well as criteria based on data-flow analysis or path exploration. Yet, such Work partially funded by French ANR (grant ANR-12-INSE-0002).