Changeset 3419 in Sophya
- Timestamp:
- Dec 7, 2007, 7:06:56 PM (18 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/SophyaLib/Manual/sophya.tex
r3417 r3419 279 279 dot . in unix). 280 280 281 \subsection{Copy constructor and assignment operator} 282 \label{memgt} 283 In C++, objects can be copied by assignment or by initialisation. 284 Copying by initialisation corresponds to creating an object and 285 initialising its value through the copy constructor. 286 The copy constructor has its first argument as a reference, or 287 const reference to the object's class type. It can have 288 more arguments, if default values are provided. 289 Copying by assignment applies to an existing object and 290 is performed through the assignment operator (=). 291 The copy constructor implements this for identical type objects: 292 \begin{verbatim} 293 class MyObject { 294 public: 295 MyObject(); // Default constructor 296 MyObject(MyObject const & a); // Copy constructor 297 MyObject & operator = (MyObject const & a) // Assignment operator 298 } 299 \end{verbatim} 300 The copy constructors play an important role, as they are 301 called when class objects are passed by value, 302 returned by value, or thrown as an exception. 303 \begin{verbatim} 304 // A function declaration with an argument of type MyObject, 305 // passed by value, and returning a MyObject 306 MyObject f(MyObject x) 307 { 308 MyObject r; 309 ... 310 return(r); // Copy constructor is called here 311 } 312 // Calling the function : 313 MyObject a; 314 f(a); // Copy constructor called for a 315 \end{verbatim} 316 It should be noted that the C++ syntax is ambiguous for the 317 assignment operator. {\tt MyObject x; x=y; } and 318 {\tt MyObject x=y;} have different meaning. 319 \begin{verbatim} 320 MyObject a; // default constructor call 321 MyObject b(a); // copy constructor call 322 MyObject bb = a; // identical to bb(a) : copy constructor call 323 MyObject c; // default constructor call 324 c = a; // assignment operator call 325 \end{verbatim} 326 327 As a general rule in SOPHYA, objects which implements 328 reference sharing on their data members have a copy constructor 329 which shares the data, while the assignment operator copies or 330 duplicate the data. 331 332 \subsection{Multi-thread programming with SOPHYA} 333 Multi-thread programming is usually safe as long as different threads DO NOT access 334 the same memory locations. SOPHYA is mainly organized as classes having only 335 data members, with very few cases having static data members (memory locations 336 common to all instances of a class), or seldom, global variables. \\ 337 Using different instances of a class in different threads is thus safe for most 338 classes / methods in SOPHYA. \\ 339 A major exception is the reference sharing mechanism, where different instances 340 of a class may shared memory locations. This reference sharing mechanism has been 341 made thread-safe in SOPHYA, from version V=2.1. \\ 342 As a consequence, different execution threads can access non overlapping sub-arrays 343 and access (read/write) the corresponding elements without the need of 344 mutex and thread synchonisation. Moreover, thread safe filling of 345 NTuple and DataTable objects can be activated, on an object per object basis. \\ 346 The {\tt ZThread, ZMutex \ldots} classes in the {\bf SysTools } module offer a relatively 347 easy way of writing multi-threaded programs. 348 281 349 \subsection{the runcxx program} 282 350 \index{runcxx} \label{runcxx} … … 303 371 LinAlg, IFFTW, XAstroPack 304 372 \end{verbatim} 305 Most examples in this manual can be tested using runcxx. The 306 example below shows how to compile, link and run a sample 373 Most examples in this manual can be tested using runcxx. 374 The preprocessor macro {\tt KeepObj()} is defined by runcxx and let the user 375 to save an objet to an PPF file, with the same name as the corresponding variable. 376 The example below shows how to compile, link and run a sample 307 377 code. 308 378 \begin{verbatim} 309 // File example.icc 310 Matrix a(3,3); 311 a = IdentityMatrix(1.); 312 cout << a ; 313 // Executing this sample code 379 ## File example.icc : 380 381 Matrix mxa(3,3); 382 mxa = IdentityMatrix(1.); 383 cout << mxa ; 384 // Save the object mxa in a PPF file named mxa 385 KeepObj(mxa); 386 387 ## Executing this sample code 314 388 csh> runcxx -f example.icc 315 389 \end{verbatim} … … 385 459 386 460 \end{verbatim} 387 \newpage 388 389 \section{Copy constructor and assignment operator} 390 \label{memgt} 391 In C++, objects can be copied by assignment or by initialisation. 392 Copying by initialisation corresponds to creating an object and 393 initialising its value through the copy constructor. 394 The copy constructor has its first argument as a reference, or 395 const reference to the object's class type. It can have 396 more arguments, if default values are provided. 397 Copying by assignment applies to an existing object and 398 is performed through the assignment operator (=). 399 The copy constructor implements this for identical type objects: 400 \begin{verbatim} 401 class MyObject { 402 public: 403 MyObject(); // Default constructor 404 MyObject(MyObject const & a); // Copy constructor 405 MyObject & operator = (MyObject const & a) // Assignment operator 406 } 407 \end{verbatim} 408 The copy constructors play an important role, as they are 409 called when class objects are passed by value, 410 returned by value, or thrown as an exception. 411 \begin{verbatim} 412 // A function declaration with an argument of type MyObject, 413 // passed by value, and returning a MyObject 414 MyObject f(MyObject x) 415 { 416 MyObject r; 417 ... 418 return(r); // Copy constructor is called here 419 } 420 // Calling the function : 421 MyObject a; 422 f(a); // Copy constructor called for a 423 \end{verbatim} 424 It should be noted that the C++ syntax is ambiguous for the 425 assignment operator. {\tt MyObject x; x=y; } and 426 {\tt MyObject x=y;} have different meaning. 427 \begin{verbatim} 428 MyObject a; // default constructor call 429 MyObject b(a); // copy constructor call 430 MyObject bb = a; // identical to bb(a) : copy constructor call 431 MyObject c; // default constructor call 432 c = a; // assignment operator call 433 \end{verbatim} 434 435 As a general rule in SOPHYA, objects which implements 436 reference sharing on their data members have a copy constructor 437 which shares the data, while the assignment operator copies or 438 duplicate the data. 439 440 \section{Multi-thread programming with SOPHYA} 441 Multi-thread programming is usually safe as long as different threads DO NOT access 442 the same memory locations. SOPHYA is mainly organized as classes having only 443 data members, with very few cases having static data members (memory locations 444 common to all instances of a class), or seldom, global variables. \\ 445 Using different instances of a class in different threads is thus safe for most 446 classes / methods in SOPHYA. \\ 447 A major exception is the reference sharing mechanism, where different instances 448 of a class may shared memory locations. This reference sharing mechanism has been 449 made thread-safe in SOPHYA, from version V=2.1. \\ 450 As a consequence, different execution threads can access non overlapping sub-arrays 451 and access (read/write) the corresponding elements without the need of 452 mutex and thread synchonisation. Moreover, thread safe filling of 453 NTuple and DataTable objects can be activated, on an object per object basis. \\ 454 The {\tt ZThread, ZMutex \ldots} classes in the {\bf SysTools } module offer a relatively 455 easy way of writing multi-threaded programs. 461 456 462 457 463 \newpage … … 462 468 class {\tcls{NDataBlock}} for handling reference counting on numerical 463 469 arrays, as well as classes providing the services for implementing simple 464 serialisation .470 serialisation (object persistence services). 465 471 \vspace*{5mm} 466 472 … … 517 523 with data objects {\bf AnyDataObject} for write operations. 518 524 \end{itemize} 519 A complete description of SOPHYA persistence mechanism and guidelines 520 for writing delegate classes for handling object persistence is beyond 521 the scope of this document. The most useful methods for using Sophya 522 persistence are listed below: 525 The most useful methods for using Sophya 526 persistence are listed below. A brief description of the PPF file format 527 and some guidelines for writing writing delegate classes for handling 528 object persistence can be found in the following paragraphs. 523 529 \begin{itemize} 524 530 \item[] {\tt POutPersist::PutObject(AnyDataObj \& o)} \\ … … 556 562 The {\bf scanppf} program can be used to list the content of a PPF file. 557 563 564 \subsubsection{PPF file format} 565 The PPF file consist of : 566 \begin{itemize} 567 \item[\rond] A file header (3x32=96 bytes) , containing an identification string, 568 PPF format version (currently V3), the file endiannes {\tt (BIG-ENDIAN , LITTLE-ENDIAN)} 569 and the file creation date and time. It should be noted that the present SOPHYA version 570 (V=2.1) does not allow updating an existing PPF file. 571 \item[\rond] A collection of tagged data items and data structuring tags. 572 the PPF tags are one byte (8 bits) long and may be followed by a length information 573 for arrays, or strings. The length information might be 4 bytes or 8 bytes long. 574 Characters, various length (1,2,4,8 bytes long) signed and unsigned integers, 575 simple or double precision (4/8) bytes floating point and complex numbers are 576 the basic data types handled by PPF streams. 577 \begin{verbatim} 578 tag=PPS_SIMPLE_Integer4 + data (4 bytes) 579 tag=PPS_SIMPLE_Float4 + data (4 bytes) 580 tag=PPS_SIMPLE_Complex8 + data (2x8=16 bytes) 581 tag=PPS_STRING + Length (4 bytes) + data (Length bytes) 582 tag=PPS_SIMPLE_ARRAY4_UInt2 + Length (4 bytes) + data (2xLength bytes) 583 \end{verbatim} 584 The two tags {\tt PPS\_OBJECT} and {\tt PPS\_ENDOBJECT} are used for identifying 585 objects. 586 \item[\rond] The file trailer contains some global statistics such as the total number 587 of objects in file, the list of name tags, with their corresponding positions. 588 These informations are grouped under the identifier tag {\tt PPS\_NAMETAG\_TABLE }. 589 The last byte in file contains the value {\tt PPS\_EOF} 590 \end{itemize} 591 We show below the result of the analysis of a PPF file using 592 {\tt PPFBinaryInputStream::AnalyseTags()}. This can easily be done using the 593 {\bf runcxx} program. 594 The PPF file contains four objects: 595 a {\tt TimeStamp} object, two {\tt NDataBlock} objects, the second one sharing its data with 596 the first one. The second NDataBlock is only written as a reference to the first object. The fourth 597 object is a {\tt RandomGenerator} which has an {\tt NDataBlock} object as data member. 598 Notice the corresponding nested structure of object marker tags. 599 The first object and the last objects in the file are written associated with a {\bf NameTag}. 600 {\small 601 \begin{verbatim} 602 ---------------------------------------------------------- 603 PPFBinaryInputStream::AnalyseTags(Level= 49) 604 FileName= toto.ppf 605 Version= 3 FileSize= 8884 Creation Date= Fri Dec 7 15:30:58 2007 606 607 NbPosTag=0 NbNameTag=2 NbObjs=4 NbTopLevObjs=3 NbRefs=1 MaxNest=2 608 609 <PPS_NAMETAG_MARK> tag at position 60 610 <PPS_OBJECT> tag at position 61 ClassId= c09dfe032b341cee ObjectId= 10 611 <PPS_SIMPLE> tag at position 72 DataType=INTEGER x4 612 <PPS_SIMPLE> tag at position 77 DataType=INTEGER x8 613 <PPS_SIMPLE> tag at position 80 DataType=FLOAT x8 614 <PPS_ENDOBJECT> tag at position 89 ObjectId= 10 615 <PPS_OBJECT> tag at position 92 ClassId= e670300b367585d1 ObjectId= 21 616 <PPS_SIMPLE_ARRAY4> tag at position a3 DataType=UNSIGNED x8 NElts= 3 617 <PPS_SIMPLE_ARRAY4> tag at position c0 DataType=INTEGER x4 NElts= 50 618 <PPS_ENDOBJECT> tag at position 18d ObjectId= 21 619 <PPS_REFERENCE> tag at position 196 ObjectId= 21 OrigPos=92 620 <PPS_NAMETAG_MARK> tag at position 1a7 621 <PPS_OBJECT> tag at position 1a8 ClassId= eb6c427a5a30caed ObjectId= 30 622 <PPS_SIMPLE_ARRAY4> tag at position 1b9 DataType=UNSIGNED x4 NElts= 6 623 <PPS_SIMPLE> tag at position 1d6 DataType=UNSIGNED x8 624 <PPS_SIMPLE> tag at position 1df DataType=UNSIGNED x8 625 <PPS_OBJECT> tag at position 1e8 ClassId= 6531a8f47336d4aa ObjectId= 41 626 <PPS_SIMPLE_ARRAY4> tag at position 1f9 DataType=UNSIGNED x8 NElts= 3 627 <PPS_SIMPLE_ARRAY4> tag at position 216 DataType=FLOAT x8 NElts= 1024 628 <PPS_ENDOBJECT> tag at position 221b ObjectId= 41 629 <PPS_ENDOBJECT> tag at position 2224 ObjectId= 30 630 <PPS_NAMETAG_TABLE> tag at position 222d 631 <PPS_NAMETAG_ENTRY> NameTag=rg-randgen NameTagMark Position=1a7 632 <PPS_NAMETAG_ENTRY> NameTag=ts-timestamp NameTagMark Position=60 633 <PPS_EOF> tag at position 22b3 TagPos=222d 634 PPFBinaryInputStream::AnalyseTags() - End - Total Number of Tags= 23 635 ---------------------------------------------------------- 636 \end{verbatim} 637 } % fin de small 638 639 \subsubsection{Writing PPF handlers} 640 Here are some guidelines for creating PPF handler classes to make 641 a class persistent through the SOPHYA PPersist mechanism. The example 642 discussed here can be found in the {\bf Examples} module, in the directory 643 {\bf MyPPF}. 644 \begin{enumerate} 645 \item The class should inherit from the {\bf SOPHYA::AnyDataObj} class. 646 In the example here, we want to make the class {\bf Vfs} persistent 647 \begin{verbatim} 648 class Vfs : public SOPHYA::AnyDataObj { 649 ... 650 } 651 \end{verbatim} 652 %%%% 653 \item The PPF handler class 654 should inherit from {\bf SOPHYA::PPersist} . The pure virtual methods 655 of PPersist class (DataObj() , SetDataObj() , ReadSelf(), WriteSelf() 656 must be implemented. 657 \begin{verbatim} 658 class PPFHandlerVfs : public SOPHYA::PPersist { 659 public: 660 virtual SOPHYA::AnyDataObj* DataObj(); 661 virtual void SetDataObj(SOPHYA::AnyDataObj &); 662 protected: 663 virtual void ReadSelf(SOPHYA::PInPersist&); 664 virtual void WriteSelf(SOPHYA::POutPersist&) const; 665 } 666 \end{verbatim} 667 %%% 668 It is possible to use the template class {\tt SOPHYA::ObjFileIO<T>}, and 669 specialize it for the tharget class (here {\tt SOPHYA::ObjFileIO<Vfs>}), 670 by defining the two methods : \\ 671 \hspace*{5mm} {\tt SOPHYA::ObjFileIO<Vfs>::ReadSelf(SOPHYA::PInPersist\&) } \\ 672 \hspace*{5mm} {\tt SOPHYA::ObjFileIO<Vfs>::WriteSelf(SOPHYA::POutPersist\&) const } 673 %%%% 674 \item If it is NOT possible to have the target class inherit from {\bf AnyDataObj}, 675 a wrapper class should be used. The same class can play the role of wrapper 676 AND the PPF handler. See the PPF handler / wrapper class for STL vectors : \\ 677 \hspace*{5mm} {\tt SOPHYA::PPFWrapperSTLVector<T>} in file BaseTools/ppfwrapstlv.h 678 %%% 679 \item Implement the ReadSelf() and WriteSelf() methods of the PPF handler. 680 All the I/O services from the following classes can be used : 681 \begin{itemize} 682 \item PPFBinaryIOStrem , PPFBinaryInputStream , PInPersist 683 \item PPFBinaryIOStrem , PPFBinaryOutputStream , POutPersist 684 \end{itemize} 685 Writing and reading of the embeded objects for which a handler has been register 686 ed can simply be performed by : \\ 687 \hspace*{5mm} {\tt POutPersist::PutObject() } \\ 688 \hspace*{5mm} {\tt PInPersist::GetObject() } 689 690 {\bf Warning:} The services associated with nametags : \\ 691 \hspace*{5mm} {\tt PPFBinaryOutputStream::WriteNameTag() } \\ 692 \hspace*{5mm} {\tt PPFBinaryInputStream::GotoNameTag() } \\ 693 are {\bf NOT} intented to be used in WriteSelf() , ReadSelf() 694 %%%%% 695 \item The new PPF handler, as well as the list of classes it can handle has to be 696 registered prior to use PPF read/write for the target classes. This must be 697 performed during the initialization phase, for example at the beginning of the 698 main() program. Another possibility is to use a module initializer 699 (See {\bf SophyaInitiator} class in file BaseTools/sophyainit.h ) 700 and declare a static instance of the class. Notice that this works only if 701 the system loader handles correcly the call of constructor 702 for the statically declared objects. 703 704 The registration can be performed using the CPP macros defined in 705 BaseTools/ppersist.h 706 \begin{verbatim} 707 // First, register the PPF handler ObjFileIO<Vfs> 708 PPRegister(ObjFileIO<Vfs>); 709 // Register the list of classes which can be handled by ObjFileIO<Vfs> 710 DObjRegister(ObjFileIO<Vfs>, Vfs); 711 \end{verbatim} 712 %%%%%%%%%%%%%%%% 713 \end{enumerate} 714 715 %%%%%%%%%%%% 558 716 \subsection{\tcls{NDataBlock}} 559 717 \index{\tcls{NDataBlock}} … … 667 825 \end{itemize} 668 826 827 \subsection{Random numbers} 828 \index{RandomGenerator} 829 The C-functions defined in the file BaseTools/srandgen.h can be used 830 for generating sequence of random numbers with different PDF (probability 831 distribution functions : flat, gaussian, poisson \ldots. 832 However, we advise to use the {\bf RandomGenerator} class which provides 833 can be used in multi-threaded programs. In this case, a different instance of 834 the RandomGenerator class should be created in each thread running in parallel. 835 In addition, this class has a PPF handler which saves the complete state of the class and 836 the underlying generatoir to the PPF stream. This can be used to generate very long sequence 837 of random numbers, distributed over several runs. 838 \begin{verbatim} 839 sa_size_t N = 1000; 840 Vector vf(2*N), vg(2*N); 841 { 842 // Instanciate the random generator 843 RandomGenerator rg; 844 // Generate some sequence of random numbers 845 for(sa_size_t i=0; i<N; i++) { 846 vf(i) = rg.Flat01(); 847 vg(i) = rg.Gaussian(); 848 } 849 // Save the generator to file rg.ppf 850 POutPersist po("rg.ppf"); 851 po << rg; 852 } 853 // .... 854 { 855 // Create and read the generator from file rg.ppf 856 RandomGenerator rg; 857 PInPersist pi("rg.ppf"); 858 pi >> rg; 859 // Continue the generation sequence 860 for(sa_size_t i=N; i<2*N; i++) { 861 vf(i) = rg.Flat01(); 862 vg(i) = rg.Gaussian(); 863 } 864 } 865 \end{verbatim} 866 867 %%%%%%%%%%%% 669 868 \newpage 670 869 \section{Module TArray} … … 998 1197 TArray<int_4> ia(5,3); 999 1198 ia = 8; 1000 pos << ia; 1199 pos << ia; // (1) 1001 1200 ia = 16; 1002 pos << ia; 1201 pos << ia; // (2) Only a reference to the previously ia array is written 1003 1202 ia = 32; 1004 1203 ia.RenewObjId(); // We change the object Id 1005 pos << ia; 1204 pos << ia; // (3) The complete array is dumped again 1006 1205 } 1007 1206 \end{verbatim} … … 1097 1296 \item[\bul] Functions returning arrays corresponding to real and imaginary 1098 1297 parts of a complex array: {\tt real(za) , imag(za) } 1099 ({\bf Warning:} Note that the these functions do not provide 1100 shared memory access to real and imaginary parts.) 1298 ({\bf Warning:} Note that the these functions create an array and copies 1299 the data from the original complex array. They do not provide 1300 shared memory access to real and imaginary parts. 1301 For shared memory access, use functions {\tt SDRealPart()} and 1302 {\tt SDImagPart() } (see below). 1101 1303 \item[\bul] Functions returning arrays corresponding to the module, 1102 1304 phase, and module squared of a complex array: … … 1155 1357 TArray<r_4> aza = ArrCastC2R(za); 1156 1358 cout << " za --> aza= " << aza; 1359 TArray< complex<r_4> > zb; 1360 zb = ArrCastR2C(aza); 1361 KeepObj(zb); 1157 1362 \end{verbatim} 1158 1363 … … 1164 1369 The first index is along the X axis and the second index along the Y axis. 1165 1370 \begin{verbatim} 1166 | (0,0) ( 0,1) (0,2) (0,3) |1167 | ( 1,0) (1,1) (1,2) (1,3) |1168 | ( 2,0) (2,1) (2,2) (2,3) |1371 | (0,0) (1,0) (2,0) (3,0) | 1372 | (0,1) (1,1) (2,1) (3,1) | 1373 | (0,2) (1,2) (2,2) (3,2) | 1169 1374 \end{verbatim} 1170 1375 In the first case, the array is completely packed … … 1196 1401 1197 1402 \begin{verbatim} 1403 BaseArray::SetDefaultMemoryMapping(BaseArray::CMemoryMapping); 1198 1404 TArray<r_4> X(4,2); 1199 1405 X = RegularSequence(1,1); 1200 1406 cout << "Array X= " << X << endl; 1201 TMatrix<r_4> X_C(X, true , BaseArray::CMemoryMapping);1407 TMatrix<r_4> X_C(X, true); 1202 1408 cout << "Matrix X_C (CMemoryMapping) = " << X_C << endl; 1203 TMatrix<r_4> X_F(X, true, BaseArray::FortranMemoryMapping); 1409 TMatrix<r_4> X_F(X_C, true); 1410 X_F.TransposeSelf(); // we make it a FortranMemoryMapping matrix 1204 1411 cout << "Matrix X_F (FortranMemoryMapping) = " << X_F << endl; 1205 1412 \end{verbatim} … … 1223 1430 4, 8 1224 1431 \end{verbatim} 1432 1433 {\bf Note:} Only the {\tt TMatrix} class is sensitive to the memory organisation. It should also 1434 be noted that the first index for a matrix is the row index. For a {\tt TArray} object, the first 1435 index correspond always to the X axis. For a matrix in the {\tt CMemoryMapping}, the row 1436 index is the Y index of the corresponding array, while for a matrix 1437 with {\tt FortranMemoryMapping}, the row index is the X index. 1438 \begin{verbatim} 1439 # 2D array arr , matrix mx 1440 TArray<r_4> arr; 1441 ... 1442 TMatrix<r_4> mx(arr); 1443 ... 1444 ### CMemoryMapping : 1445 mx( row , col ) -> arr( ix=col, jy= row ) 1446 ### FortranMemoryMapping : 1447 mx( row , col ) -> arr( ix=row, jy= col ) 1448 \end{verbatim} 1449 The following code fragment shows the difference between element access 1450 index order for the different memory organisation: 1451 \begin{verbatim} 1452 TArray<int_4> a(5,3); 1453 a = RegularSequence(10,2); 1454 cout << "Array a = " << a << endl; 1455 TMatrix<r_4> mac(a); 1456 cout << "Matrix mac (CMemoryMapping) = " << mac << endl; 1457 TMatrix<r_4> maf(mac); 1458 maf.TransposeSelf(); // we make it a FortranMemoryMapping matrix 1459 cout << "Matrix maf (FortranMemoryMapping) = " << maf << endl; 1460 // ---- element access 1461 cout << " Array(ix,jy) : a(2,0)= " << a(2,0) << " a(1,2)= " << a(1,2) 1462 << " a(0,2)= " << a(0,2) << endl; 1463 cout << " mac(row,col) : mac(2,0)= " << mac(2,0) << " mac(1,2)= " << mac(1,2) 1464 << " mac(0,2)= " << mac(0,2) << endl; 1465 cout << " maf(row,col) : maf(2,0)= " << maf(2,0) << " maf(1,2)= " << maf(1,2) 1466 << " maf(0,2)= " << maf(0,2) << endl; 1467 \end{verbatim} 1468 1225 1469 1226 1470 \newpage … … 1434 1678 1435 1679 \subsection{Writing, viewing \dots } 1436 1437 All these objects have been design to be written to or read from a persistent file. 1680 %% 1681 Histogram and NTuple/DataTable objects have PPF handlers and 1682 can be written to or read from PPF files. Sophya graphical tool (spiapp) can 1683 automatically display and operate on all these objects. 1438 1684 The following example shows how to write the previously created objects 1439 1685 into such a file~: 1440 1686 \begin{verbatim} 1441 //-- Writing1442 1687 { 1443 1688 char *fileout = "myfile.ppf"; … … 1449 1694 } // closing ``}'' destroy ``outppf'' and automatically close the file ! 1450 1695 \end{verbatim} 1451 1452 Sophya graphical tools (spiapp) can automatically display and operate1453 all these objects.1454 1696 1455 1697 \newpage … … 1702 1944 The classes {\bf ZMutex} \index{mutex} and {\bf ZSync} can be used 1703 1945 to perform synchronisation and signaling between threads. 1704 1946 Example multithread programs using these classes can be found in 1947 the {\bf Tests} module : \\ 1948 \hspace{10mm} {\tt zthr.cc , tmtdt.cc , tmtrnd.cc } 1949 1705 1950 \subsection{Dynamic linker and C++ compiler classes} 1706 1951 \index{PDynLinkMgr} … … 1743 1988 1744 1989 \subsection{Command interpreter} 1990 \index{Commander} 1991 \index{Expression evaluation} 1745 1992 The class {\bf Commander} can be used in interactive programs to provide 1746 1993 c-shell like command interpreter and scripting capabilties. 1747 1994 Arithmetic expression evaluation is implemented through the {\bf CExpressionEvaluator} 1748 and {\bf RPNExpressionEvaluator} classes. 1995 and {\bf RPNExpressionEvaluator} classes. The latter can be used to perform evaluation 1996 in reverse polish notation (old HP calculators), 1997 while the former uses the usual algebraic (c-language like) expressions. 1749 1998 The command language provides variable manipulation through the usual 1750 1999 {\tt \$varname} vector variable and arithmetic expression extensions, as well … … 1772 2021 \end{figure} 1773 2022 The {\bf SkyMap} module provides classes for creating, filling, reading pixelized spherical and 2D-maps. The types of values stored in pixels can be int, float, double , complex etc. according to the specialization of the template type. 2023 \subsection{3D geometry} 2024 Some of the classes in this module simplify the angle manipulation, or the 3D geometry 2025 and rotation calculations, such as the {\bf Vector3d} and {\bf UnitVector} classes. 2026 \index{Vector3d} 2027 The classes {\bf Vector3d} and {\bf UnitVector} are useful for angle conversions. 2028 \index{Angle} 2029 {\bf LongLat} class and {\bf Angle} class (defined in file vector3d.h) can be used for 2030 angle conversions : 2031 \begin{verbatim} 2032 // Example to convert 0.035 radians to arcsec 2033 double vr = 0.035; 2034 cout << "Angle rad= " << vr << " ->arcsec= " << Angle(vr).ToArcSec() << endl; 2035 // Example to convert 2.3 arcmin to radian - we use the conversion operator 2036 double vam = 2.3; 2037 cout << "Angle arcmin= " << vam << " ->rad= " 2038 << (double)Angle(vam, Angle::ArcMin) << endl; 2039 \end{verbatim} 2040 %%% 1774 2041 \subsection {Spherical maps} 1775 2042 SkyMap module provides three kinds of complete ($4 \pi$) spherical maps according to the … … 2113 2380 The {\bf FFTWServer} class (in module FFTW) implements FFTServerInterface class 2114 2381 methods, for one dimensional and multi-dimensional Fourier 2115 transforms on double precision data using the FFTW package 2116 (available from {\tt http://www.fftw.org}). 2382 transforms using the FFTW package (available from {\tt http://www.fftw.org}). 2383 Depending on the configuration options during library build, only 2384 transforms on double precision data might be available. 2117 2385 2118 2386 \newpage … … 2393 2661 \input{ex1.inc} 2394 2662 2395 2396 2663 \newpage 2397 2664 \addcontentsline{toc}{section}{Index}
Note:
See TracChangeset
for help on using the changeset viewer.