DOCSLIB.ORG

Fast Floating-Point Processing in Common Lisp

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fast Floating-Point Processing in Common Lisp Fast FloatingPoint Pro cessing in Common Lisp RICHARD J FATEMAN UniversityofCalifornia Berkeley and KEVIN A BROUGHAN and DIANE K WILLCOCK UniversityofWaikato and DUANE RETTIG Franz Inc Lisp one of the oldest higherlevel programming languages has rarely b een used for fast numerical oatingp oint computationWe explore the b enets of Common Lisp an emerging new language standard with some excellent implementations for numerical computation We compare it to Fortran in terms of the sp eed of eciency of generated co de as well as the structure and convenience of the language There are a surprising number of advantages to Lisp esp ecially in cases where a mixture of symbolic and numeric pro cessing is needed Categories and Sub ject Descriptors G Mathematics of Computing Mathematical Software eciency portability D Programming Languages Pro cessorscompilers interpreters optimization General terms Common Lisp Fortran C Floatingp oint arithmetic Additional Key Words and Phrases Compiler optimization Symb olic computation Numerical algorithms INTRODUCTION The combination of symbolic and numeric computation has b ecome p opular in sev eral application areas These include for example motion planning for rob otics signal pro cessing and image understanding One burgeoning area is the develop mentofscientic computing environments including symb olic mathematics sys tems numerical computing and graphics These tend to mix traditional strengths of the Lisp programming language interactivity and symb ol manipulation with the additional need for numerics In general mathematical mo deling of complex physical phenomena includes a symb olic manipulation phase of mo del formulation followed byanumerical solu tion phase and output visualization Mo del formulation has traditionally b een a Authors addresses Richard J Fateman Computer Science Division University of California Berkeley CA USA Kevin A Broughan and Diane K Willco ck Dept of Mathematics and Statistics UniversityofWaikato Private Bag Hamilton NZ Duane Rettig Franz Inc UniversityAve Berkeley CA USA email fate manp eoplesparcBerkeleyedu kabwaikatoacnz duanefranzcom Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage the ACM copyright notice and the title of the publication and its date app ear and notice is given that copying is by p ermission of the Asso ciation for Computing MachineryTo copy otherwise or to republish requires a fee andor sp ecic p ermission R J Fateman et al p encilandpap er activity but in recentyears computer algebra systems haveas sisted in analysis and subsequentFortran co de generation for numerical compu tation Since dierent languages are b eing used for the analysis and nal execution this approach precludes the development of algorithms which use mixed symb olic numeric pro cessing at a deep er level A b etter arrangmentwould allow the analysis and execution phases to exist simultaneouslyallowing eachtointeract with the other Still even if the symb olic and numeric phases coexist as a practical mat ter errors or exceptional conditions on one side of the software b oundary tend to b e dealt with inconveniently on the other side suchevents include oatingp oint exceptions keyb oard or mousegenerated interrupts op erating system actions and storagereclamation pro cessing garbage collection in Lisp A b etter metho d of joining the two kinds of pro cessing without descending to lowlevel implementation co ding would b e useful For some time now the need for a symb olicnumeric mixture has b een well recognized by designers of computer algebra systems Sometimes this need is met entirely in the Lisp system environmentby writing in Lisp Sometimes the numeric or graphical routines are loaded from a standard library or written in advance using CorFortran but integrated at compile or load time with the computer algebra system Sometimes the need for numerical co de is only satised by pro ducing on the y Fortran sourceco de compiling and loading it backinto Lisp This last approach tends to b e delicate but several systems have b een built around the use of symb olic systems to help co de Fortran subroutines which are then t into templates of other Fortran co de to pro duce complete packages Some recen twork includes work by Wirth Lanam Wang Broughan Co ok and Ka jler As a principal example of the approach of linking Lisp programs with numerics consider the developmentofsymb olicnumeric algorithms for the Senac environ ment under way at the UniversityofWaikato New Zealand Mathematical Soft ware Pro ject The goal of this development has b een to combine computer algebra languages with numeric and graphic subroutine libraries The combination has until recently b een achieved using Lispbased algebra languages combined with Fortranbased numeric and graphics co de The linking of these systems has of ten employed Lisp foreign function interfaces to C and Fortranlanguage co de Such links to foreign functions are included in a numb er of mo dern Lisp systems although the linkage sp ecication syntax is not yet standardized Another technique sometimes used is to set up interpro cess communication IPC between dierent pro cesses The IPC may in fact link programs running on dierent computers Either technique provides an alternative to the traditional concept of the users explicit editing of symb olic mathematical text into a numeric source program although the IPC technique is even less likely to b e robust in the face of errors than the foreignfunction linkage Using b oth of these metho ds the Waikato group has written a number of in terfaces Naglink was written b etween Macsyma and the NAG Library Numlink between Senac and Graink and the NAG Fortran Library and Graphics Library These references describ e howcomponents have b een integrated to provide a very highly automated problemsolving environment combining symb olic numeric and graphic to ols As exp ected the approaches retain the eciency and robustness of Fast FloatingPoint Pro cessing in Common Lisp the Fortran co de They automate using interface programs written in Lisp the calling and return pro cesses and userwritten subroutines demanded bysome Fortran packages eg numerical integration minimization can in fact b e written by Senac rather than the user An additional b enet of the Senac approachisthat the user need not attend to the tedious requirements to provide output formatting In spite of success in researchenvironments there have b een obstacles to the widespread propagation and generalization of these concepts They include The lack of a language standard for foreign function interfaces in Common Lisp Standardization on this topic is arguably to o dicult or controversial to hold out much exp ectation for a standard so on The low standard of maintenance of implementation dep endent foreign func tion interfaces and linkers in general by language and op erating system or hardware vendors The Waikato exp erience has b een that of grappling with a succession of serious bugs Lack of compatibilitybetween libraries for dierent language compilers and between ob jectco de formats for the same compiler at dierent revision levels This diversity has created a degree of insecurity for this and other comp osite language environment develop ers Op erating system defects Wecontinue to see ma jor computer corp orations releasing versions of their op erating systems for highsp eed workstations with no provision for dynamic linking In this pap er we explore an approachwhich enables all of the problems listed ab ovetobesolved at a single stroke use Lisp as the source language for the numeric and graphical co de This is not a new idea it was tried at MIT and UCB in the s While these exp eriments were mo destly successful the particular systems are obsolete Fortunately some of those ideas used in Maclisp NIL andFranz Lisp were incorp orated in the subsequent standardization of Common Lisp CL In this new setting it is appropriate to reexamine the theoretical and practical implications of writing numeric co de in Lisp The p opular conceptions of Lisps ineciency for numerics have b een based on rumor supp osition and exp erience with early and in fact inecient implemen tations It is certainly p ossible to continue to write inecient programs As one example of the results of deemphasizing numerics in the design consider the situ ation of the basic arithmetic op erators The denitions of these functions require that they are generic eg must b e able to add anycombination of several pre cisions of oats arbitraryprecision integers rational numb ers and complexes The very simple way of implementing this arithmetic b y subroutine calls is also v ery inecient Even with appropriate declarations to enable more sp ecic treatmentof numeric typ es compilers are free to ignore declarations and such implementations naturally do not accommo date the needs of intensivenumb ercrunching See the app endix for further discussion of declarations Be this as it may the situation with resp ect to Lisp has changed for the b etter in recentyears With the advent of ANSI standard Common Lisp several active vendors of implementations and one active university research group Carnegie Mel lon there has b een a signicantimprovement in the quality and eciency of the R J Fateman et al numeric facilities available in Lisp systems Based on our exp erience rep orted in part in this pap er we exp ect that co de from Common Lisp compilers can demon strate
Load more

