Your SlideShare is downloading. ×
  • Like
  • Save
Object Oriented Programming Implementation of Scalar, Vector, and Tensor Variables for 1 to 3D calculations: Comparison Between Polymorphic and Template Based Models (2006)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Object Oriented Programming Implementation of Scalar, Vector, and Tensor Variables for 1 to 3D calculations: Comparison Between Polymorphic and Template Based Models (2006)

  • 1,157 views
Published

Final year BSc honours project. …

Final year BSc honours project.
Please contact me for soft copy if interested.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,157
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Scalar,Object Oriented Programming Implementation of Scalar, Vector, Tensor Variables calculations: and Tensor Variables for 1 to 3D calculations: Comparison Between Polymorphic and Template Based Models Between Models by Lune Gene Yeo 3rd Year Undergraduate, Department of Earth Science and Engineering, Imperial CollegeA Project Submitted in Fulfillment for the Module 4.09 Independent Project as Partial Fulfillment for the Degree of BSC COMPUTATIONAL GEOSCIENCE Dr. Stephan Matthai, Supervisor (Department of Earth Science and Engineering) ©Lune Gene Yeo, 2006 Imperial College London Submitted on the 19th of February 2007
  • 2. Lune Gene YeoAbstractPolymorphism is a vital facet of the object oriented programming paradigm. There arefive kinds of polymorphism recognized in computer code, two of which are dynamicpolymorphism and static polymorphism, which contrast each other in function binding.Dynamic polymorphism utilizes late binding, while static polymorphism uses earlybinding. In the case of scalar, vector and tensor variables for 1D to 3D calculations in theComplex Systems Platform 5.0 library, a static polymorphic (template) model usingindividual template classes is in place. This model, however, has issues ofinteroperability between the different classes of objects. A dynamic polymorphic modelwas written as an alternative to the first model in an attempt to resolve theaforementioned issues. Results of speed benchmarking and storage comparison testsshow that the processes involving the objects from the dynamic polymorphic model runat a slower speed compared to the template model, but both show no difference in storagespace required. The properties of the dynamic polymorphic model thus provide an answerto the interoperability issues of the template model at the cost of runtime speed. There are,however, alternative approaches to solving these issues apart from the dynamicpolymorphic model written. In retrospect, the reusability of the dynamic polymorphicmodel has significant implications for software maintenance in the object orientedprogramming archetype due to its reusability.KeywordsCSP, modeling, geological systems, C++, programming, scalar, vector, tensor,polymorphism, templates, static, dynamic, object orientedObject Oriented Programming Implementation of Scalar, Vector, andTensor Variables for 1 to 3D Calculations
  • 3. Lune Gene YeoTable of ContentsINTRODUCTION………………………………………………………………..1 Literature review…………………………………………………….……1 Claim.……………………………………………………………….…….4 Agenda…………………………………………………….……...............4METHODS………………………………………………………………….……5 Software Engineering………………………………………………….…5 Variable Class Suites………………………………………………….….6 Guide to Test Programs………………………………………………….10RESULTS………………………………………………………………………..12 Speed Benchmarking…………………………………………………….12 Storage Requirement Comparisons………………………………………15DISCUSSION……………………………………………………………………17 Interoperability Issues: A Solution …………………………………...….17 Interoperability versus Speed versus Storage Requirements………..……21 Limitations of the Models Tested ……………………………….….……23 Implications for Object Oriented Programming……………………..…...25CONCLUSIONS…………………………………………………………..……..27ACKNOWLEDGEMENTS……………………………………………….…...…28LIST OF REFERENCES………………………………………………..…….….29LISTS OF TABLES AND FIGURES…………………………………….…...….31APPENDIX……………………………………………………………….…...….33Object Oriented Programming Implementation of Scalar, Vector, andTensor Variables for 1 to 3D Calculations
  • 4. Lune Gene YeoIntroductionLiterature ReviewWhat is polymorphism?Polymorphism (in Ancient Greek, poly means “many” and “morph” means form), whendefined in non-software terms, literally means the ability to assume many forms.Polymorphism in computer code was first identified by Christopher Strachey, a Britishcomputer scientist in his 1967 book Fundamental Concepts of Programming Languages(Campbell-Kelly, 1985, p. 19-42). In the object oriented programming paradigm,polymorphism is described as a feature in which the behavior of a class may be reused inthe definition of new classes, according to a paper entitled Concepts and Paradigms ofObject-Oriented Programming by Wegner (1990, p. 10).In their paper, A Proposal for Harmonising Types, Inheritance and Polymorphism ForObject-Oriented Programming, Simons and Cowling (1992, p.16-17) classifypolymorphism into 5 kinds: universal polymorphism, bounded polymorphism, universalconstruction, bounded construction and arbitrary union. In this project, implementationsof two of these kinds are explored and compared, namely bounded polymorphism, alsoknown as dynamic polymorphism (this is the term that will be used throughout the restof the this report) and universal construction, also known as parametric polymorphism orstatic polymorphism.Dynamic polymorphism versus static polymorphismWhen we talk of basic polymorphism, the first assumption would be that we are referringto dynamic polymorphism based on inheritance (Gunther and Mitchell, 1994, p. 497)where several subclasses are connected through a base class through a hierarchicalorganization of classes; as opposed to static polymorphism which is defined asprogramming using templates (Vandevoorde and Josuttis, 2006, p.240).A classic example of dynamic polymorphism in application would be a generic classShape which is inherited by a group of classes: Circle, Square and Triangle. These classesare blueprints for objects representing geometric shapes (Eckel, 2000, p. 39-41) as shownin Figure 1.1. The class Shape declares the common operations and properties for theCircle, Square and Triangle classes: these common operations and properties are definedObject Oriented Programming Implementation of Scalar, Vector, and 1Tensor Variables for 1 to 3D Calculations
  • 5. Lune Gene Yeoin the individual subclasses themselves. In the base class, common operations are usuallydeclared and defined as virtual functions. Thus, dynamic polymorphism is effectivelyprogramming with virtual functions, also thought of as object oriented programming(Vandevoorde and Josuttis, 2006, p. 240).Static polymorphism, when practically applied, is followed by the notion of genericprogramming which is utilized in the C++ programming language through templates(Vandevoorde and Josuttis, 2006, p. 240); where instead of factoring common behaviourin base classes, the objects from different classes in an application must supportoperations using a common syntax. The different concrete classes are definedindependently form each other. This version of polymorphism defines the intra-classnature of each of the Complex Systems Platform (CSP) 5.0 variable classes (see Figure1.2).Binding: Early or Late?One question, however, arises when attempting to treat derived object types as theirgeneric base types. If a function of the same name is called while ignoring the specific(derived) type, how will the right behaviour occur? There are two paths to an answer:through static polymorphism, using early binding; or through dynamic polymorphismusing late binding. In early (static) binding, the compiler generates a call to a specificfunction name, and the linker resolves this call to the absolute address of the code to beexecuted; all of which is done during compile time. In late (dynamic) binding, the codebeing called is not determined until runtime (Eckel, 2000, p. 37-38).Object Oriented Programming Implementation of Scalar, Vector, and 2Tensor Variables for 1 to 3D Calculations
  • 6. Lune Gene YeoComplex Systems Platform (CSP) 5.0 VariablesThe Complex Systems Platform (CSP) 5.0 is a C++ language based library used for themodeling of geological processes and their interactions, invented by S.K. Matthai incollaboration with S. G. Roberts (ANU), and Sebastian Geiger (ETH) for the PC,Macintosh and UNIX workstations (Matthai, Geiger and Roberts, 2004, p. 1).The CSP variable classes comprise of a ScalarVariable, a VectorVariable and a TensorVariable template (see Figure 1.2): VectorVariable and TensorVariable have 1, 2 and 3Dtemplate specializations which store different types of data (e.g.: float, integer, double)for the purpose of calculations. Each value is tagged with a flag which specifies the datasource of usage of this instance of the class. These classes are not connected to each otherthrough a base class or a template equivalent of a base class.The Problems and Possible SolutionsThere is a key issue that arises from the type differences between the individual CSPscalar, vector and tensor variable static polymorphic template classes as they are declaredand defined individually from each other. This is the lack of interoperability betweeninstances of the scalar, vector and tensor classes due to the type differences of thevariables which are not derived from a common base class.Therefore one always has to write if statements like:if ( scalar )...else if ( tensor )...Another qualm from this lack of interoperability is that direct applications of operatorsbetween different classes like vector = vector*scalar is not possible.The issues outlined above do not only apply for CSP variables, however, but to any rangeof classes which are used in operations or functions with one another.Object Oriented Programming Implementation of Scalar, Vector, and 3Tensor Variables for 1 to 3D Calculations
  • 7. Lune Gene YeoAn obvious answer to this would be to dynamic polymorphism. Thus, it will be easier forany future extension in the form of new types of objects, if the new objects conform tothe original interface. In object-oriented polymorphism, the original program does noteven need to be recompiled (only relinked) in order to make use of new types exhibitingnew, but interface-conformant behaviour.In dynamic binding, heterogeneous collections are handled elegantly, the executable codesize is potentially smaller and code can be entirely compiled (Vandevoorde and Josuttis,2006, p. 238). This was therefore a natural choice in the search for a viable solution to theabovementioned problem.ClaimThe aim of this project is to compare the performance in terms of speed and storagerequirements of an implementation of separate template classes with a polymorphicimplementation of these template classes (see Figure 1.5 in the Methods Section, page 9)for the 3 dimensional unions of these classes. The current implementation is used as abenchmark with a speed of one.A new storage system for the variable classes was also written to resolve type differencesautomatically using the template struct pair, a core component of the STL (StandardTemplate Library) library which stores heterogeneous pairs of values (Stepanov and Lee,1995, p. 5).AgendaThe report begins with the Methods section detailing changes done to the original suite,the important steps in writing the code for each different suite and a short description ofthe test programs used.This is followed by the Results section which contains graphs and measurements of thespeed and storage performances of the class suites. The results and implications of thisproject are then discussed in the Discussion section.Conclusions drawn from the project are then expressed in the Conclusions section, whichis followed by the Acknowledgements section, the List of References, the List of Tablesand Figures and the Appendix.Object Oriented Programming Implementation of Scalar, Vector, and 4Tensor Variables for 1 to 3D Calculations
  • 8. Lune Gene YeoMethodsSoftware EngineeringThe pre-existing suite of CSP variable classes (ScalarVariable, VectorVariable1,VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2 andTensorVariable) is referred to as Template1 in this project. A new storage system for thevariable classes was written to resolve type differences automatically via the templatestruct pair in Template1b (a suite of classes which is identical to Template1, with theexception of storing flag and data as a single pair type (pair<DATA_STYLE, fT> data)instead of in two different variables (DATA_STYLE flag and fT data) as in Template1).Polymorphic was then written to connect the separate variable template classes through asingle base class as a replacement for the existing suite of variable template classes. Bothmodels were compared in terms of speed and storage requirements in relation to eachother. See the activity diagram in Figure 1.3 for the general steps undertaken in thecourse of this project.All programming was done in the C++ programming language as it supports dynamicbinding, and hence polymorphism. The code was compiled on the Intel(R) Pentium(R) MObject Oriented Programming Implementation of Scalar, Vector, and 5Tensor Variables for 1 to 3D Calculations
  • 9. Lune Gene Yeoprocessor using the Dev C++ Version 4.9.9.2 compiler by Bloodshed Software.Template1, Template1b and Polymorphic class suites, their associated test programs aswell as the results of this project were burned into the CD accompanying this report.The style of programming was executed along two of the guiding principles of extremeprogramming: Simplicity, where the simplest thing that could possibly work is done andthe system is left in the simplest condition possible (Anderson, Beattie, Beck et al., 1998,p. 24); and Testing, where unit testing was done upon the completion of each suite ofclasses (Anderson, Beattie, Beck et al., 1998, p.28).Variable Class SuitesTemplate 1This suite refers to the original code for the variable classes ScalarVariable,VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2and TensorVariable. Refer to Figure 1.2 on page 3 for the class hierarchy.Data StructureThe data is stored by the scalar, vector and tensor variables in the form of two types:fT data - A template defined type (fT) which can be substituted by the types defined bythe typedefs in the header file CSP_number_types.h. This is used to store numericalvalues (e.g.: int, float).typedef char char8;typedef unsigned char uchar8;typedef char int8;typedef unsigned char uint8;typedef short int16;typedef unsigned short uint16;typedef int int32;typedef unsigned int uint32;typedef long long long64;typedef unsigned long long ulong64;typedef float float32;Object Oriented Programming Implementation of Scalar, Vector, and 6Tensor Variables for 1 to 3D Calculations
  • 10. Lune Gene Yeotypedef double double64;DATA_STYLE flag – An enumeration (DATA_STYLE) defined in the header fileCSP_definitions.h. This is used to store the flags which tag the values stored by the classto specify the data source of usage of this instance of the class, bounded by theenumeration types shown below.PLAIN, // modifiable, dependent or indep. var.INIT_GUESS, // convergence oriented not phys. meaningful, notcheckedINIT_COND, // physically meaningful initial condition, checkedDIRICH, // Dirichlet boundary conditionNEUMANN, // Neumann boundary conditionEOS, // Value calculated from equation of stateFIELD_DATA, // (Geological) field data for comparisonBOUNDARY, // flag used to denote placement at a group boundaryALL, // PLAIN + BOUNDARYCSP_FIXED, // unspecified discriminatorMULTIPLE // combinations, for instance DIRICH & BOUNDARYSpecificationsTable a.i. in the Appendix section outlines the methods declared and defined in theclasses, sorted according to the classes of incidence of these methods and operators. Theequivalent outline for overloaded operators in the classes is in Table a.ii. in the Appendixsection.Steps Taken • The first step was to run main_CSP_number_types.exe where the value ‘4’ was set for the default size in which the compiler. • Unit testing, speed and storage testing was then done for the suite Template 1 using program Variable_Test_Template1.exe.Template 1bObject Oriented Programming Implementation of Scalar, Vector, and 7Tensor Variables for 1 to 3D Calculations
  • 11. Lune Gene YeoThis suite is identical to Template1 with one exception: Template1b implements a newdata storage scheme using the pair template struct, which is core component of the C++STL library, in place of the old storage scheme in Template 1 (see Figure 1.4). Thepurpose of the creation of this suite is for it to serve as a control case for comparisonwith the Polymorphic suite, as both of these uses the same data storage scheme. Thus,instead of storing numerical data value and its associated tag which indicates the sourceof the data as two separate different types, they are stored as members of a template struct(pair).Storage schemes for Template1 and Template1bData storage scheme was altered from DATA_STYLE flag and fT data topair<DATA_STYLE, fT> data. The new pair data storage system uses the two publicfields of the pair, first and second, to store the data. The variable “flag” (which stores thedata source of usage, limited to the types defined in CSP_definitions.h) is now stored indata.first, and “data” (which stores the numerical data values defined inCSP_number_types.h) is now stored in data.second. Steps Taken • Unit testing, speed and storage testing was then done for the suite Template 1b using program Variable_Test_Template1b.exe. PolymorphicObject Oriented Programming Implementation of Scalar, Vector, and 8Tensor Variables for 1 to 3D Calculations
  • 12. Lune Gene Yeo This suite is the original suite of separate classes implemented under a polymorphic structure which unifies all variable classes under the base class Variable<fT>. This suite implements the same storage scheme using pairs as is used in Template1b (see Storage Schemes for Template1 and Template1b above). The new class hierarchy is shown in Figure 1.5.SpecificationsTable a.iii. in the Appendix section outlines the methods declared and defined in theclasses, sorted according to the classes of incidence of these methods and operators.Steps Taken • The common methods of the classes ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2, TensorVariable, which consist of fT Average(), void Out() const, bool IsWithinRange( fT vmin, fT vmax ) const, void Zero(), void Fabs(), fT Value() const, fT Value(const stl_index& i=0) const, fT Value(stl_index i, stl_index j) const, DATA_STYLE& Flag(), DATA_STYLE& Flag(const stl_index& i=0), DATA_STYLE& Flag(stl_index i=0, stl_index j=0), void Sqrt(), void Log(), void Log10(), void In(), stl_index Dim() const, void EuclideanNormalize(), void Identity(), fT MinElement()Object Oriented Programming Implementation of Scalar, Vector, and 9Tensor Variables for 1 to 3D Calculations
  • 13. Lune Gene Yeo const, fT MaxElement() const and fT Determinant() const, as well as the destructor of class Variable, were made virtual in the base class Variable. These common methods are given empty definitions under the base class Variable, which were then overridden in their respective sub classes. • Unit testing, speed and storage testing was then done for the suite Polymorphic using program Variable_Test_Polymorphic.exe. • The header file CSP_definitions.h, which contains the enumeration DATA_STYLE (which has a type status in suite Template1 and Template1b) was included in Variable.h and taken out from the list of header file inclusions for ScalarVariable, VectorVariable and Tensor Variable classes from 1D to 3D.Guide to Test ProgramsUnit Test Programs and Benchmarking ProgramsUnit tests (to test common methods and overloaded operators to make sure they work),speed benchmarking conducted for a variety of operations involving 2D and 3D variablesand associated storage requirements measurements are done using different functionswithin individual test programs( which are tailored specifically for each class suite).Test programs called Variable_Test_Suite name.exe are included in each suite’s folder.Suite name is replaced with the name of the suite subject to the tests (e.g.: Polymorphic).Project Variable_Test_Suite name which includes • Variable_Test_(Suite name).h • Variable_Test_(Suite name).cpp • main.cppThis includes the following functions: • unit_test(): Unit tests for the common functions of the variable classes: fT Average(), void Out() const, bool IsWithinRange( fT vmin, fT vmax ) const, void Zero() and void Fabs(), as well as for common operators *=, +=, -=, /= and =.Object Oriented Programming Implementation of Scalar, Vector, and 10Tensor Variables for 1 to 3D Calculations
  • 14. Lune Gene Yeo • SpeedTest(): A speed test done in loops with a variety of calculations involving 3D vectors and 2D tensors in each loop. An array of twenty 3D vectors is created and the operators += and -= are applied nineteen times between the components of this array. This process is repeated in a loop; and then further sets of loops in increasing quantities are applied. The number of loops range from an amount of 0 loops to 1000000 loops, where the amount of loops is incremented by 100000 at the end of each cycle of loops (e.g.: 100000 loops are used, then at the next stage 200000 loops are used) The time need for each set of loops are calculated at the end of each set cycle. The equivalent is done for the 2D tensors. The function then outputs the times taken to a text file. • StorageTest(): A test to compare using the associated storage sizes of instances of ScalarVariable, VectorVariable and TensorVariable classes from 1D to 3D. The sizeof() function, which returns an integer value that is the size in bytes of the data, to obtain the associated storage sizes of the aforementioned instances. Each of the variable instances measured store floats. The function then outputs the size to a text file.Each test program is customized to suit the individual suite it tests for. To use, follow theinstructions which appears on the console menu when it runs.The speed and storage requirement data is generated as text files in the folders of therespective suites. The numerical data from the speed test text files are then visualized inMicrosoft Excel 2003 as linear graphs with markers displayed at each data value, whereasthe storage requirements are depicted on a clustered column chart.Object Oriented Programming Implementation of Scalar, Vector, and 11Tensor Variables for 1 to 3D Calculations
  • 15. Lune Gene YeoResultsThe final results of speed benchmarking tests and associated storage requirementcomparisons are presented following section and summarized in the Table 1.1 andTable1.2. Based on this data, graphs were generated from Microsoft Excel 2003 (seeFigure 1.6 and Figure 1.7), to illustrate the data trends. As Template1b is the control casefor comparison with Polymorphic, comparisons between the results of Template1 andPolymorphic shall not be made.Speed BenchmarkingAt 0 to 50000 loops, the time taken by class instances (ScalarVariable, VectorVariable,and TensorVariable) remains at 0 seconds (see Figure 1.6 and Table1.1). However, after50000 loops, Template1b increases at a rate greater than that of Template1, as shown bythe divergence of the related curves (see Figure 1.6 and Table1.1). An application of theTrendline function in Excel on both the curves reveals a gradient of 0.3659 for Template1and 0.7713 for Template1b (see Figure 1.7).A comparison of the curves for Template1b and Polymorphic, however, reveals a relationsimilar to that of Template1 and Template1b. At 0 to 50000 loops, the time taken for bothcases remains at 0 seconds. But after 50000 loops, Polymorphic increases at a greater ratethan Template1b (see Figure 1.6). The Trendline function on Polymorphic curve gives agradient of 1.0123 as opposed to the 0.7713 gradient for Template1b (see Figure 1.7).Object Oriented Programming Implementation of Scalar, Vector, and 12Tensor Variables for 1 to 3D Calculations
  • 16. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 13Tensor Variables for 1 to 3D Calculations
  • 17. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 14Tensor Variables for 1 to 3D Calculations
  • 18. Lune Gene YeoStorage Requirement ComparisonsIn a comparison between storage requirements for Template1 and Template1b, it isshown that instances of ScalarVariable, VectorVariable1, VectorVariable2,VectorVariable, TensorVariable1, TensorVariable2 and TensorVariable take up morememory space in Template1b compared to its counterparts in Template1 (see Figure 1.8and Table 1.2). This shows that the “pair” storage system takes up more space than theoriginal storage system (which consists of a template defined type and an enumeration).Comparisons between the storage requirements of Template1b and the Polymorphic showthat instances of ScalarVariable, VectorVariable and TensorVariable for 1D to 3D forboth suites take up the same amount of space (see Figure 1.8 and Table 1.1).Object Oriented Programming Implementation of Scalar, Vector, and 15Tensor Variables for 1 to 3D Calculations
  • 19. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 16Tensor Variables for 1 to 3D Calculations
  • 20. Lune Gene YeoDiscussionInteroperability Issues: A SolutionIndividualistic Templates…The interoperability deficiency in the existing template base static polymorphic model(represented by the Template1 suite of classes) is mainly a corollary of its early binding(static binding) mechanism.Binding is defined as connecting a function call to a function body, where binding beforea program is run is called early binding (also called static binding) whereas binding atruntime is called late binding, which is also called dynamic binding (Eckel, 2000, p.631).See page 2 of the Literature Review in the Introduction Section.The consequence of the amalgamation of effects from the independence of its classes,ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1,TensorVariable2 and TensorVariable (classes of scalar, vector and tensor variablesranging from 1D to 3D), from each other and its early binding mechanism in theObject Oriented Programming Implementation of Scalar, Vector, and 17Tensor Variables for 1 to 3D Calculations
  • 21. Lune Gene YeoTemplate1 model is the lack of interoperability between the scalar, vector and tensorvariables on all levels of dimensionality.The aforementioned variables, can be described as objects in code terms: objects beingthe elements in the problem space (location of where the model of a problem is beingsolved, code text on the compiler interface) and their representatives in the solution space(the place where the problem is being modeled, which is the computer) (Eckel, 2000, p.23), which in this case stores numerical data and flags which tag the values stored inorder to indicate the data source of usage.The classes templates aligned with these objects, which describes a set of objects thathave identical characteristics (DATA_STYLE flag and fT data in this case) and behaviors(functionality)(Eckel, 2000, p. 26) and thus the blueprints of these objects, are notinterconnected. The behaviors of the objects (the scalar, vector and tensor variables) aredefined in the class and the function calls of the objects are bound to the functions atcompile time (see Figure 1.9) due to the early or static binding nature of staticpolymorphism which is executed by class templates of the Template1 suite. Hence theobject behavior or the (possible) interactions between the variables are set in stasis at thatstage.As there is no connection between the classes, thus any exchanges between the objectscannot be facilitated by the running program in the end, as binding has already beenimplemented before runtime. An obvious path of inquisition to overcome such an objectoriented problem would be along the lines of object oriented programming, which issometimes referred to as programming using virtual functions or dynamic polymorphism(refer to page 1 of the Literature Review in the Introduction section).…Welded Together By PolymorphismIn the polymorphic model (represented by the Polymorphic suite of classes), however, thebase class Variable is downcast to the subclasses (formerly classes of Template1)ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1,TensorVariable2 and TensorVariable. Therefore, through this inheritance relationship,the classes are henceforth linked (see Figure 1.5).Object Oriented Programming Implementation of Scalar, Vector, and 18Tensor Variables for 1 to 3D Calculations
  • 22. Lune Gene YeoThe key ability of polymorphism, implemented through virtual functions, is permittingthe many types (ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable,TensorVariable1, TensorVariable2 and TensorVariable) to be treated as a single type(Variable).The keyword virtual is applied to the common methods in ScalarVariable,VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2and TensorVariable (methods which are inherited by the subclasses from the base class),in which the declaration of the function is preceded by the keyword virtual. This instructsthe C++ compiler (Dev C++) to perform late binding instead of early binding (Eckel,2000, p. 632). The late binding mechanism works as thus (see also Figure 2.0): 1. Object behavior (functions) of the scalar, vector and tensor variables are derived from the base class Variable. 2. A single, unique address table called the VTABLE is created for the base class Variable which contains the virtual functions. 3. The addresses of the virtual functions listed on page 9 to 10 of the Methods section are placed onto this VTABLE. 4. A pointer, known as the vptr, is placed onto the class Variable. This is initialized automatically via the constructor, when the constructor of Variable is called, to point to the beginning of the VTABLE. Next, the constructor of the subclass of the object (variable) in use is called. 5. At runtime this function of the subclass is retrieved by dereferencing the vptr, accessing its address in the VTABLE.Object Oriented Programming Implementation of Scalar, Vector, and 19Tensor Variables for 1 to 3D Calculations
  • 23. Lune Gene YeoAs the binding of the functions occur during runtime (see Figure 1.9 and step 5 of the latebinding mechanism description above), any operations between the different objects ofthe subclasses ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable,TensorVariable1, TensorVariable2 and TensorVariable, such as vector =vector*scalar; which are defined during compile time, is possible.The new storage system implemented in Template 1b and Polymorphic using the pairtemplate struct from the STL Library (which allows data polymorphism) was written toattain the same purpose of resolving the interoperability issues arising from typedifferences. Under this new system, DATA_STYLE flag and fT data are both membersof the same struct; whereas in the case of both Template1b and Polymorphic, this isimplemented by a pair type variable named data (see Figure 1.4 on page 8 under theMethods section).Object Oriented Programming Implementation of Scalar, Vector, and 20Tensor Variables for 1 to 3D Calculations
  • 24. Lune Gene YeoInteroperability versus Speed versus Storage RequirementsWith reference to the Results section above, the speed at which the objects of theTemplate1b class suite (an equivalent of Template1 using the same data storage system(with the STL container, the pair template struct) in Polymorphic) run faster than theircounterparts of the Polymorphic class suite (see Figure 1.6 and Table 1.1).This can be explained by the late binding mechanism integral to dynamic polymorphism,where there is a calling of an additional constructor (in a polymorphic hierarchy, theconstructor of the base class (Variable) is always called before the constructor of thesubclass in use (ScalarVariable, VectorVariable1, VectorVariable2, VectorVariable,TensorVariable1, TensorVariable2 or TensorVariable)). Thus, 2 constructors per objectare called. A more detailed explanation of the constructor calling chain is shown inFigure 2.1.Object Oriented Programming Implementation of Scalar, Vector, and 21Tensor Variables for 1 to 3D Calculations
  • 25. Lune Gene YeoAlso in factor is the late binding of class methods: during runtime, the compiler willcheck the current data type of the array item and it will call the specific method of thechild class and not its equivalent in the base class (Shaker, 2005,http://cairocafe.blogspot.com/2005_09_11_cairocafe_archive.html). Virtual functionscannot be declared as inline functions, so there will always be an overhead of onefunction call.All these complexities lend weight to the total volume of processes that occur duringruntime, slowing down the whole process altogether. In contrast, in the case of theobjects of the classes of Template1, only one constructor per object needs to be called asthe classes are not related through a base class. Early binding of functions means that nobinding occurs during runtime.All these factors above explain why the Polymorphic suite operations are slower than itscounterparts in Template1.The instances (storing floats) of the objects of the classes ScalarVariable,VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2and TensorVariable from Template1b take up the same amount of storage space(measured in bytes) in memory as their equivalents in Polymorphic1 (see Figure 1.8 andTable 1.2) as they use the same storage scheme (pair template structs from the STLlibrary), but both these models are less efficient in storage space needs compared toTemplate1, which stores the same data in two separate types.This storage scheme using pairs, which works on the basis of data polymorphism, slowsdown the speed of operations during runtime for the very same reason that slows downthe speed of operations in dynamic polymorphism (refer to Interoperability Issues: ASolution on pages 17-20).Taking factors of speed, storage and ease of interoperability into account for the 3 models(Template1, Template1b and Polymorphic), one has to make two different kinds ofcompromises between the opportunity costs, as shown in Figure 2.2.Object Oriented Programming Implementation of Scalar, Vector, and 22Tensor Variables for 1 to 3D Calculations
  • 26. Lune Gene YeoLimitations of the Models TestedThus, the limitations of the Template1, Template1b and Polymorphic models are clearlyillustrated in Figure 2.2: compromises have to be made between speed, storagerequirements and ease of interoperability. While downcasting ScalarVariable,VectorVariable1, VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2and TensorVariable from a base class in a polymorphic hierarchy solves the issues ofinteroperability due to type differences, it slows down the speed of operations duringruntime at an increasing rate as the operations grow in scale (see Figure 1.6) due to theindirection through pointers.Furthermore, the interface commonality needs to be expressed through a common baseclass, concrete types with only partial interfaces cannot be used if only that part isexercised by the application, the code cannot compile as efficiently, the code cannot bechecked as thoroughly, and dead code cannot be eliminated as effectively. This is due toObject Oriented Programming Implementation of Scalar, Vector, and 23Tensor Variables for 1 to 3D Calculations
  • 27. Lune Gene Yeothe fact that the explicit specification of implementation details is forfeited (Agesen, 1996,p.1).Possible Alternative ModelsYet another alternative (dynamic) polymorphic model to the model in this project couldtake a STL library container, like a pair type, as its base class (e.g.: pair<DATA_STYLE,csp_float>) which is inherited by subclasses. A suitable container for the subclasseswould just flatten them storing only the pairs.Another choice could be a template based (static polymorphism) approach could be alsoused which utilizes the Barton-Nackman trick, also known as the Curiously RecurringTemplate Pattern; where a template class derives from an instantiation of anothertemplate, passing itself as a template parameter to that other template in this form:class A : public base<A> { ... };In the case of the CSP variable classes, it would thus be appropriate to apply it asclass X : public Variable<X> { ... }; where the class Variable here is thetemplate equivalent of the base class Variable in the Polymorphic suite of classes and Xrepresents the template equivalent of the subclasses ScalarVariable, VectorVariable1,VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2 or TensorVariable.To illustrate an example, a ScalarVariable object storing floats would be initialized asVariable<ScalarVariable<csp_float> > sc.The important application of this technique is to give a common “base template” for a setof template classes. One can overload operators and other non-member functions for thecommon base template: the derived classes will match the definitions. Because it avoidsrun-time dispatching, this technique is often used in the numerical domain (Järvi,Willcock and Lumsdaine, 2003, p. 236).Apart from the two alternative models outlined above, many other possible polymorphicmodels are also potential solutions to the interoperability issues surrounding Template1.Object Oriented Programming Implementation of Scalar, Vector, and 24Tensor Variables for 1 to 3D Calculations
  • 28. Lune Gene YeoImplications for Object Oriented ProgrammingIn many ways, dynamic polymorphism (which allows programs to be more general byletting each class of a related group of classes have a different implementation of aparticular function) is the fundamental concept of the object oriented programmingapproach for problem solving. The key contribution of dynamic polymorphism is the dataabstraction that it permits.Object oriented programming, true to its name, revolves around objects which come fromclasses. The interface of the methods defined in a class can be specified separately fromthe implementation details, allowing the design of the system to be separated from itsimplementation (Wiener and Pinson, 1988, p.3).An important enhancement provided by object the oriented programming approach isreusability (the concepts encapsulated in the class are provided in the method interfaces).Maintainability is enhanced in this approach as changes in the implementation of a datastructure (or algorithm) can be localized to the region of code that implements the classor part of the class. No fall-out effects are induced in the scope outside the class becausethe class interface is preserved (Wiener and Pinson, 1988, p.3).In a non-polymorphic class hierarchy, reusability and maintainability is limited to anintra-class level (within methods); and is not accomplished on an inter-class level. Thiseffectively negates the advantages of an object oriented approach if more than one classof objects has to be utilized in a single operation or a set of operations.In the case of this project, the classes ScalarVariable, VectorVariable1, VectorVariable2,VectorVariable, TensorVariable1, TensorVariable2 and TensorVariable are used in themodeling of geological processes such as the simulation of a steady state fluid pressuredistribution example as detailed on pages 19 to 26 of the Complex Systems Platform 5.0User’s Guide written by Matthai, Geiger and Roberts (2004); where interoperationsbetween different variable classes, for example vector = vector*scalar in one ofthe derived equations of the steady-state fluid-pressure distribution equation (equation (2)on page 19 of the user’s guide) where K, the hydraulic conductivity (a scalar quantity) ismultiplied with p, the fluid pressure (a vector quantity).In this project’s attempt to resolve these issues (of interoperability), a polymorphichierarchy was created for the ScalarVariable, VectorVariable1, VectorVariable2,Object Oriented Programming Implementation of Scalar, Vector, and 25Tensor Variables for 1 to 3D Calculations
  • 29. Lune Gene YeoVectorVariable, TensorVariable1, TensorVariable2 and TensorVariable classes via a topdown data type decomposition approach. This allows the common functionality of theclasses to be shared in a base class, thus allowing the programmer (a user of the CSPlibrary in this case) to pursue a course of action by sending a message to an objectwithout being concerned about how the software system is to implement the action: thisbecomes significant when the same general type of action can be executed in differentways by different types of objects. This concept can be illustrated by a non-softwareanalogy such as the case on page 144 of the book entitled An Introduction to ObjectOriented Programming and C++ by Wiener and Pinson (1988).Other cases of using dynamic polymorphism to solve a programming problem is thebuilding of a heterogeneous linked list for a university records system as shown on AnIntroduction to Object Oriented Programming and C++ by Wiener and Pinson (1988)from pages 157 to 165, as compared to the non-polymorphic approach on pages 150 to157, where the dynamic polymorphic approach provides more reusability during softwaremaintenance (e.g.: a new subclass (of university people) may need to be added to the list).This example is expanded upon on pages 170 to 176, where a heterogeneous search treeis built for the university records system using polymorphism. In this case, if a newsubclass were to be added to the university people (e.g. student exchange scholars), itwould be easier to implement. Polymorphism can also be used in finite state machines(an important design tool in software engineering) such as the one illustrated on pages176 to 181.Dynamic polymorphism, like all other mechanisms, has its limitations as well. In the caseof early binding polymorphism (e.g.: operator overloading), the early binding mechanismleads to runtime efficiency as the compiler can optimize code before executing it.However, in the Polymorphic suite of classes written in this project, late bindingpolymorphism is in place reduces run time efficiency but compensates with flexibilityand a high level of problem abstraction.Object Oriented Programming Implementation of Scalar, Vector, and 26Tensor Variables for 1 to 3D Calculations
  • 30. Lune Gene YeoConclusionsThe existence of classes which are separate from one another (not connected through abase class or a template equivalent) creates interoperability issues in a situation when theobjects of these classes need to be used in operations involving each other.The CSP template (static polymorphic) classes ScalarVariable, VectorVariable1,VectorVariable2, VectorVariable, TensorVariable1, TensorVariable2 andTensorVariable; which are used in tandem with each other to model geological processesand their interactions, provide an excellent example of where these issues may arise.Dynamic polymorphism, or more specifically its inheritance mechanism, was used in anattempt to engineer a solution to these issues through the creation of a new suite ofclasses, fittingly named Polymorphic. This new model connects the aforementioned CSPtemplate classes through the base class Variable, solving the issues outlined above.However, late binding is a core mechanism of the dynamic polymorphic model, whichslows down runtime speed significantly through the added complexity due to theindirection of pointers.A new storage system where the stored data is connected through static polymorphism(with a STL container, pair, which is a template struct) was also implemented in an efforttowards solving the same issues involving type difference. This new storage scheme is,however, more inefficient in terms of storage requirements; in addition to also having thesame outcome (as dynamic polymorphism) of slowing down runtime processes.Dynamic polymorphism is a crucial element of object oriented programming, havingapplications in other problems outside the CSP scalar, vector and tensor template classes(1D to 3D) dilemma. Some of these are linked lists, search tress and finite state machines.Other models are possible however, including using an approach based upon the “Barton-Nackman trick” (Curiously Recurring Template Pattern) where a template (staticpolymorphic) version of the base class in the Polymorphic model can be used to unify thescalar, vector and tensor classes from 1D to 3D.Object Oriented Programming Implementation of Scalar, Vector, and 27Tensor Variables for 1 to 3D Calculations
  • 31. Lune Gene YeoAcknowledgementsI would like to thank Dr. Stephan Matthai for his invaluable help and guidance inunderstanding CSP and the problems associated with the current CSP variable classes; aswell as providing the existing code for the variable classes of CSP 5.0.I would also like to thank Adriana Paluzny, Hassan Sabirin, Alan Chew and VeraPancaldi for shedding light on programming concepts/techniques and the intricacies ofC++.Object Oriented Programming Implementation of Scalar, Vector, and 28Tensor Variables for 1 to 3D Calculations
  • 32. Lune Gene YeoList of References 1) Matthai, S. K., Geiger, S. and Roberts, S.G., 2004, Complex Systems Platform 5.0 User’s Guide, Department of Earthsciences, ETH Zurich, Switzerland, 129 p. 2) Eckel, Bruce, 2000, Thinking in C++ Second Edition Volume One: Introduction To Standard C++, Prentice Hall Inc., New Jersey, 814 p. 3) Vandervoorde, David and M. Josuttis, Nicolai, 2006, C++ Templates: The Complete Guide, Addison-Wesley, Boston, MA, 528 p. 4) Anderson, A., Beattie, R., Beck, K. et al., 1998, Chrysler Goes to “Extremes", Distributed Computing Volume 54 Number 1, p. 24-28 5) Stepanov, Alexander and Lee, Meng, 1995, The Standard Template Library, HP Laboratories Technical Report 95-11(R.1), (Revised version of A. A. Stepanov and M. Lee: The Standard Template Library, Technical Report X3J16/94-0095, WG21/N0482, ISO Programming Language C++ Project, May 1994.), p. 1-64 6) Gunther, Carl A. and Mitchell, John C., 1994, Theoretical Aspects of Object- Oriented Programming: types, semantics, and language design, The MIT Press, London, 558 p. 7) Wegner, Peter, 1990, Concepts and paradigms of object-oriented programming, ACM SIGPLAN OOPS Messenger, Volume 1 Issue 1, p.7-87 8) Shaker, Kareem, 2005, Cairocafe (Tech Talks), http://cairocafe.blogspot.com/2005_09_11_cairocafe_archive.html 9) Agesen, Ole, 1996, Concrete Type Inference: Delivering Object-Oriented Applications, p. 1-175 10) Järvi, Jaakko, Willcock, Jeremiah and Lumsdaine, Andrew, 2003, Concept- controlled polymorphism, Generative Programming And Component Engineering; Vol. 48, p. 228-244 11) S. Wiener, Richard and J. Pinson, Lewis, 1988, An Introduction to Object Oriented Programming and C++, Addison-Wesley, Boston, MA, 273 p. 12) Simons, A.J.H. and Cowling, A.J., 1992, A proposal for harmonising types, inheritance and polymorphism for object- oriented programming, Department of Computer Science Research Report CS-92-13, (Sheffield: DCS, 1992), p. 1-31Object Oriented Programming Implementation of Scalar, Vector, and 29Tensor Variables for 1 to 3D Calculations
  • 33. Lune Gene Yeo 13) Matthai, S. K., 2005, Object Oriented Programming with C++ and UML, lecture session 6, 24 p. 14) Campbell-Kelly, 1985, M. Christopher Strachey, 1916–1975 — A Biographical Note, IEEE Annals of the History of Computing, Vol.7, No.1, p.19–42 15) Lee, Jan, 2002, CS 1104 – Introduction to Computer Science, http://courses.cs.vt.edu/~cs1104/Compilers/Compilers.020.htmlObject Oriented Programming Implementation of Scalar, Vector, and 30Tensor Variables for 1 to 3D Calculations
  • 34. Lune Gene YeoList of Tables and Figures*All figures were drawn using Adobe Illustrator 12.0.1. All tables were created usingMicrosoft Excel 2003 and then edited using Adobe Illustrator 12.0.1.List of Figures 1) Figure 1.1, Class hierarchy of base class Shape and its subclasses, p. 2 2) Figure 1.2, Class hierarchy of Template1 suite, p. 3 3) Figure 1.3, Storage schemes for Template1 and Template1b, p. 5 4) Figure 1.4, Activity diagram for project methodology, p. 8 5) Figure 1.5, Class hierarchy of Polymorphic suite, p. 9 6) Figure 1.6, Speed benchmarks for ScalarVariable, VectorVariable and TensorVariable from 1D to 3D implementations for Template1, Template1b and Polymorphic suites (graph), p. 13 7) Figure 1.7, Speed benchmarks for ScalarVariable, VectorVariable and TensorVariable from 1D to 3D implementations for Template1, Template1b and Polymorphic suites (graph with Trendline function), p. 14 8) Figure 1.8, Associated storage space requirements for ScalarVariable, VectorVariable and TensorVariable for 1D to 3D implementations, p.15 9) Figure 1.9, Early binding and late binding at different stages of in the birth of a program (compile time and runtime), p. 17 10) Figure 2.0, Late binding mechanism: what happens when a virtual function is used, p. 20 11) Figure 2.1, Constructor calling chain for inherited classes, p. 21 12) Figure 2.2, Bar scales showing the compromises that has to be made in choosing between the 3 models, p. 23List of Tables 1) Table 1.1, Speed benchmarks for ScalarVariable, VectorVariable and TensorVariable from 1D to 3D implementations for Template1, Template1b and Polymorphic suites, p. 16Object Oriented Programming Implementation of Scalar, Vector, and 31Tensor Variables for 1 to 3D Calculations
  • 35. Lune Gene Yeo 2) Table 1.2, Associated storage space requirements for ScalarVariable, VectorVariable and TensorVariable for 1D to 3D implementations, p. 16Object Oriented Programming Implementation of Scalar, Vector, and 32Tensor Variables for 1 to 3D Calculations
  • 36. Lune Gene YeoAppendixFiles in the folders of the different models (on CD) Template1 Template1b Polymorphic CSP_Index.h CSP_Index.h CSP_Index.h CSP_number_types.h CSP_number_types.h CSP_number_types.h CSP_String.h CSP_String.h CSP_String.h CSP_Point.h CSP_Point.h CSP_Point.h CSP_definitions.h CSP_definitions.h CSP_definitions.h ScalarVariable.h ScalarVariable.h ScalarVariable.h VectorVariable1.h VectorVariable1.h VectorVariable1.h VectorVariable2.h VectorVariable2.h VectorVariable2.h VectorVariable.h VectorVariable.h VectorVariable.h TensorVariable1.h TensorVariable1.h TensorVariable1.h TensorVariable2.h TensorVariable2.h TensorVariable2.h Main.cpp Main.cpp Main.cpp CSP_Index.cpp CSP_Index.cpp CSP_Index.cpp CSP_Point.cpp CSP_Point.cpp CSP_Point.cpp main_CSP_number_types.cpp main_CSP_number_types.cpp main_CSP_number_types.cpp ScalarVariable.cpp ScalarVariable.cpp ScalarVariable.cpp VectorVariable1.cpp VectorVariable1.cpp VectorVariable1.cpp VectorVariable2.cpp VectorVariable2.cpp VectorVariable2.cpp VectorVariable.cpp VectorVariable.cpp VectorVariable.cpp TensorVariable1.cpp TensorVariable1.cpp TensorVariable1.cpp TensorVariable2.cpp TensorVariable2.cpp TensorVariable2.cpp Variable_Test.cpp Variable_Test.cpp Variable_Test.cpp Variable_Test_Template1.dev Variable_Test_Template1b.dev Variable_Test_Polymorphic.dev Variable_Test_Template1.exe Variable_Test_Template1b.exe Variable_Test_Polymorphic.exe Variable.h Variable.cppObject Oriented Programming Implementation of Scalar, Vector, and 33Tensor Variables for 1 to 3D Calculations
  • 37. Lune Gene YeoText files generated from the test programs (on CD)Test Program Variable_Test_ Variable_Test_ Variable_Test_ Variable_Test_Name Template1.exe Template1b.exe Polymorphic.exe Template2.exeTest Subject Template1 Template1b Polymorphic Template2Speed Speed_Temp1.t Speed_Temp1b.txt Speed_Poly.txt Speed_Temp2.txt xtStorage Storage_Temp1 Storage_Temp1b.txt Storage_Poly.txt Storage_Temp2.txt .txtObject Oriented Programming Implementation of Scalar, Vector, and 34Tensor Variables for 1 to 3D Calculations
  • 38. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 35Tensor Variables for 1 to 3D Calculations
  • 39. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 36Tensor Variables for 1 to 3D Calculations
  • 40. Lune Gene YeoObject Oriented Programming Implementation of Scalar, Vector, and 37Tensor Variables for 1 to 3D Calculations
  • 41. Lune Gene Yeo “When I let go of what I am, I become what I might be” Lao Tzu, Chinese philosopher and founder of Taoism, sixth century B.C.Object Oriented Programming Implementation of Scalar, Vector, and 38Tensor Variables for 1 to 3D Calculations