New Version Of Code Research Articles

Specification and inference of trace refinement relations

The modern software engineering process is evolutionary, with commits/patches begetting new versions of code, progressing steadily toward improved systems. In recent years, program analysis and verification tools have exploited version-based reasoning, where new code can be seen in terms of how it has changed from the previous version. When considering program versions, refinement seems a natural fit and, in recent decades, researchers have weakened classical notions of concrete refinement and program equivalence to capture similarities as well as differences between programs. For example, Benton, Yang and others have worked on state-based refinement relations . In this paper, we explore a form of weak refinement based on trace relations rather than state relations. The idea begins by partitioning traces of a program C 1 into trace classes, each identified via a restriction r 1 . For each class, we specify similar behavior in the other program C 2 via a separate restriction r 2 on C 2 . Still, these two trace classes may not yet be equivalent so we further permit a weakening via a binary relation A on traces, that allows one to, for instance disregard unimportant events, relate analogous atomic events, etc. We address several challenges that arise. First, we explore one way to specify trace refinement relations by instantiating the framework to Kleene Algebra with Tests (KAT) due to Kozen. We use KAT intersection for restriction, KAT hypotheses for A , KAT inclusion for refinement, and have proved compositionality. Next, we present an algorithm for automatically synthesizing refinement relations, based on a mixture of semantic program abstraction, KAT inclusion, a custom edit-distance algorithm on counterexamples, and case-analysis on nondeterministic branching. We have proved our algorithm to be sound. Finally, we implemented our algorithm as a tool called Knotical, on top of Interproc and Symkat. We demonstrate promising first steps in synthesizing trace refinement relations across a hand-crafted collection of 37 benchmarks that include changing fragments of array programs, models of systems code, and examples inspired by the thttpd and Merecat web servers.

Version 4.0 of code Java for 3D simulation of the CCA model

This paper presents a new version Java code for the three-dimensional simulation of Cluster–Cluster Aggregation (CCA) model to replace the previous version. Many redundant traverses of clusters-list in the program were totally avoided, so that the consumed simulation time is significantly reduced. In order to show the aggregation process in a more intuitive way, we have labeled different clusters with varied colors. Besides, a new function is added for outputting the particle’s coordinates of aggregates in file to benefit coupling our model with other models. New version program summaryProgram Title: CCA v04Program Files doi:http://dx.doi.org10.17632/zwz37tvjny.1Licensing provisions: Apache-2.0Programming language: JavaJournal reference of previous version: Computer Physics Communications 207 (2016) 547–548Does the new version supersede the previous version?: YesNature of problem: The previous program for CCA model can be optimized for yielding better operation efficiency and visualization effects. Besides, it can be extended for coupling with other models by adding some new functions.Solution method: Some redundant traverses of the clusters-list for updating an important variable were removed technically. Furthermore, displaying different clusters with distinct colors can benefit to the effectiveness of visualization. We have also introduced a new function for outputting the aggregated clusters, so that this model can be easily coupled with other models.Reasons for the new version:1. In the previous versions [1–3], the global variable of Dmax, which means the maximum diffusion coefficient of clusters, is supposed to be calculated when aggregation occurs. In fact, this variable is critical to determine whether the currently selected cluster carries out diffusion or not. In the previous version, we had to traverse the clusters-list to update Dmax, even though it may keep unchanged after a round of aggregation. But, we have explored that it is not necessary to traverse all clusters, if we compare the previous variable of Dmax with the diffusion coefficient of the new cluster, which is formed by aggregating two clusters. In the case of the new one is larger, Dmax will be updated to it; otherwise, Dmax keep unchanged. Obviously, removing redundant traverses can enhance algorithm efficiency, and the time complexity of the algorithm is closely related to the loop in it. As a result, the new version of code can greatly cut down the simulation time, in contrast to the previous codes.2. The old versions paint all particles with same color, which does not help to identify different clusters. In order to show the visualization of the 3D aggregate process in different states intuitively, we introduce labeling different clusters with different colors. Consequently, the particles belong to one cluster are painted with the same color.3. A new function is added to record intermediate or final state of clusters so that it can be used for further research when using other relevant models.Summary of revisions:1. Reduce unnecessary traverses of the clusters-list for speeding up simulation.2. Paint clusters with different colors to pursuit better visualization effects.3. Add a new function of exporting the coordinates of clusters to a text file for benefiting other models.Additional comments:To test the optimization effects offered by the new version of code, we have carried out a comparison experimentto measure the simulation time with different initial particles, by using the new and the previous version 3.0 of code. In the experiments, we set concentration C to 0.01, diffusion exponent γ to 0, sticking probability exponent σ to 1, the sticking probability P1 to 0.1, absolute temperature T to 298 K, and the side length L of cube was respectively set to 30, 40, 50, 60, 70 and 80 to yield different initial particles, as the number of particles N can be calculated by the formula N=C∗L3 [1]. To avoid the influences of hardware and software, we use Monte Carlo steps (MCS) as our simulation time [4–6]. As shown in Fig. 1, the slope coefficient caused by this new version of code is about 1.3813, it is close to line complexity, as for the previous version, it is 1.5703, larger than the new one. It is obvious the new one has a faster running speed than the previous one. More importantly, the reduction of simulation time becomes more obvious when the number of simulated particles is getting larger.The changed visualization of our program is shownin Fig. 2. We can clearly see how much clusters in simulation system, and how they distribute. And the button “save” marked red in Fig. 2 can help realize our new function by exporting the particle coordinates to a text file, which also store the related initial conditions.AcknowledgmentsThis work was partially supported by “National Natural Science Foundation of China (Nos. 41271292, 61303038)”.

