127,196 research outputs found

    Automatic linearity detection

    Get PDF
    Given a function, or more generally an operator, the question "Is it linear?" seems simple to answer. In many applications of scientific computing it might be worth determining the answer to this question in an automated way; some functionality, such as operator exponentiation, is only defined for linear operators, and in other problems, time saving is available if it is known that the problem being solved is linear. Linearity detection is closely connected to sparsity detection of Hessians, so for large-scale applications, memory savings can be made if linearity information is known. However, implementing such an automated detection is not as straightforward as one might expect. This paper describes how automatic linearity detection can be implemented in combination with automatic differentiation, both for standard scientific computing software, and within the Chebfun software system. The key ingredients for the method are the observation that linear operators have constant derivatives, and the propagation of two logical vectors, \ell and cc, as computations are carried out. The values of \ell and cc are determined by whether output variables have constant derivatives and constant values with respect to each input variable. The propagation of their values through an evaluation trace of an operator yields the desired information about the linearity of that operator

    Sharing storage using dirty vectors

    Get PDF
    Consider a computation F with n inputs (independent variables) and m outputs (dependent variables) and suppose that we wish to evaluate the Jacobian of F. Automatic differentiation commonly performs this evaluation by associating vector storage either with the program variables (in the case of forward-mode automatic differentiation) or with the adjoint variables (in the case of reverse). Each vector component contains a partial derivative with respect to an independent variable, or a partial derivative of a dependent variable, respectively. The vectors may be full vectors, or they may be dynamically managed sparse data structures. In either case, many of these vectors will be scalar multiples of one another. For example, any intermediate variable produced by a unary operation in the forward mode will have a derivative vector that is a multiple of the derivative for the argument. Any computational graph node that is read just once during its lifetime will have an adjoint vector that is a multiple of the adjoint of the node that reads it. It is frequently wasteful to perform component multiplications explicitly. A scalar multiple of another vector can be replaced by a single multiplicative "scale factor" together with a pointer to the other vector. Automated use of this "dirty vector" technique can save considerable memory management overhead and dramatically reduce the number of floating-point operations required. In particular, dirty vectors often allow shared threads of computation to be reverse-accumulated cheaply. The mechanism permits a number of generalizations, some of which give efficient techniques for preaccumulation

    Superposition as memory: unlocking quantum automatic complexity

    Full text link
    Imagine a lock with two states, "locked" and "unlocked", which may be manipulated using two operations, called 0 and 1. Moreover, the only way to (with certainty) unlock using four operations is to do them in the sequence 0011, i.e., 0n1n0^n1^n where n=2n=2. In this scenario one might think that the lock needs to be in certain further states after each operation, so that there is some memory of what has been done so far. Here we show that this memory can be entirely encoded in superpositions of the two basic states "locked" and "unlocked", where, as dictated by quantum mechanics, the operations are given by unitary matrices. Moreover, we show using the Jordan--Schur lemma that a similar lock is not possible for n=60n=60. We define the semi-classical quantum automatic complexity Qs(x)Q_{s}(x) of a word xx as the infimum in lexicographic order of those pairs of nonnegative integers (n,q)(n,q) such that there is a subgroup GG of the projective unitary group PU(n)(n) with Gq|G|\le q and with U0,U1GU_0,U_1\in G such that, in terms of a standard basis {ek}\{e_k\} and with Uz=kUz(k)U_z=\prod_k U_{z(k)}, we have Uxe1=e2U_x e_1=e_2 and Uye1e2U_y e_1 \ne e_2 for all yxy\ne x with y=x|y|=|x|. We show that QsQ_s is unbounded and not constant for strings of a given length. In particular, Qs(0212)(2,12)<(3,1)Qs(060160) Q_{s}(0^21^2)\le (2,12) < (3,1) \le Q_{s}(0^{60}1^{60}) and Qs(0120)(2,121)Q_s(0^{120})\le (2,121).Comment: Lecture Notes in Computer Science, UCNC (Unconventional Computation and Natural Computation) 201

    First steps towards the certification of an ARM simulator using Compcert

    Get PDF
    The simulation of Systems-on-Chip (SoC) is nowadays a hot topic because, beyond providing many debugging facilities, it allows the development of dedicated software before the hardware is available. Low-consumption CPUs such as ARM play a central role in SoC. However, the effectiveness of simulation depends on the faithfulness of the simulator. To this effect, we propose here to prove significant parts of such a simulator, SimSoC. Basically, on one hand, we develop a Coq formal model of the ARM architecture while on the other hand, we consider a version of the simulator including components written in Compcert-C. Then we prove that the simulation of ARM operations, according to Compcert-C formal semantics, conforms to the expected formal model of ARM. Size issues are partly dealt with using automatic generation of significant parts of the Coq model and of SimSoC from the official textual definition of ARM. However, this is still a long-term project. We report here the current stage of our efforts and discuss in particular the use of Compcert-C in this framework.Comment: First International Conference on Certified Programs and Proofs 7086 (2011
    corecore