human: Given a node-centered hypergraph: <hypergraph>, where nodes represent papers and hyperedges represent sets of papers co-cited by a source paper.

Details of the hypergraph:
Center node: "an approach to static performance guarantees for programs with run time checks"
  Abstract: Instrumenting programs for performing run-time checking of properties, such as regular shapes, is#R##N#a common and useful technique that helps programmers detect incorrect program behaviors. This#R##N#is specially true in dynamic languages such as Prolog. However, such run-time checks inevitably#R##N#introduce run-time overhead (in execution time, memory, energy, etc.). Several approaches have#R##N#been proposed for reducing such overhead, such as eliminating the checks that can statically#R##N#be proved to always succeed, and/or optimizing the way in which the (remaining) checks are#R##N#performed. However, there are cases in which it is not possible to remove all checks statically (e.g.,#R##N#open libraries which must check their interfaces, complex properties, unknown code, etc.) and in#R##N#which, even after optimizations, these remaining checks still may introduce an unacceptable level of#R##N#overhead. It is thus important for programmers to be able to determine the additional cost due to#R##N#the run-time checks and compare it to some notion of admissible cost. The common practice used#R##N#for estimating run-time checking overhead is profiling, which is not exhaustive by nature. Instead,#R##N#we propose a method that uses static analysis to estimate such overhead, with the advantage that#R##N#the estimations are functions parameterized by input data sizes. Unlike profiling, this approach#R##N#can provide guarantees for all possible execution traces, and allows assessing how the overhead#R##N#grows as the size of the input grows. Our method also extends an existing assertion verification#R##N#framework to express “admissible” overheads, and statically and automatically checks whether#R##N#the instrumented program conforms with such specifications. Finally, we present an experimental#R##N#evaluation of our approach that suggests that our method is feasible and promising.

Question: Please tell me which class the center node belongs to. The 40 classes are: cs.NA(Numerical Analysis), cs.MM(Multimedia), cs.LO(Logic in Computer Science), cs.CY(Computers and Society), cs.CR(Cryptography and Security), cs.DC(Distributed, Parallel, and Cluster Computing), cs.HC(Human-Computer Interaction), cs.CE(Computational Engineering, Finance, and Science), cs.NI(Networking and Internet Architecture), cs.CC(Computational Complexity), cs.AI(Artificial Intelligence), cs.MA(Multiagent Systems), cs.GL(General Literature), cs.NE(Neural and Evolutionary Computing), cs.SC(Symbolic Computation), cs.AR(Hardware Architecture), cs.CV(Computer Vision and Pattern Recognition), cs.GR(Graphics), cs.ET(Emerging Technologies), cs.SY(Systems and Control), cs.CG(Computational Geometry), cs.OH(Other Computer Science), cs.PL(Programming Languages), cs.SE(Software Engineering), cs.LG(Machine Learning), cs.SD(Sound), cs.SI(Social and Information Networks), cs.RO(Robotics), cs.IT(Information Theory), cs.PF(Performance), cs.CL(Computation and Language), cs.IR(Information Retrieval), cs.MS(Mathematical Software), cs.FL(Formal Languages and Automata Theory), cs.DS(Data Structures and Algorithms), cs.OS(Operating Systems), cs.GT(Computer Science and Game Theory), cs.DB(Databases), cs.DL(Digital Libraries), cs.DM(Discrete Mathematics). Directly output the class name.

gpt: cs.PL(Programming Languages)