Recommended publications
  • The Sagemanifolds Project
    Tensor calculus with free softwares: the SageManifolds project Eric´ Gourgoulhon1, Micha l Bejger2 1Laboratoire Univers et Th´eories (LUTH) CNRS / Observatoire de Paris / Universit´eParis Diderot 92190 Meudon, France http://luth.obspm.fr/~luthier/gourgoulhon/ 2Centrum Astronomiczne im. M. Kopernika (CAMK) Warsaw, Poland http://users.camk.edu.pl/bejger/ Encuentros Relativistas Espa~noles2014 Valencia 1-5 September 2014 Eric´ Gourgoulhon, Micha l Bejger (LUTH, CAMK) SageManifolds ERE2014, Valencia, 2 Sept. 2014 1 / 44 Outline 1 Differential geometry and tensor calculus on a computer 2 Sage: a free mathematics software 3 The SageManifolds project 4 SageManifolds at work: the Mars-Simon tensor example 5 Conclusion and perspectives Eric´ Gourgoulhon, Micha l Bejger (LUTH, CAMK) SageManifolds ERE2014, Valencia, 2 Sept. 2014 2 / 44 Differential geometry and tensor calculus on a computer Outline 1 Differential geometry and tensor calculus on a computer 2 Sage: a free mathematics software 3 The SageManifolds project 4 SageManifolds at work: the Mars-Simon tensor example 5 Conclusion and perspectives Eric´ Gourgoulhon, Micha l Bejger (LUTH, CAMK) SageManifolds ERE2014, Valencia, 2 Sept. 2014 3 / 44 In 1969, during his PhD under Pirani supervision at King's College, Ray d'Inverno wrote ALAM (Atlas Lisp Algebraic Manipulator) and used it to compute the Riemann tensor of Bondi metric. The original calculations took Bondi and his collaborators 6 months to go. The computation with ALAM took 4 minutes and yield to the discovery of 6 errors in the original paper [J.E.F. Skea, Applications of SHEEP (1994)] In the early 1970's, ALAM was rewritten in the LISP programming language, thereby becoming machine independent and renamed LAM The descendant of LAM, called SHEEP (!), was initiated in 1977 by Inge Frick Since then, many softwares for tensor calculus have been developed..
    [Show full text]
  • Using Macaulay2 Effectively in Practice
    Using Macaulay2 effectively in practice Mike Stillman ([email protected]) Department of Mathematics Cornell 22 July 2019 / IMA Sage/M2 Macaulay2: at a glance Project started in 1993, Dan Grayson and Mike Stillman. Open source. Key computations: Gr¨obnerbases, free resolutions, Hilbert functions and applications of these. Rings, Modules and Chain Complexes are first class objects. Language which is comfortable for mathematicians, yet powerful, expressive, and fun to program in. Now a community project Journal of Software for Algebra and Geometry (started in 2009. Now we handle: Macaulay2, Singular, Gap, Cocoa) (original editors: Greg Smith, Amelia Taylor). Strong community: including about 2 workshops per year. User contributed packages (about 200 so far). Each has doc and tests, is tested every night, and is distributed with M2. Lots of activity Over 2000 math papers refer to Macaulay2. History: 1976-1978 (My undergrad years at Urbana) E. Graham Evans: asked me to write a program to compute syzygies, from Hilbert's algorithm from 1890. Really didn't work on computers of the day (probably might still be an issue!). Instead: Did computation degree by degree, no finishing condition. Used Buchsbaum-Eisenbud \What makes a complex exact" (by hand!) to see if the resulting complex was exact. Winfried Bruns was there too. Very exciting time. History: 1978-1983 (My grad years, with Dave Bayer, at Harvard) History: 1978-1983 (My grad years, with Dave Bayer, at Harvard) I tried to do \real mathematics" but Dave Bayer (basically) rediscovered Groebner bases, and saw that they gave an algorithm for computing all syzygies. I got excited, dropped what I was doing, and we programmed (in Pascal), in less than one week, the first version of what would be Macaulay.
    [Show full text]
  • Writing Fast Fortran Routines for Python
    Writing fast Fortran routines for Python Table of contents Table of contents ............................................................................................................................ 1 Overview ......................................................................................................................................... 2 Installation ...................................................................................................................................... 2 Basic Fortran programming ............................................................................................................ 3 A Fortran case study ....................................................................................................................... 8 Maximizing computational efficiency in Fortran code ................................................................. 12 Multiple functions in each Fortran file ......................................................................................... 14 Compiling and debugging ............................................................................................................ 15 Preparing code for f2py ................................................................................................................ 16 Running f2py ................................................................................................................................. 17 Help with f2py ..............................................................................................................................
    [Show full text]
  • High-Level Language Features Not Found in Ordinary LISP. the GLISP
    DOCUMENT RESUME ED 232 860 SE 042 634 AUTHOR Novak, Gordon S., Jr. TITLE GLISP User's Manual. Revised. INSTITUTION Stanford Univ., Calif. Dept. of Computer Science. SPONS AGENCY Advanced Research Projects Agency (DOD), Washington, D.C.; National Science Foundation, Washington, D.C. PUB DATE 23 Nov 82 CONTRACT MDA-903-80-c-007 GRANT SED-7912803 NOTE 43p.; For related documents, see SE 042 630-635. PUB TYPE Guides General (050) Reference Materials General (130) EDRS PRICE MF01/PCO2 Plus Postage. DESCRIPTORS *Computer Programs; *Computer Science; Guides; *Programing; *Programing Languages; *Resource Materials IDENTIFIERS *GLISP Programing Language; National Science Foundation ABSTRACT GLISP is a LISP-based language which provides high-level language features not found in ordinary LISP. The GLISP language is implemented by means of a compiler which accepts GLISP as input and produces ordinary LISP as output. This output can be further compiled to machine code by the LISP compiler. GLISP is available for several ISP dialects, including Interlisp, Maclisp, UCI Lisp, ELISP, Franz Lisp, and Portable Standard Lisp. The goal of GLISP is to allow structured objects to be referenced in a convenient, succinct language and to allow the structures of objects to be changed without changing the code which references the objects. GLISP provides both PASCAL-like and English-like syntaxes; much of the power and brevity of GLISP derive from the compiler features necessary to support the relatively informal, English-like language constructs. Provided in this manual is the documentation necessary for using GLISP. The documentation is presented in the following sections: introduction; object descriptions; reference to objects; GLISP program syntax; messages; context rules and reference; GLISP and knowledge representation languages; obtaining and using GLISP; GLISP hacks (some ways of doing things in GLISP which might not be entirely obvious at first glance); and examples of GLISP object declarations and programs.
    [Show full text]
  • View of XML Technology
    AN APPLICATION OF EXTENSlBLE MARKUP LANGUAGE FOR INTEGRATION OF KNOWLEDGE-BASED SYSTEM WITH JAVA APPLICATIONS A Thesis Presented to The Faculty of the Fritz J. and Dolores H. Russ College of Engineering and Technology Ohio University In Partial Fulfillment of the Requirement for the Degree Master of Science BY Sachin Jain November, 2002 ACKNOWLEDGEMENTS It is a pleasure to thank the many people who made this thesis possible. My sincere gratitude to my thesis advisor, Dr. DuSan Sormaz, who helped and guided me towards implementing the ideas presented in this thesis. His dedication to research and his effort in the development of my thesis was an inspiration throughout this work. The thesis would not be successful without other members of my committee, Dr. David Koonce and Dr. Constantinos Vassiliadis. Special thanks to them for their substantial help and suggestions during the development of this thesis. I would like also to thank Dr. Dale Masel for his class on guidelines for how to write thesis. Thanlts to my fellow colleagues and members of the lMPlanner Group, Sridharan Thiruppalli, Jaikumar Arumugam and Prashant Borse for their excellent cooperation and suggestions. A lot of infom~ation~1sef~11 to the work was found via the World Wide Web; 1 thank those who made their material available on the Web and those who kindly responded back to my questions over the news-groups. Finally, it has been pleasure to pursue graduate studies at IMSE department at Ohio University, an unique place that has provided me with great exposures to intricacies underlying development, prograrn~ningand integration of different industrial systems; thus making this thesis posslbie.
    [Show full text]
  • An Implementation of Python for Racket
    An Implementation of Python for Racket Pedro Palma Ramos António Menezes Leitão INESC-ID, Instituto Superior Técnico, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Universidade de Lisboa Rua Alves Redol 9 Rua Alves Redol 9 Lisboa, Portugal Lisboa, Portugal [email protected] [email protected] ABSTRACT Keywords Racket is a descendent of Scheme that is widely used as a Python; Racket; Language implementations; Compilers first language for teaching computer science. To this end, Racket provides DrRacket, a simple but pedagogic IDE. On the other hand, Python is becoming increasingly popular 1. INTRODUCTION in a variety of areas, most notably among novice program- The Racket programming language is a descendent of Scheme, mers. This paper presents an implementation of Python a language that is well-known for its use in introductory for Racket which allows programmers to use DrRacket with programming courses. Racket comes with DrRacket, a ped- Python code, as well as adding Python support for other Dr- agogic IDE [2], used in many schools around the world, as Racket based tools. Our implementation also allows Racket it provides a simple and straightforward interface aimed at programs to take advantage of Python libraries, thus signif- inexperienced programmers. Racket provides different lan- icantly enlarging the number of usable libraries in Racket. guage levels, each one supporting more advanced features, that are used in different phases of the courses, allowing Our proposed solution involves compiling Python code into students to benefit from a smoother learning curve. Fur- semantically equivalent Racket source code. For the run- thermore, Racket and DrRacket support the development of time implementation, we present two different strategies: additional programming languages [13].
    [Show full text]
  • Bringing GNU Emacs to Native Code
    Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
    [Show full text]
  • The Java® Language Specification Java SE 8 Edition
    The Java® Language Specification Java SE 8 Edition James Gosling Bill Joy Guy Steele Gilad Bracha Alex Buckley 2015-02-13 Specification: JSR-337 Java® SE 8 Release Contents ("Specification") Version: 8 Status: Maintenance Release Release: March 2015 Copyright © 1997, 2015, Oracle America, Inc. and/or its affiliates. 500 Oracle Parkway, Redwood City, California 94065, U.S.A. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. The Specification provided herein is provided to you only under the Limited License Grant included herein as Appendix A. Please see Appendix A, Limited License Grant. To Maurizio, with deepest thanks. Table of Contents Preface to the Java SE 8 Edition xix 1 Introduction 1 1.1 Organization of the Specification 2 1.2 Example Programs 6 1.3 Notation 6 1.4 Relationship to Predefined Classes and Interfaces 7 1.5 Feedback 7 1.6 References 7 2 Grammars 9 2.1 Context-Free Grammars 9 2.2 The Lexical Grammar 9 2.3 The Syntactic Grammar 10 2.4 Grammar Notation 10 3 Lexical Structure 15 3.1 Unicode 15 3.2 Lexical Translations 16 3.3 Unicode Escapes 17 3.4 Line Terminators 19 3.5 Input Elements and Tokens 19 3.6 White Space 20 3.7 Comments 21 3.8 Identifiers 22 3.9 Keywords 24 3.10 Literals 24 3.10.1 Integer Literals 25 3.10.2 Floating-Point Literals 31 3.10.3 Boolean Literals 34 3.10.4 Character Literals 34 3.10.5 String Literals 35 3.10.6 Escape Sequences for Character and String Literals 37 3.10.7 The Null Literal 38 3.11 Separators
    [Show full text]
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)
    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
    [Show full text]
  • Practical Semantic Web and Linked Data Applications
    Practical Semantic Web and Linked Data Applications Common Lisp Edition Uses the Free Editions of Franz Common Lisp and AllegroGraph Mark Watson Copyright 2010 Mark Watson. All rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works Version 3.0 United States License. November 3, 2010 Contents Preface xi 1. Getting started . xi 2. Portable Common Lisp Code Book Examples . xii 3. Using the Common Lisp ASDF Package Manager . xii 4. Information on the Companion Edition to this Book that Covers Java and JVM Languages . xiii 5. AllegroGraph . xiii 6. Software License for Example Code in this Book . xiv 1. Introduction 1 1.1. Who is this Book Written For? . 1 1.2. Why a PDF Copy of this Book is Available Free on the Web . 3 1.3. Book Software . 3 1.4. Why Graph Data Representations are Better than the Relational Database Model for Dealing with Rapidly Changing Data Requirements . 4 1.5. What if You Use Other Programming Languages Other Than Lisp? . 4 2. AllegroGraph Embedded Lisp Quick Start 7 2.1. Starting AllegroGraph . 7 2.2. Working with RDF Data Stores . 8 2.2.1. Creating Repositories . 9 2.2.2. AllegroGraph Lisp Reader Support for RDF . 10 2.2.3. Adding Triples . 10 2.2.4. Fetching Triples by ID . 11 2.2.5. Printing Triples . 11 2.2.6. Using Cursors to Iterate Through Query Results . 13 2.2.7. Saving Triple Stores to Disk as XML, N-Triples, and N3 . 14 2.3. AllegroGraph’s Extensions to RDF .
    [Show full text]
  • Scope in Fortran 90
    Scope in Fortran 90 The scope of objects (variables, named constants, subprograms) within a program is the portion of the program in which the object is visible (can be use and, if it is a variable, modified). It is important to understand the scope of objects not only so that we know where to define an object we wish to use, but also what portion of a program unit is effected when, for example, a variable is changed, and, what errors might occur when using identifiers declared in other program sections. Objects declared in a program unit (a main program section, module, or external subprogram) are visible throughout that program unit, including any internal subprograms it hosts. Such objects are said to be global. Objects are not visible between program units. This is illustrated in Figure 1. Figure 1: The figure shows three program units. Main program unit Main is a host to the internal function F1. The module program unit Mod is a host to internal function F2. The external subroutine Sub hosts internal function F3. Objects declared inside a program unit are global; they are visible anywhere in the program unit including in any internal subprograms that it hosts. Objects in one program unit are not visible in another program unit, for example variable X and function F3 are not visible to the module program unit Mod. Objects in the module Mod can be imported to the main program section via the USE statement, see later in this section. Data declared in an internal subprogram is only visible to that subprogram; i.e.
    [Show full text]
  • Singular Value Decomposition and Its Numerical Computations
    Singular Value Decomposition and its numerical computations Wen Zhang, Anastasios Arvanitis and Asif Al-Rasheed ABSTRACT The Singular Value Decomposition (SVD) is widely used in many engineering fields. Due to the important role that the SVD plays in real-time computations, we try to study its numerical characteristics and implement the numerical methods for calculating it. Generally speaking, there are two approaches to get the SVD of a matrix, i.e., direct method and indirect method. The first one is to transform the original matrix to a bidiagonal matrix and then compute the SVD of this resulting matrix. The second method is to obtain the SVD through the eigen pairs of another square matrix. In this project, we implement these two kinds of methods and develop the combined methods for computing the SVD. Finally we compare these methods with the built-in function in Matlab (svd) regarding timings and accuracy. 1. INTRODUCTION The singular value decomposition is a factorization of a real or complex matrix and it is used in many applications. Let A be a real or a complex matrix with m by n dimension. Then the SVD of A is: where is an m by m orthogonal matrix, Σ is an m by n rectangular diagonal matrix and is the transpose of n ä n matrix. The diagonal entries of Σ are known as the singular values of A. The m columns of U and the n columns of V are called the left singular vectors and right singular vectors of A, respectively. Both U and V are orthogonal matrices.
    [Show full text]