China
Africa
Explore chapters and articles related to this topic
Cams and Followers
Published in Eric Constans, Karl B. Dyer, Introduction to Mechanism Design, 2018
The term “function handle” is a little cryptic. If you think of a handle as something used to grab onto an object, then a function handle is a way of grabbing a function in order to use it. Basically, the statement above defines a variable called camfunc that can be used to “grab” a function called svaj345. The “@” syntax indicates that svaj345 is a function, and not simply a variable. Any time later in the program that we want to use the svaj345 function we can type cam.camfunc instead, and obtain the same results. This makes the program much easier to use for design – if the user wishes to use a 4-5-6-7 polynomial, for example, she would enter
The Window Program Components
Published in Julio Sanchez, Maria P. Canton, Software Solutions for Engineers and Scientists, 2018
Julio Sanchez, Maria P. Canton
In the context of Windows programming, a handle is a token that represents an item, object, or resource. For example, the following line in the WIN_HELLO program hwnd = CreateWindw (szAppName, …
Missing Data Analysis in Regression
Published in Applied Artificial Intelligence, 2022
C. G. Marcelino, G. M. C. Leite, P. Celes, C. E. Pedreira
Table 2 shows that the mean for the PD was below 3.61% for all the treatment methods. Naive Imputation revealed to be the treatment method with higher PD values and percentiles. It becomes clear that in the majority of cases the difference in the quality of the regression is negligible, suggesting that not knowing how data is missing might not greatly effect the regression outcome. This looks good since oftentimes acknowledging such information is not possible. Which method handles imputation more uniformly is clearly a database-dependent information. Discard Rows performed similar in Compactiv database while the other imputation methods were more diverged. The opposite was observed with Airfoil Wankara regressions differed uniquely among each treatment method, while Abalone and Wine Quality results behaved similar throughout the different methods and missing types.
A Code-Agnostic Driver Application for Coupled Neutronics and Thermal-Hydraulic Simulations
Published in Nuclear Science and Engineering, 2021
Paul K. Romano, Steven P. Hamilton, Ronald O. Rahaman, April Novak, Elia Merzari, Sterling M. Harper, Patrick C. Shriwise, Thomas M. Evans
The NeutronicsDriver class contains only pure virtual methods (indicated by bold italics in Fig. 1) and no data members. The find() method takes an array of coordinates and returns an array of cell “handles” corresponding to each of the coordinates. These handles are opaque objects that are never interpreted directly by the driver. They have meaning only for, and are defined by, the derived classes. At the driver level, they are used merely to uniquely identify a cell when making calls to other methods (such as when it comes time to change the temperature of a cell). Also necessary for initialization is the create_tallies() method, which allows an MC code to set up any tallies needed for obtaining energy deposition in cells that are coupled. A series of methods allows CoupledDriver to get or set the density and temperature for a cell during the simulation as well obtain the volume for a cell. The solve_step() method executes the neutronics code, after which the heat_source() method can provide an array containing energy deposition for each cell. Currently, NeutronicsDriver has two concrete implementations: OpenmcDriver and ShiftDriver. Implementations of these classes for codes using different solution methods (for example, deterministic transport codes) would work in principle as well. However, if a determinstic transport code was being used, the requirements may look quite different; for example, there might be a stronger desire to perform a tight coupling between neutronics and TH, in which case ENRICO would be ill-suited for such an application.
The digital ‘connected’ earth: open technology for providing location-based services on degraded communication environments
Published in International Journal of Digital Earth, 2018
Ramón Piedrafita, Rubén Béjar, Rubén Blasco, Alvaro Marco, F. Javier Zarazaga-Soria
The ‘Framework’ is composed of several components: HTTP server: handles the communications with the rest of the system, i.e. send and receive orders and information to/from the nodes and external customers.The database manager: it handles the appropriate operations of reading and writing the database according to the operations requested by the nodes or customers.Figure 7 shows the server’s data classes diagram. The class Node represents a node of the system with the corresponding attributes and methods. The class Measurement is an abstract class used to encapsulate any type of measure in a node, such as location (Location), energy (Power) or information from a sensor (SensorData). The class Sensor represents possible sensors associated with each of the nodes. At the same time, the sensors have associated measurements of the SensorData class.