Chaos Many-Body Engine v03: A new version of code C# for chaos analysis of relativistic many-body systems with reactions

In this paper we present a new version of the Chaos Many-Body Engine C# application (Grossu et al. 2012 [1]). In order to benefit from the latest technological advantages, we migrated the application from .Net Framework 2.0 to .Net Framework 4.0. New tools were implemented also. Trying to estimate the particle interactions dependence on initial conditions, we considered a new distance, which takes into account only the structural differences between two systems. We used this distance for implementing the “Structural Lyapunov” function. We propose also a new precision test based on temporal reversed simulations. New version program summaryProgram title: Chaos Many-Body Engine v03Catalogue identifier: AEGH_v3_0Program summary URL: http://cpc.cs.qub.ac.uk/summaries/AEGH_v3_0.htmlProgram obtainable from: CPC Program Library, Queen’s University, Belfast, N. IrelandLicensing provisions: Standard CPC licence, http://cpc.cs.qub.ac.uk/licence/licence.htmlNo. of lines in distributed program, including test data, etc.: 214429No. of bytes in distributed program, including test data, etc.: 9512380Distribution format: tar.gzProgramming language: Visual C# .Net 2010Computer: PCOperating system: .Net Framework 4.0 running on MS WindowsRAM: 128 MBClassification: 24.60.Lz, 05.45.aCatalogue identifier of previous version: AEGH_v2_0Journal reference of previous version: Computer Physics Communications 183 (2012) 1055–1059Does the new version supersede the previous version?: YesNature of problem: Chaos analysis of three-dimensional, relativistic many-body systems with reactions.Solution method: Second order Runge–Kutta algorithm. Implementation of temporal reversed simulation precision test, and “Structural Lyapunov” function.Reasons for new version:1.In order to benefit from the advantages involved in the latest technologies (e.g. LINQ Queries [2]), Chaos Many-Body Engine was migrated from .Net Framework 2.0 to .Net Framework 4.0.2.In addition to existing energy conservation assessment [3], we propose also a reverse simulation precision test. Thus, for a regular simulation, we considered the corresponding reversed process: initial time equals the end time of regular simulation, and temporal resolution dt<0. One can compare the initial state of the regular system, and the final state of the reversed one (t=0) using, for example, the phase-space distance.3.Trying to measure particle interactions dependence on initial conditions, we considered the following distance, which takes into account only the structure differences between two many-body systems with reactions: (1)ds=∑i=1n(Ni1−Ni2)2 where Ni1 represents the number of particles of type “i” from the first system, and Ni2 is the corresponding number for the second system. We sum over all particle types.Inspired by the Lyapunov Exponent method [4], we implemented the evolution in time of the “Structural Lyapunov” function, for two identical systems with slightly different initial conditions: (2)Ls(t)=lnds(t)ds(0).Summary of revisions:1.Migration from .Net Framework 2.0 to .Net Framework 4.02.Implementation of new chaos analysis tools: a.Reverse simulation precision testb.“Structural Lyapunov” function.Additional comments:1.In [1] we applied the Chaos Many-Body Engine to some nuclear relativistic collisions at 4.5 A GeV/c (SKM 200 collaboration [5,6]). We considered also some first tests on He+He head-on collisions at 1 A TeV/c (choose the Simulation∖Collision menu, and set the appropriate parameters Fig. 1). However, in this case, more complex reaction schemas should be considered. Further investigation on higher energies is currently in progress. [Display omitted] Restrictions: The reverse simulation precision test does not apply for: systems with reactions, parallel simulations, and Monte Carlo simulations.Running time: quadratic complexity.

Developing connection design rules in China

The new version of Code for Design of Steel Structures (GB50017-2003) and other design standards in China were released over the last two years. Comparing with the previous version (GBJ17-88), many clauses covering the connection design have been revised. A number of additional provisions are supplemented to specify the design requirements for beam-column moment connections, as well as gusset plates for truss joints. In this paper, a summary on the design rules on connections specified in the current Chinese code is presented, and relevant commentary and background information is provided whenever appropriate. The design criteria governing weld and bolt resistance is examined and reviewed. Moreover, several issues such as detailing requirements for stiffeners and end-plate connections are discussed.

Solving growth problems in a rapidly expanding PDN (panel session, abstract only)

Tymnet's public data network has been expanding in size and revenues at about a 35% per year rate since its inception. Maintaining this growth has put strain more on the organization than the technology. I will discuss several dimensions of the problem of managing prolonged rapid growth, including capacity management (bandwidth, switching, interfaces, and floor-space), topological complexity, job specialization, order processing, forecasting, and deploying new versions of code. The topic selection will favor issues that are likely to be common to other operations and the discussion will be biased toward solutions and pro-active management.