dataesr/scientific-paragraphs-categorization huggingface dataset:
ESR measurements In Figure  12 , the electron density, electron and ion temperatures and ion velocity are plotted as a function of altitude, as obtained from the ESR data (using the GUISDAP software,  Lehtinen & Huuskonen 1996). The full lines represent the average values during the period under study. The error bars represent the extrema measured during this period. We plot the data from both radars: the 42 m dish (parallel to the magnetic field) in blue and the 32 m dish (pointing west magnetic) in black. In the E region, the maximum electron density is about 9 • 10 9 m À3 at 150 km with the 42 m dish and 3 • 10 10 m À3 at 170 km with the 32 m dish. These values are very low, showing a very quiet atmosphere. The variability with height is high although the values themselves always remain in the range of a quiet ionosphere.
2009 ). This data processing has been improved, so that we provide here the new development. We determined a Mueller matrix M 4 (e. g. Clarke 2010) proportional to: M 4 ¼ 1 P i 0 0 P i 1 0 0 0 0 R 0 0 0 0 R 0 B B B @ 1 C C C A ; where P is the DoLP, and R ¼ ffiffiffiffiffiffiffiffiffiffiffiffiffi 1 À P 2 i q. In the following, the index o stands for ''observed'', r for ''real'' and i for ''instrumental'', h the AoLP. The initial state of polarisation, hereafter referred to as ''real'', is described by the Stokes vector S r S r ¼ I r Q r U r V r 0 B B B @ 1 C C C A ; whilst the observed polarisation is described by the Stokes vector S o S o ¼ 1 P o 0 0 0 B B B @ 1 C C C A : Circular polarisation is null because a linear polariser is used (V o = 0). In  Lilensten et al. (2013a) , the observed direction of polarisation h o is chosen as reference axis for the linear polarisation and the relation between S o and S r is given by S o ¼ R À1 4 M 4 R 4 S r ; ðA1Þ where R 4 is the rotation matrix In the following, Sa = sin2a, Ca = cos2a, and R ¼ ffiffiffiffiffiffiffiffiffiffiffiffiffi ffi 1 À P 2 i q.
Acknowledgements. The present research project has been supported by the European Project  COST MP1104  ''Polarisation as a tool to study the Solar System and beyond'' and the European  FP7 Project ESPAS , Grant Agreement No:  283676  (Near-Earth Space Data Infrastructure for e-Science). EISCAT is an international association supported by research organisations in China (CRIRP),  Finland (SA), Japan  ( NIPR  and STEL),  Norway (NFR), Sweden (VR)  and the  United Kingdom (NERC). We thank  D. Lorentzen  and  F. Sigernes  at  UNIS  for their invaluable contributions. J. Moen  was supported by the  Research Council of Norway  Grant  208006/F50. J. Lilensten  and  M. Barthélemy  thank the institute  IPEV  for its continuous support. All the plots in this article have been made with the Gildas Greg software developed at the  Institute of Metric Radio Astronomy (IRAM)  and used in many international astronomical facilities.
( 13 ) The implementation of the halo model we use is described fully in  Coupon et al. (2012). We derive the best-fitting halo models corresponding to our measurements using the "Population Monte Carlo" (PMC) technique as implemented in the CosmoPMC 2  package to sample likelihood space  (Wraith et al. 2009; Kilbinger et al. 2010). For each galaxy sample, we simultaneously fit both the two-point correlation function w and the number density of galaxies n gal , by summing both contributions to the total χ 2 : χ 2 = i,j [w obs (θi) -w model (θi)](C -1 )i,j[w obs (θj) -w model (θj)] + [n obs gal -n model gal ] 2 σ 2 gal , ( 14 ) where C is the data covariance matrix. The error on the galaxy number density σ gal contains both Poisson noise and cosmic variance.
5 which deviates markedly and consistently from all trends presented in this paper. To investigate further the discrepancy at 1 < z < 1. 5 we used the "WIRDS" data set  (Bielby et al. 2012)  to investigate the nature of the differences between COSMOS and other data. Although WIRDS is shallower than the present data set, it consists of four fields separated widely on the sky. We measured correlation functions in averaged mass-thresholded data in WIRDS and compared it to the COSMOS field. Interestingly, we find that the WIRDS data agrees with COSMOS on large scales, but a small scales there is much more power in COSMOS than in WIRDS. The implication which this has in the halo model fits can be seen in Figure  8 : for a given abundance, the derived halo masses are much lower than one would expect, essentially because of the much steeper one-halo term.
ACKNOWLEDGMENTS HJM acknowledges financial support form the " Programme national cosmologie et galaxies " (PNCG). This work is based on data products from observations made with  ESO Telescopes at the La Silla Paranal Observatory  under  ESO  programme  ID 179. A-2005 and on data products produced by TERAPIX and the  Cambridge Astronomy Survey Unit on behalf of the UltraVISTA consortium. JSD acknowledges the support of the  European Research Council  via the award of an  Advanced Grant , and the contribution of the EC  FP7   SPACE  project  ASTRODEEP (Ref. No:  312725 ).
Statistical analysis Data are presented as mean + SEM. Where data were not normally distributed they were transformed prior to analysis to achieve normal distribution. Time to delivery data was log-transformed before analysis; and the proportion of dead pups was arc-sin transformed prior to analysis. Data were analysed by one-way analysis of variance to compare treatment groups, followed by either Dunnett's or Newman-Keuls multiple comparison tests between treatment groups to identify significant differences. All statistical analyses were performed using GraphPad Prism 5. 0 software (Graph Pad, San Diego, CA, USA). P , 0. 05 was considered to indicate statistical significance.
generation to bridge the gap between high-level design models and low-level implementations. In MDD, models are often used by code generators. Since design errors in the models may be propagated into the implementations via model-to-code transformation, it is very important to uncover design errors during the early stages of software development. In MDD, models must conform to the well-formedness rules of the metamodel. Such well-formedness rules can be thought of as invariants of the metamodel. One needs to check the models to ensure that the invariants of the metamodel are satisfied using automated tools such as Eclipse OCL  [Tea05] , so that the developers can identify potential problems during design time before they are used to generate code. However, the existing tools are inefficient for invariant checking on large models.
In this paper we focus on analyses that involve checking the consistency between a model and the invariants defined in a metamodel. However, checking whether a model is a valid instance of the metamodel is out of scope of the paper. This means that we assume the model conforms to the structural constraints (e. g. , multiplicity constraints) defined in the metamodel, but may or may not satisfy the invariants defined in the metamodel. We have developed a framework that provides: (1) an implementation of the model slicing technique; (2) an implementation for checking models against invariants defined in the metamodels. The framework was implemented using Java and the Eclipse Modeling Framework (EMF)  [SBMP09]. Even though the evaluation framework builds upon Java and Eclipse, the slicing technique is not bound to a particular technological space, and it can be implemented using any language and framework.
Invariant Checking USE  [GBR07] , developed by the Database Systems Group at Bremen University, is a modeling tool for specifying object-oriented systems. It allows developers to generate models (expressed using the object diagram notation) that are checked against user-specified properties such as invariants expressed in a metamodel (expressed using the class diagram notation). A system with a set of invariants can be specified using the USE specification language, that is based on a subset of the Unified Modeling Language (UML)  [EFLR99]  and the Object Constraint Language (OCL)  [Spe07a]. A model can be created using the shell commands provided by the USE tool. The feedback provided by the USE tool includes highlighted invariants that are inconsistent with the given model. Alloy  [Jac02]  is a formal specification language that was developed by the Software Design Group at MIT.
The Kermeta language [JCB + 13] was developed by the Triskell Team at INRIA. It is an executable metamodeling language implemented on top of the Eclipse Modeling Framework (EMF)  [SBMP09]  within the Eclipse development environment. It has been used for specifying models, and model transformations that are compliant to the Meta Object Facility (MOF) standard  [Omg08]. The Kermeta workbench allows developers to specify well-formedness rules, often formulated as invariants, on metamodels. These rules can be expressed using an OCL-like specification language. The Kermeta workbench provides several APIs for evaluating OCL-like invariants against models. It reports warning information if a given model does not satisfy the invariants defined in the metamodel. The Eclipse OCL project  [Tea05]  is an implementation of the OCL standard  [Spe07a]  for EMF-based models.
Model Slicing Kagdi et al. [KMS05]  proposed an approach for slicing class models. The slices are applicable to models that do not require a context (e. g. , a set of scenarios in which objects are involved) for the computation of a model slice. OCL invariants are not considered in their slicing approach. Blouin et al. [BCBB11]  described a model-driven approach to specifying model slicers for different domain specific modeling languages. The approach relies on Kompren, a modeling language dedicated to the construction of model slicers, that aims at automatically building model slicers for any languages. Kompren can be used to produce a slicer for the slicing approach described in the paper. Sen et al. [SMBJ09]  proposed a slicing technique for metamodel pruning by removing unnecessary classes and properties from a metamodel.
Motivation Errors detected in the design phase of the software development process are less expensive to fix than those detected later. One approach used by software designers for checking correctness is to ensure that a model conforms to a predefined metamodel using automated tools. This involves the following steps. (i) A software modeler designs a metamodel and defines a set of Well-Formedness Rules (WFRs) specified in the form of invariants which must be satisfied by models conforming to the metamodel. (ii) He creates a set of models that conform to the metamodel structure. (iii) He checks models against the WFRs using invariant checking tools such as the Eclipse OCL checker  [Tea05]. The entire process works well for small models with hundreds of elements, and the modeler can receive the feedback from the checking tools within seconds or minutes.
However, given the growing complexity of software systems, models used to represent these complex systems are also growing significantly in size. While design models were built by hand in the early days of MDD, nowadays models with possibly more than one million elements can be built programmatically. For example, we used a reverse engineering tool, namely MoDisco  [BCDM14] , to generate Java models from multiple Eclipse platform plugins. These models can have up to one million elements. The checking time goes up significantly for large models with hundreds of thousands of elements. This motivates the improvement of the scalability of the invariant checking approach in the context of large models. In the approach described in the paper, checking models against invariants does not need the entire metamodel and the full model to be actually processed.
Such invariants cannot be expressed directly using the class diagram notation, and thus are specified using other languages such as the OCL  [Spe07a]. The model in Figure  2   Tools such as the Eclipse OCL checker  [Tea05]  can be used in this situation for invariant checking. They take as input the invariant, the metamodel and the model, and produce checking results, indicating whether the model is consistent with the invariant defined in the metamodel. In this case, the model in Figure  2  does not violate the UniqueTicketNumber invariant defined in the metamodel since t1, t2, t3 have different numbers (i. e. , 1, 2, 3). Note that to check the UniqueTicketNumber invariant, we only need to look into the tickets and their numbers. The rest of the model is not relevant to the checking. Indeed, the UniqueTicketNumber invariant is defined in the context of the Ticket class and only refers to the number attribute in the Ticket class.
Evaluation Framework Implementation We developed an evaluation framework that provides (1) implementation of the proposed slicing technique, and (2) implementation for checking models against metamodels with invariants. The metamodels used in the evaluation are expressed using the Ecore [SBMP09] standard (i. e. , the de-facto standard to define metamodels), the models used in the evaluation are expressed using the XMI [Spe07b] standard (i. e. , the de-facto standard to serialize models), and the invariants used in the evaluation are expressed using the OCL  [Spe07a]. The evaluation framework was implemented using Java and Eclipse development platform. Even though the evaluation framework builds upon Java and Eclipse, the slicing technique is not bound to a particular technical space, and it can be implemented using any language and framework.
The framework also builds upon the Eclipse Modeling Framework (EMF)  [SBMP09]  and the Eclipse OCL project  [Tea05]. The framework uses the Eclipse OCL project to (1) parse the OCL invariants defined in a metamodel and (2) check a model against the metamodel with OCL invariants since the Eclipse OCL project also builds upon EMF. Both the implementations of the slicing technique and the evaluation framework can be found in https://github. com/sunwuliang/SlicingProject3. 0.
Large Models The metamodel used for the evaluation is the Java metamodel from the EMF  [SBMP09]. The reasons for this choice are: (1) it is fairly complex having 345 model elements including classes, attributes, references, and enumerations and (2) its relevant conforming models are relatively easy to collect from Java programs using reverse engineering tools. The models used for the evaluation are generated from 73 Eclipse plugins (Java programs). The reason we chose Eclipse plugins is that the models generated from the Eclipse plugins are quite large. We used a reverse engineering tool, namely MoDisco  [BCDM14] , to generate models from these plugins. Six invariants were used in the evaluation. The complete data used in the evaluation can be found in https://github. com/sunwuliang/SlicingProject3.
Small Models The small models used in the evaluation were collected from state-of-the-art model repositories: ReMoDD [Tea13b] and Metamodel Zoos  [Tea13a]. Below is a list of the collected models: • FSM [Tea13a], a domain model that describes the concepts of a finite state machine; • ER2MOF  [Tea13b] , a domain model that describes a model transformation from an entity-relationship schema to a relational model; • HTML  [Tea13a] , a domain model that describes the HyperText Markup Language (HTML); • MATLAB  [Tea13a] , a domain model that describes the MATLAB language; • MARTE  [Tea13a] , a domain model that describes the MARTE profile. These models conform to the UML2 standard, and were manually created by domain experts. These models are much smaller than the models generated by the reverse engineering tools.
Ray is a Professor in the Computer Science Department at Colorado State University. She has also been a visiting faculty at Air Force Research Laboratory and at INRIA, Rocquencourt, France. She obtained her Ph. D. from George Mason University under the joint supervision of Professor Sushil Jajodia and Professor Paul Ammann. Her research interests include security and privacy, database systems, e-commerce and formal methods in software engineering. She has published over a hundred technical papers in refereed journals and conference proceedings. She is on the editorial board of Computer Standards and Interfaces. She was the Program Chair of ACM SACMAT 2006, Program Co-Chair for CSS 2013, ICISS 2013, IFIP DBSec 2003, and General Chair of SACMAT 2008. Contact her at iray@cs. colostate. edu.
Indrakshi Ray is a Professor in the Computer Science Department at Colorado State University. She has also been a visiting faculty at Air Force Research Laboratory and at INRIA, Rocquencourt, France. She obtained her Ph. D. from George Mason University under the joint supervision of Professor Sushil Jajodia and Professor Paul Ammann. Her research interests include security and privacy, database systems, e-commerce and formal methods in software engineering. She has published over a hundred technical papers in refereed journals and conference proceedings. She is on the editorial board of Computer Standards and Interfaces. She was the Program Chair of ACM SACMAT 2006, Program Co-Chair for CSS 2013, ICISS 2013, IFIP DBSec 2003, and General Chair of SACMAT 2008. Contact her at iray@cs. colostate.
Most programming languages natively provide an abstraction of character strings. However, it is difficult to assess the design or the API of a string library. There is no comprehensive analysis of the needed operations and their different variations. There are no real guidelines about the different forces in presence and how they structure the design space of string manipulation. In this article, we harvest and structure a set of criteria to describe a string API. We propose an analysis of the Pharo 4 String library as a first experience on the topic.
Orthogonality: Combining variations of abstract operations; for instance, substituting one/several/all occurrences corresponding to an index/character/sequence/pattern, in a case-sensitive/insensitive way. In previous work, empirical studies focused on detecting non-obvious usability issues with APIs  [12, 13, 11] ; for practical advice on how to design better APIs, these works cite guideline inventories built from experience  [2, 6]. Besides the examples set by particular implementations in existing languages like Ruby, Python, or Icon  [8] , and to the best of our knowledge, we are not aware of string-specific analyses of existing APIs or libraries and their structuring principles. Section 2 shows the problems we face using the current Pharo 4 string library. In Sections 3 and 4, we identify idioms and smells among the methods provided by Pharo's String class.
Pharo: Symptoms of Organic API Growth As an open-source programming environment whose development branched off from Squeak, Pharo inherits many design decisions from the original Smalltalk-80 library. However, since the 1980's, that library has grown, and its technical constraints have evolved. In particular, since Squeak historically focused more on creative and didactic experimentation than software engineering and industrial use, the library that has evolved organically more than it was deliberately curated towards a simple and coherent design. Even though we restrict the scope of the analysis to the String class, we face several challenges to identify recurring structures and idioms among its methods, and to understand and classify the underlying design decisions. Large number of responsibilities.
Besides its inherent complexity, intertwining of behaviors means that, despite the large number of methods, there is still no guarantee that all useful combinations are provided. Some features are surprisingly absent or unexploited from the basic String class. For instance, string splitting and regular expressions, which are core features in Ruby or Python, have long been thirdparty extensions. They were only recently integrated, so some methods like lines, substrings:, or findTokens: still rely on adhoc implementations. This reveals refactoring opportunities towards better composition of independent parts. Confusingly, some similarly named methods do not accept the same arguments, while some use different wording for similar behavior. For instance, findTokens: and replaceAll:with: accept single characters, but their relatives findTokens:keep: and copyReplaceAll:with: require collection; conversely, compare the predicates isAllDigits but onlyLetters, or asUppercase and asLowercase but withFirstCharacterDownshifted.
Impact of immutability. In some languages such as Java and Python, strings are immutable objects, and their API is designed accordingly. In Smalltalk, strings historically belong in the collections hierarchy, and therefore are mutable. In practice, many methods produce a modified copy of their receiver to avoid modifying it in place, but either there is no immediate way to know, or the distinction is made by explicit naming. For instance, replaceAll:with: works inplace, while copyReplaceAll:with: does not change its receiver. Moreover, the VisualWorks implementation supports object immutability, which poses the question of how well the historic API works in the presence of immutable strings. Duplicated or irrelevant code. A few methods exhibit code duplication that should be factored out. For instance, with-BlanksCondensed and withSeparatorsCompacted both deal with repeated whitespace, and findTokens: and findTokens:keep: closely duplicate their search algorithm.
Some methods generate a number of separate results, accumulating and returning them as a collection. This results in allocating and building an intermediate collection, which is often unnecessary since the calling code needs to iterate them immediately. A more general approach is to factor out the iteration as a separate method, and to accumulate the results as a special case only. A nice example is the group of line-related methods that rely on lineIndicesDo:; some even flatten the result to a single value rather than a collection. Collection lines, allRangesOfSubstring:, findTokens:, findTo- kens:keep:, findTokens:escapedBy:, substrings, substrings: Iteration linesDo:, lineIndicesDo: In our opinion, this idiom reveals a wider problem with Smalltalk's iteration methods in general, which do not decouple the iteration per se from the choice of result to buildin fact, collections define a few optimized methods like select:thenCollect: to avoid allocating an intermediate collection.
Inconsistencies and Smells Here we report on the strange things we found. Redundant specializations. Some methods express a very similar intent, but with slightly differing parameters, constraints, or results. When possible, user code should be rewritten in terms of a more general approach; for example, many of the pattern-finding methods could be expressed as regular expression matching. Substring lookup findAnySubStr:startingAt: and findDelimiters:-startingAt: are synonymous if their first argument is a collection of single-character delimiters; the difference is that the former also accepts string delimiters. Character lookup indexOfFirstUppercaseCharacter is redundant with SequenceableCollection»findFirst: with very little performance benefit. Ad-hoc behavior. Ad-hoc methods simply provide convenience behavior that is both specific and little used.
Miscellaneous lineCorrespondingToIndex Mispackaged or misclassified methods. There are a couple methods that do not really belong to String: • asHex concatenates the literal notation for each character (e. g. , 16r6F) without any separation, producing an ambiguous result; it could be redefined using flatCollect:. • indexOfSubCollection: should be defined in Sequence-ableCollection; also, it is eventually implemented in terms of findString:, which handles case, so it is not a simple subsequence lookup. Many ad-hoc or dubious-looking methods with few senders seem to come from the completion engine; the multiple versions and forks of this package have a history of maintenance problems, and it seems that methods that should have been extensions have been included in the core packages. Misleading names.