dataesr/scientific-paragraphs-categorization huggingface dataset:
Following standard practice in the literature, we exclude from the sample bidders that operate in regulated utilities (SIC code 4900-4999) or in the financial industry (SIC code 6000-6999) and bidders with negative book equity. We further require each bidder to match on the CRSP and COMPUSTAT databases. We require that annual financial data for the calculation of the control variables (see below) are available in COMPUSTAT for each bidder, and that the  Peters and Taylor (2017)  data on intangible capital (see below) are available on WRDS. We extract data for the most recent annual report that is filed not more than a year before the announcement. The corresponding takeover announcements, filed as 8-K forms, are then downloaded from the EDGAR platform, the Electronic Data Gathering, Analysis, and Retrieval system, which performs automated collection and distribution of data and public filings by companies and others who are required by law to file forms with the SEC.
Public companies must file an 8-K form with the SEC within four business days to announce material events that shareholders should know about. Form 8-K is a "current report. " It is not filed in the regular time intervals, but is triggered by a significant event like a CEO departure or an M&A. Only 8-Ks filed no later than 4 business days after the announcement date of the deal are used in the analysis. 5   Table  SA. 1 summarizes the sample construction. The final takeover sample consists of 3,036 deals. Several databases provide additional data needed for testing our hypotheses. Analyst stock buy-sell recommendations are from I/B/E/S (Recommendations -Summary Statistics section). Insider trading data are from Thomson Reuters Insider Filings. Managerial incentives, computed as in  Core and Guay (2002)  and  Coles et al.
We use daily observations of temperature, precipitation and humidity rate. Humidity rate is the amount of water vapor in the air expressed as a percentage. It indicates the likelihood of precipitation, dew or fog. Humidity may result in consumer behaviors distinct from those caused by precipitation. Weather data is extracted from the National Oceanic and Atmospheric Administration GSOD database. The measure of abnormal weather in a given month is the average anomaly calculated as the average difference between the daily observed weather and its normal value.
Computational study In this computational section, we first introduce our benchmark set of instances and provide implementation details, before we discuss the obtained computational results. All the experiments have been performed on a computer equipped with a 3. 40 gigahertz 8-core Intel Core i7-3770 processor and 16 gigabytes of RAM, running a 64-bit Linux operating system. The source codes were compiled with gcc 4. 8. 4 and using -O3 flag, for compiler optimization. We used CPLEX 12. 7. 0 (called just CPLEX for brevity in what follows) and the CALLABLE LIBRARIES The latter two functions allow to separate the Benders cuts described in Sections 4 and 5 , for fractional and integer solutions, respectively.
The number of explored nodes is still relatively low and this figure never goes beyond 200 nodes, which can be also explained by the high quality of the LP relaxation bounds. The source code of our branch-and-Benders-cut algorithm as well as the benchmarking data set of instances can be downloaded at https://github. com/fabiofurini/LocationCovering. The software was given the DOI (Digital Object Identifier) https://doi. org/10. 5281/zenodo. 1412080.
Equilibrium models 5 ended up mediating controversies on trade, notably on the level of agricultural subsidies in the USA versus in the European Economic Community in the 1980s  (Fouilleux, 2000). American universities and research institutes played a leading role in the development of these equilibrium models. The US Department of Agriculture and the Ford Foundation funded the International Agricultural Trade Research Center (IATRC), a think tank whose goal was to equip the OECD and the GATT negotiations with the economic toolkit that delegitimized subsidies and led to trade liberalization in agriculture  (Joly and Lacombe, 2017). The US also supported networks of modelers working on the development of an international agricultural database, such as the Global Trade Analysis Project (GTAP) created in 1991 at the Purdue University in interaction with the FAO and the OECD  (Leblond and Trottier, 2016; Dorin and Joly, 2019) , which is still widely used today.
As for GLOBIOM, it relates human activities (food, fiber, energy, industry) with both environmental and economic equilibriums. IMPACT has long dominated the field and still benefits from its "return on investment", in a modeler's terms. It has become a reference tool for providing foresight on food security and malnutrition. However, it has been deemed less relevant than GLOBIOM to provide scenarios on the interactions between agriculture, environment, and energy, as it uses a database representing both forests and farming. According to interviewees, IMPACT would be threatened if GLOBIOM were able to improve the way it represents food security: -You were saying that GLOBIOM is the most dominant model? […]  It is a dominant model in terms of publications, and in terms of the issues dealt with: […] they've got farming, they've got a very good forestry model, etc.
Acknowledgements This research was supported by a grant from the  French National Research Agency  for the  INNOX  project, " Innovation in Expertise. Modelling and simulation as tools of governance"  ( ANR-13-SOIN-0005 ), coordinated by  David Demortain. I am grateful for comments on earlier versions of Cornilleau this article from participants in INNOX workshops, especially from  Stefan Aykut ,  Bilel Benbouzid ,  David Demortain , and  Bertrand Schmitt. Additionally , advice from  Jérôme Aust ,  Olivier Borraz ,  Patrick Castel ,  Pierre-Benoît Joly ,  Jean-Noël Jouzel ,  Scott Viallet-Thévenin , and two anonymous reviewers of Science & Technology Studies greatly improved the paper. I also thank  Annelies Fryberger  for her excellent language editing.
Resolution procedure We use an exhaustive search to solve effectively these models. All tests of this paper have been performed on a desktop computer, Pentium 4 with Intel Core 2 Duo CPU (3 GHz 2. 93), and 2 GB RAM. We use MATLAB to implement different algorithms. In the following, we give different algorithms of our analytical resolution procedure. (20 ) o wo = Rev o wo -IC o wo + MC o wo + PC o wo + SC o wo + OC o (21) Rev o wo = c o max ⋅ Δt o + c s max ⋅ Δs s ⋅ p o s (22) PC o wo = c o max ⋅ Δt o ⋅ c o p (23) OC o = Δs s ⋅ c ots (24) SC o wo = d o p 0 ⋅ c o s = max 0, d o -I t o 1 + c o max ⋅ Δt o ⋅ c o s ( 25 ) IC o wo = ⎡ ⎢ ⎢ ⎢ ⎢ ⎣ c o max ⋅ Δr o 1 ⋅ � Δr o 1 2 + Δs o + Δr o 2 � + I � t o 1 � ⋅ Δt o + c o max � Δr o 2 � 2 2 + Δs o ⋅ � c o max + c s max � ⋅ � Δs o 2 + Δr o 2 � ⎤ ⎥ ⎥ ⎥ ⎥ ⎦ ⋅ c o h (26) MC o wo = M o Δt o ⋅ c o r + c o m.
Computational Results and Analysis. In this section, we analysis the results of using the approaches in Section 5 on a series of instances. Computational experiments are implemented in a MacBook Pro using an Intel Core i7 3GHz CPU with 8GB RAM, running macOS High Sierra 10. 13. 3 operating system. Furthermore, all experiments are coded in Matlab R2017b which itself calls YALMIP R20171121 to run through CPLEX 12. 8. 0. For all the instances, one run is conducted for each approach, according to the settings in Section 6. 1. Then all the results are analyzed as follows. First, we compare the results of the SAA and the GA for the stochastic programming problem in Table  1. We consider the instances with two capacity levels  = 2 and with three capacity levels  = 3. In Table  1 , the results of  = 2 are showed from rows 4 to 7.
ACKNOWLEDGEMENTS We would like to thank  Clara Vinh  for editing and translating the article first draft. PAGE 23  Borja de Mozota , B. and Wolff, F. (2019). Forty Years of Research in Design Management: A Review of Literature and Directions for the Future. Strategic Design Research Journal , volume 12, number  01 ,  January -April   2019. 4-26. Doi: 10. 4013/sdrj. 2019. 121. 02A previous version of this paper was published in French in France in the research journal:  Sciences du Design  (Number 7) Special issue on Design Management (Spring 2018). https://www. cairn. info/revue-sciences-du-design-2018-1-page-28. html.
Requirements reuse Requirements Reuse in Requirements Engineering consists in selecting requirements from defined and verified system requirements of a previous project to use them in a new project. It is used to reduce development time & cost and increase the productivity and quality of products. It is particularly useful to help stakeholder rapidly elicit a system's requirements, especially when their knowledge about the current technological possibilities is lacking  (Pacheco et al. , 2015; Toval et al. , 2002). RR methods and technics have been greatly explored in the software domain. The literature about software RR shows that all RR processes are based on the selection of requirements candidates from a requirement database  (Irshad et al. , 2018). Moros et al. (2008)  introduce a method for modelling software requirements for reuse, then modelling new software requirements by reuse.
The requirements for reuse are classified in catalogues while ensuring the traceability and relations between the requirements. In their cases, the catalogues are software functionalities. When such functionalities are needed in new projects, the requirements corresponding to these functionalities are selected for reuse  (Moros et al. , 2008). Prior to functionality identification, stakeholders' needs are the inputs of design processes and RE processes. Other methods in the literature aim at identifying reusable requirements before the analysis and identification of system's functionalities. For instance  Kaiya and Saeki (2006)  map the requirement database with domain ontologies. They match concepts expressed in the stakeholders needs with concepts from the domain ontology to identify missing reusable requirements from system's requirements.
Whether the input for RR is system functionality or stakeholder need, direct reuse of requirements is not always possible. When system functionalities are reused in new contexts and integrated to new system functionalities, the description of their requirements must be adapted. This activity is called requirement recycling. It can be defined as keeping the suitable parameters in the base of the requirement description, adapting the other parameters to the new context and integrating the resulting requirement to the new system's requirements  (Alexander and Kiedaisch, 2002). Few propositions have been made for parameter recycling. Knethen et al. (2002)  propose a systematic process to identify requirement's recycled parameters. For that, they use abstractions of the database requirements in the form of templates.
First and prior to any new ATS R&D project, a database of former projects' system requirements is built. The requirements in the database are modelled for reuse. Second, requirement candidates are semi-automatically selected from the database then reused or recycled. Clients are integrated to the reuse and recycling activity. Third, project specific requirements are elicited with the client and integrated to the reused and recycled requirements. Finally, at the end of the whole requirements engineering process, the final ATS requirement is used to update the requirements database. Maintaining the database for future elicitation processes is one of the RRR challenges  (Toval et al. , 2002).
Through the design process, the ATS functions are defined to satisfy ORs and FRs. More detailed FRs can be derived from these functions and their interactions. FR example: The communication_network must ensure the transfer of the START_command During the design process, designers may have to decide between different solution alternatives to satisfy a system requirement. As stated previously, more detailed system requirements can be derived from each solution. This results in several alternatives of requirement sets that satisfy the system requirement. In the database, we model these requirement alternatives using decision gates. As illustrated in Figure  2 , the decision gate indicates two alternatives to satisfy OR1: FR1 or FR2. During the design process, designer will have to decide between satisfying FR1 or FR2.
Relations between requirements In the 3. 2, we detail the identification of requirement candidates for reuse or recycling. The links between requirements is used for one of the ways to do so. According to Winkler and von Pilgrim, the definition of the traceability links depends on the analyst's interpretation  (Winkler and von Pilgrim, 2010). Same as for requirements types, we identified the most relevant and used requirements links during our industrial observation of ATS R&D projects. In the database we model the following links: "Refine" link: the requirements R1. 1 and R1. 2 refine R1 when R1, being complex, is broken down into smaller and more manageable requirements R1. 1 and R1. 2. "Satisfy" link: The requirement R2 satisfies R1 when R2 is a lower level requirement that has been defined for the system to satisfy R1.
A formal semantic structure The use of a formal semantic structure facilitates the identification of requirements candidates with the little information obtained from the clients. It also conserves requirements consistency while recycling their parameters for database update (cf. 3. 2). In addition, it reduces the expression ambiguity of the requirement's description. To obtain the parameters of the formal semantic structure that would capture the complex aspects of ATS, we based it on a proposal for formal modelling of CPS properties  (Garro et al. , 2016) : What is to be satisfied; When in time that is to be satisfied; Which entity in the system that is to be satisfied; -<source object>: the entity that satisfies the requirement -<Target object>: the entity that is the target of the requirement How well that is to be satisfied.
Requirements reuse & recycling In part 2, Requirements candidates' identification for reusing and recycling was conducted through functionalities, use cases and domain ontologies. In The case of ATS R&D, the lack of information on the client's need and the system's operational context prevent the use of the two first. When browsing the database, the analysis of the requirement's parameters is the only way of identifying potential requirements candidates. In our proposed process, we identify requirements candidates by matching a few key concepts expressed by the stakeholders with the parameters from the formal structure of requirements' descriptions. This step is automated using Natural Language Processing (NLP) and matching concepts. The used technic is out of the scope of this paper and in the remaining of the paper, we consider that we matched key concepts from stakeholders with some of the requirements' parameters.
The requirements containing these parameters are the first set of requirements candidates to be selected. From this set, we use their traceability links to other requirements in the database to retrieve more requirements candidate. Further details about this step come in the next paragraph. The results of the literature review showed that including stakeholders in the requirement reuse and recycle process is more adapted to ATS R&D. However, if the overall candidates' selection results in a considerable number of candidates, it would be complicated and time consuming for the clients and requirements engineers to process each one of them. We propose in this process to prioritize the set of requirements candidates that are proposed to them. With these successive sets, the engineers select with the clients what requirements are relevant for the project.
They form the category C3. We call the process to retrieve C3 requirements frontward traces propagation. C2 and C3 requirements are then successively processed to be either reused, recycled or discarder. Following this reasoning, we propose a tree structure for the requirements candidates' categories. As illustrated in Figure  3 , the root of the tree is the category C1. Each node of the tree has two child nodes: the left child node represents its sub-C2 category and is filled through backward traces propagation on its parent nodes requirements. The right child node represents its sub-C3 category and is filled through frontward traces propagation on its parent nodes requirements. The generation of categories stops when no more requirements candidates are detected in the database.
ICED19 Figure  3 : Candidates Category Tree Figure  4  illustrate an example of the filling of the requirements category tree from a small database of 16 requirements. In his example, FR1 is detected through NLP. For the sake of the example FR8 was supposed to be discarded by the client when proposed. Through this example, we can notice several characteristics of this process. First, all the requirements linked to FR8 where not proposed to be reused or recycled. In addition, FR16 was isolated, thus couldn't be reached by the traceability propagation process. Besides, the decision gate between FR4 and FR5 was conserved to warn the requirements engineer. Later in the project, a decision must be taken to satisfy either FR4 or FR5. Finally, we can notice that once a requirement has been processed in a category, it does never appear in lower level categories, even if it has been discarded.
Database update As stated in the beginning of part 3, the requirement database maintenance for future elicitation processes is one of the RRR challenges  (Toval et al. , 2002). The final sub-process's aim is the update of the database. Throughout the ATS R&D project, the requirement's system evolves drastically. The final version of the system' requirement is used to update the requirements database. For the update, the following steps are automatically applied to the database: Recycled requirements are added to the database with an "evolve to" link from the older version to this new version, New elicited requirements are added to the requirements database with their corresponding links to the recycled requirement, A conflicts analysis is conducted to avoid integrating conflicting requirements to the database.
CASE STUDY To validate our process, we tested this RR process with the autonomous systems team of AKKA Technologies. We built the requirements database from a former project of platooning system design. The platooning system is an ATS composed of a lead vehicle, driven by an operator, and followed by a number of autonomous follower vehicles. The team is developing a platooning system in collaboration with other companies for the integration on a test platform and the development of communication network between the vehicles. From a part of this project, we built a database with 2 NFR, 22 OR and 76 FR and one decision gate. The database's requirement graph is illustrated in Figure  5. The red links represent "refine" links while the green links represent "satisfy" links. Figure  5 : Sample of the platooning system's requirements database graph 3 tests were conducted to validate our process.
For each case, around an hour was taken for the reuse, recycling, and discard analysis. The results are summarised in Table  1 : Use case 1: A new client asks for the R&D of a new platooning system. Some aspects of the operational context were different from the former platooning project, but we used 3 key concepts expressed by the client: "follower_vehicle", "lead_vehicle", and "platoning_system". In this use case, we could retrieve all the requirements from the database. Interestingly, the category C1 contained half of the database. Even for a new project very close to the former one, we could eliminate half of the database from the initial discussion to avoid overwhelming the client. Use case 2: A new client asks for the R&D to automate a vehicle. In its operational context, it should be able to handle an intersection.
Hence we used the following 3 key concepts for candidates' selection: "intersection", "vehicle", and "autonomous". Use case 3: The use case 2 client added new information to the operational context. The vehicle must activate an emergency stop if it encounters an obstacle on its way. Hence, we added two more key concepts and used the following concepts for candidates' selection: "intersection", "vehicle", "autonomous", "obstacle", and "emergency_stop" The results of Table1 show that in an hour and with as little inputs as 3 concepts, we could reuse and recycle up to 44 requirements from a database of 100 requirements. The categorization of the candidates helped the engineers handle the important number of requirements and progressively improved their understanding of the clients' needs. However, we can also notice from the table that using 2 more concepts, in this case, didn't drastically change the number of reused/recycled requirements.
Study design In our model revision initiative, several interrelated components were involved (figure  1 ). First, we derived risk prediction models using individual participant data from 85 prospective cohorts in the Emerging Risk Factors Collaboration (ERFC). 3] [24]  Third, we completed external validation using indi vidual participant data from a further 19 prospective cohorts that did not contribute to the model derivation. Fourth, models were applied to indi vidual participant data from 79 countries collected with the WHO STEPwise Approach to Surveillance (STEPS). 25.
Added value of this study The newly developed risk models involve several features that should confer advantages compared with existing tools. First, they are underpinned by powerful, extensive, and complementary datasets of global relevance. Second, we used comprehensive contemporary estimates of cardiovascular disease incidence and risk factor values to adapt (ie, recalibrate) the risk models to many different populations using a simpler and more generalisable approach than that of previous studies. Third, these models provide estimates for the combined outcome of fatal and non-fatal events. Fourth, they include pragmatic models that do not assume availability of laboratory measurements (eg, serum lipid concentrations) that could be used as part of stepwise approaches to help target laboratory testing in people most likely to benefit from the extra information.
We did not use prospective cohort studies analysed as nested case-control studies. Details of the contributing studies are described in appendix 1 (pp 3-5, 37-38). 4] 30  We included prospective cohort studies in the external validation analysis if they met the following criteria: did not contribute to the model derivation stage, met the same methodological criteria as those described for the cohorts selected from the ERFC for the model derivation stage, and made individual participant data accessible for analysis to investigators in our working group. Studies used for external validation included the following: the Asia Pacific Cohort Studies Collaboration (APCSC),  31  the New Zealand primary care-based PREDICT cardio vascular disease cohort (PREDICT-CVD),  12  the Chinese Multi-Provincial Cohort Study,  32  the Health Checks Ubon Ratchathani Study  33  in Thailand, the Tehran Lipids and Glucose Study,  34  and UK Biobank (appendix 1 p 6).