Making Information Sources Available for a New Market in an Electronic Commerce Environment
Sebastian Pulkowski
University Library &
Institute for Program Structures and Data Organization
Universit?t Karlsruhe
D-76128 Karlsruhe, Germany
Tel.: +49-721-608-4065
Fax.: +49-721-608-7343
E-mail: pulkowsk@https://www.doczj.com/doc/df1767460.html,a.de
Abstract
Literature search and delivery in the World Wide Web is a rapidly expanding market. Up to now the search is mostly cost-free. But in the future we expect the appearance of more and more providers charging for their services. The main problems are finding the right provider and extracting the information. In this paper we present a system for intelligent information search and extraction from multiple provider’s Web sites. One important part of the system is the so-called wrapper. In this paper, we present the architecture of these wrappers. Their task is the translation of a customer’s query into the sources syntax and the re-translation of the answer. Applying these wrappers in an electronic commerce environment needs additional functionality, e.g., navigation through a providers site, collection of the information the customer desires or pre-calculation of costs. Because of the variety of the sources functionality, we need a flexible and individually built wrapper. This could be achieved using a modular concept.
1 Introduction
The World Wide Web can be seen as one big virtual library. Information about documents or even the documents themselves in electronic format can be found for nearly every subject area. Literature search and delivery is a rapidly expanding market. Today, almost all booksellers and publishers place their offers on the Internet, and intermediaries that catalogue and index documents for search assist users in the retrieval of relevant information. Almost all of these do so to make a profit and, consequently, charge users and/or providers for their services. Most of these providers offer information about the documents (even now) without charging. They sell the books or documents only. But in the future more and more so-called research-centers like the Fachinformationszentrum Karlsruhe [FIZ] will arise on the market. They exclusively offer databases for specific areas. Here, a user must pay for both search and delivery. In future, it is expected that even university libraries, where at the moment the search is for free, will charge for the service of literature search.
Despite the wealth of offers, virtual libraries suffer from severe shortcomings: Each service must be individually known to the user and it is up to the user to find the most suitable ones and to combine them into a search and delivery process that meets his or her needs. To navigate the bewildering array of services and to make efficient use of the developing information market, the user needs support in locating, assessing and using information providers. This opens up an opportunity for systems that provide “one-stop-shopping” for electronic documents by transparently selecting, negotiating with, and combining providers to obtain the best possible deal for the user. In this process the reduction of costs represents a new challenge. The two main problems are that costs of several sources will arise in parallel making it hard for the user to keep track of them, and that costs are unknown until they arise. At this point of time it is too late to stop the search.
The UniCats1 project at the University of Karlsruhe attempts to meet this goal of information provision by employing a federation architecture based on user agents,
1 UniCats stands for: a UNiversal Integration of Catalogues based on an Agent-supported Trading and wrapping System
traders and wrappers. User agents interpret, augment and execute search and retrieval requests of human users, based on policies and preferences kept in user profiles. Traders assist user agents in the selection of suitable information sources by maintaining metadata about these sources such as content and service fees.
Wrappers, which are the subject of this paper, adapt information sources so that user agents and traders can work as desired. They are responsible for executing user requests by utilizing the source's query facilities and translating results back into the format expected by the user agent. Two important aspects in this process are the translation of a user query into a sequence of navigation and retrieval steps executed against the source and the estimation and limitation of the resulting costs. This search functionality is essential, because user agents assume that requests are executed atomically and with a predictable cost, whereas most information sources require a multi-stage search involving several HTML pages. Fees may depend on the output of previous stages. This paper describes the architecture of wrappers that navigate autonomously in an information source without violating cost limits, following the instructions from the user agent. Cost calculation is based on metadata. This makes it possible to warn the user if the cost limit is too low, so that he/she may cancel the request before the price gets even higher.
The paper is organized as follows: We begin in section 2 by introducing the UniCats system, its architecture and the components. The following section describes the heterogeneity of information sources and the tasks of a wrapper especially under consideration of providers in an electronic commerce environment. Thereafter, we show our concept of a powerful wrapper to access these source before the wrapper and its architecture are described. Related work appears in Section 5, and we conclude and present future work in Section 6.
2 The UniCats Environment
To cope with the open, heterogeneous, and non-transparent market, we need a flexible architecture. It must be open for modifications and extensions and independent from concrete computer platforms. The interfaces towards the customer and the providers
must be designed variably and individually, so that a maximum number of providers and customers can be served by the system. At the same time, the customer can utilize an interface he/she is used to for the information search. The flexibility of the architecture is guaranteed using three component types, as illustrated in Figure 1.
Provider
Customer Wrapper Trader User Agent Figure 1 : The UniCats architecture
2.1 System components
According to the previous section the integration is managed by three components: an interface component on the customer side, an interface on the provider side and an intermediate component which is responsible for establishing the contact between customer and provider.
The three main components of the UniCats system [Christoffel et al. 1998, 1999] are the user agent at the customer side, the wrapper to include the information provider and finally traders for the intermediation. Their functions and the interaction between them are the following:
User Agent
The function of the user agent is twofold: On the one hand, it offers the customer a uniform interface to transparently access all the heterogeneous information providers, on the other hand, the user agent has to select suitable providers, develop a search plan minimizing the overall costs and integrate the results received from multiple information providers. To find the right provider and to formulate the query as good as possible a profile of the user is collected including languages or level of knowledge in different areas. Additionally, existing logins and accounts are collected, minimizing the customer’s interaction with provider details.
Wrapper
The task of the wrappers is the translation of queries into the special format of the assigned information source and results back from the format of the source into the result format of the UniCats environment. However, they are much more than just simple translators. Wrappers are built individually for an information provider and present the whole spectrum of functions available to the customer, or its user agent, respectively. Other features of the wrapper are cost optimization, query processing and access control. Additionally, metadata about the provider are stored and exported if demanded, e.g., to a trader.
Traders
The traders [Christoffel 1999] operate between the two components mentioned above. They store information about the available service providers. An incoming user demand is matched with existing service offers to find the most appropriate providers for the user query. To calculate the best offer the trader uses profiles in form of metadata collected by the wrappers. To achieve scalability traders are often organized in federations where information is exchanged between participating traders when necessary.
2.2 Component interaction
Figure 1 illustrates the communication principle and information flow inside the UniCats environment. First, the wrapper has to register (1) with one or more traders and has to give them a profile in the form of metadata. Then, the customer submits its query to the user agent (2) which merges the query with the user profile and contacts the trader (3) using this information. The trader returns a list of recommendations for service providers together with additional information available. Thereafter, the user agent addresses the suggested services (4,5), more particularly the wrappers. This can be done in parallel to more than one service provider. The wrappers transform the query into the native query format of the information source and send the re-transformed results back to the user agent.
Then, the results from all the wrappers are collected, integrated in one overall result and displayed to the customer (7). Finally the user agent can give a feedback (8) to the trader about the success of the query, which may be taken into consideration for further requests.
In the future, this open market must include financial transactions (6). So the actual platform is designed in a way that offers a simple way to add components for certifying, accounting, billing and electronic payment.
For the information exchange between the components, we use unique protocol mechanisms and predefined interface declarations. All information (e.g., metadata), requests and results are exchanged using XML. The problem is to hide the heterogeneity of the providers to the system and to apply a uniform query language. The problems arising during the integration of the providers are shown in the next section, before we present a possible solution to the problems with our wrapper model.
3 The Wrapper in an Electronic Commerce Environment
The task of the wrapper is to hide the heterogeneity and the variety of providers from the user agent. In this section, we demonstrate the manifold spectrum of functions of providers and other problems arising while wrapping information sources.
Functional heterogeneity
Because we want to have a wrapper for both conventional providers and providers of an electronic commerce environment, we classify all the providers in four categories and name their characteristics:
-Providers which put online information and documents to the customer’s disposal without charging money. Examples are search engines of university libraries or university institutions which collect lots of papers and documents. In this case, the search and all the information is free and can be seen and downloaded without the requirement of a login or charging for it. Examples for such services are the
NCSTRL- [NCSTRL] or the Liinwww server [LiinWWW].
-The next class of providers offers some of their service only to a restricted group of people, e.g., a university library for its students: Everybody can search in the
catalogues of the university library of Karlsruhe [UBKA] but the reservation or the lending of books is restricted to the students. In this case a login is required. The service is still free.
-Another class of providers require a login before accessing information. The customer has to pay an annual fee for this login. After logging in the customer can download whatever he or she likes. An example for that sort of source is, e.g., the online-server of the Springer publishing company [Springer].
-Finally, a source may require a login and the search for information itself costs money. These costs depend on the actions performed to obtain the requested
information. An example for this class is the Fachinformationszentrum Karlsruhe [FIZ].
These examples show the heterogeneity and variety of provider functions. Of course other combinations of these features can be made and appear on the providers site.
Secure data transmission
At least the last two examples of possible source functionality show a need for a secure data transmission, for example, the customer has to submit logins or information about
his or her credit cards. On the other hand, the provider is certainly interested in submitting the documents only to the customer who pays for it. So the wrapper as an intermediary between the user agent and the information provider has the responsibility of securing data transmission.
Search costs
Another problem that arises from the search in cost-based providers are the fees for the information search. Often these fees depend on the actions performed, the number of documents shown to the customer, the amount of time of the search or even the size of the downloaded files. It is true that some of the providers offer the possibility to obtain a cost information, but this information only covers the costs incurred. No provider will calculate the costs before the action is performed. However, this is desirable to avoid search costs, which is very useful for our scenario. It is even required if we search in parallel in multiple information sources. A precalculation of costs would help the user agent to decide whether to cancel or to continue a search request.
Wrapper location
The next problem is the location of the wrapper. Because of the mass of information sources, we cannot assume that all providers are willing or even capable of creating a wrapper for our UniCats system. So we must have a wrapper which can be run on the provider’s side, at the institution of the customer or even as a third party somewhere in the World Wide Web.
Flexibility of Wrappers
Finally, HTML pages are undergoing drastic changes over the times. An HTML page has an average lifetime of about 3 months. If a page is changing its content and/or the data representation, it is no problem for a user to recognize this change. He or she can react immediately. But in our system a program, the wrapper, is accessing the page and the customer has to pay for the information. Thus, a change must be recognized and the wrapper must be immediately adapted to the new situation because the user is certainly not willing to pay for information of no use. So the wrapper must be able to recognize
the changes and immediately stop the search and to inform the organization running the wrapper. The wrapper must have an architecture which can be easily and rapidly adapted to changes in HTML pages.
4 The UniCats Wrapper
In the previous section, some problems have been discussed which show the importance of a flexible and powerful wrapper. This power has been inserted in our wrapper by using a modular concept:
4.1 Modular Concept
In order to built a wrapper individually for an information provider with the required functions we use the following modular concept: Each functionality is encapsulated into a module. We have divided all possible functions in two groups: Some functions are required for all information providers regardless of the above mentioned classes of providers they belong to. These modules are called basic modules. The other group of functions includes specific functions which are not necessary to all wrappers. They can be inserted into the wrapper using additional modules. With this modular structure we can build a wrapper like with a building set individually for an information provider including a maximum of functionality.
Basic Modules
The basic modules cover query processing and the interaction between the user agent and the provider. They include the following functions:
-connection establishment and termination to the provider;
-validation of customer’s search request to avoid incorrect requests;
-translation of search into the source’s syntax;
-re-transformation of the source’s answer;
-checking for syntactical correctness of results to recognize changes on the HTML pages;
-collection of metadata during the search activity for a better pre-calculation of possible results.
Additional Modules
Which additional modules should be added to the wrapper depends on the characteristics of the source. A module is only loaded into a wrapper if it is required and at the point of time it is required (see below). These modules cover the following functions:
-cost control and administration;
-planning of costs before they arise;
-secure data transmission;
-informing a trader of changes in the providers metadata profile;
-accounting and administration of the session;
-extra login for a wrapper;
-extra charging of money for the wrappers work.
4.2 Module Implementation
The UniCats wrapper is implemented using Java JDK 1.1.3. With the possibility of loading modules during runtime, we can realize the above described concept of including the functions in a modular way. They are only inserted when they are needed; and hence a wrapper for the same source can change from session to session dependent on the user actions. For example, a user who is only searching information about literature in a provider’s database without performing a document delivery can dispense with functions like login or the secure transmission of data. At the moment he or she changes the status from “search” to “delivery”, the necessary modules are added and the full functionality will be available.
In the next section, the modules of the wrapper and their interaction are described by an example of a search in an information source.
4.3 The Architecture
Site
Communication inside the wrapper Communication with external components
Basic Module
Additional Module Figure 2: The architecture of the wrapper
The wrapper architecture is displayed in Figure 2. Query processing begins when the so-called coordination module of the wrapper receives a user agent’s search request.First, the request is checked for syntactical correctness in the validation module . To perform this check, the module needs information about the content and the possible ways to request information. This so-called meta information is stored in a database with other information about the source like number of documents, languages or cost information. If the request is correct, it will be handed over to the planner . The task of the planner is to determine all pages that must be visited to fulfil the search request.This is done by searching a navigation graph. This graph contains a scheme of the
source with all pages, their attributes and additional information. Every relevant page in the providers site will be included into the sources graph. Links between the pages are translated into actions, e.g., following a dynamically generated link to gather
information about a special document. The planner uses on the one hand meta
information about the source, the same which was used during request validation. On the other hand, information about the pages and the content representation in the form of templates is required to extract the information from the result pages. This
information is stored in a second database called page information . Both databases are
created semi-automatically when the wrapper is generated. When the planner creates a navigation plan, the cost for this plan has to be calculated and compared with the user’s conditions and the maximal costs, respectively. This is performed by the cost monitor. If the costs are too high, the search is stopped, the customer is informed, and the wrapper waits for the customer’s decision. For example, this decision could be increasing the cost limit, reducing the required attributes or canceling the search. If there is no conflict after cost calculation, the planner executes the query plan and transmits the search request to the converter. The converter fills out the search forms, follows links to the next pages and finally extracts the information from the provider’s result pages. This is done with the above mentioned page information.
The returned provider result is compared with the expected results in the navigation plan. If not all the required information are collected, the planner begins to re-calculate the plan, checks the expected costs again and finally executes the next part of the plan. If the whole request is performed, the result is finally transmitted back to the user agent by the coordination module. If the customer or the provider wishes a secure data transmission, it is the task of the latter module to appropriately encode the messages.
In the next subsections, the two main modules, the coordination module and the planner, are described shortly.
4.4 The coordination module
The coordination module is very important for the interaction with the user. It is a basic module, which exists in all wrappers. This module calls other modules (not mentioned in the architecture description). In Figure 3, the coordination module is shown with these related modules.
Information flow in non commerce sources
Additional actions in cost based sources Basic Module Additional Module
Figure 3: The coordination module and interacting components
We use XML as data representation language for transmittal of the user’s search request to the wrapper (1) and the results back to the user agent (9). With this common format,the interface to the wrapper is not restricted to UniCats agents and traders, but every other agent or program can use these wrappers. The only condition is the use of our protocol specification and XML as data exchange format. A sample request is shown in Figure 4.
title, author, year, publisher, abstract, document
Figure 4: A sample XML request
This is an example for a query given by a user agent for a cost-based source: The agent wants to search for a document about wrapper generation from the year 1999 and expects as result the following attributes: title, author, year of publication, publishing organization, an abstract and the document itself.
The conditions for the search are a maximum cost of 20$, a maximum of 10 documents and a maximum search time of about 2 minutes. The delivery time has to be at most 3 days.
The request is divided into three parts: The first part includes the attributes and values of the search. In the second part, the customer specifies the attributes he or she expects as results and finally the conditions or restrictions for the search are given.
If the coordination module receives a search request, the data is stored (3) in a session buffer and then sent (4) to the validation module. Here, the request is divided into the three parts. If costs are not considered, the restriction part and the corresponding modules will not be taken into account.
Thereafter, an examination of a possible execution of the request takes place under consideration of the search information given to the user. In many cases the user or
his/her agent does not know the specific requirements of the source to fill out the forms. Here, the wrapper corrects and completes the request automatically. If too much information is missing, the wrapper subsequently demands more detailed attribute specifications by contacting the user agent. If the request is syntactically correct and can be performed without any error, the second part of the request will be taken into consideration: Is it possible to deliver all the required attributes? It could happen that a provider does not offer in the search forms the possibility to search for specific attributes. For example, if a provider has only one single search field for the title, a user query containing an author or a year cannot be performed. Here a post filtering of the result data must be done. This post filtering is not restricted on the final result but must be generated for each page which is dynamically generated by the provider. These filters are individually created (5+6) by a filter generator in dependence of the request and the page with its result attributes. This filtering becomes necessary because of the
search costs: Documents that are not relevant must be excluded out of the result set as fast as possible.
Another problem is the fact that a customer often demands more information about a document than the source can make available. In this case, the wrapper does not execute the request but informs the user agent. Thus, the user is in turn to decide whether to change attributes or abort the search. This guarantees that the customer has never to pay for incomplete information.
Finally, the third part of the request is checked, that is, if all additional information needed, such as logins or cost information, are available. Otherwise, they will be demanded from the customer. In this part the required security level will be checked, too. If a user or the provider demands a secure data transmission (7), they try to find a common security level. Then the wrapper arranges with the customer the part of information which has to be encoded using a special protocol, we have developed. This protocol is described in [Früauf 1999].
If the wrapper requires a login itself, for example, if the user has to pay even for the wrapper’s services, this is being checked (2) before the request validation (see above).
All interactions with the customer or his or her user agent, respectively, is stored in a logging file. Of course, personal data such as logins or passwords are deleted at the moment the user leaves the session. In cost-based information sources a commitment of the search costs is required from the user agent. If no commission takes place, all the data will be stored for a later proof of the performed search actions and the money the user has to pay for them.
The data about the performed actions and some information about the results such as the number of hits, the eventually downloaded documents and the current search costs is stored in a metadata database. During the following requests, this data can be used to optimize the query and pre-calculate expected costs in the planner module.
The Planner
The planner is another basic module. However, this module is much less important for non-commercial sources than it is for cost-based sources. The main task of the planner is the selection of pages, which must be visited to fulfill the customers request using the navigation graph.
Figure 5: A navigation graph for the FIZ Karlsruhe
The navigation graph is a representation of the information source in a graph covering only those pages that are relevant for the search. Figure 5 shows a sample graph of the site-structure of the Fachinformationszentrum Karlsruhe [FIZ]. In this graph the HTML pages are displayed as nodes. The edges of the graph represent links between the pages.
We distinguish three different types of pages: pages that have forms and no further search relevant information, e.g., a login or a simple search form. These pages can be represented without parsing any information by filling in a simple URL only with the parameters. Second, we have pages which include information the customer is searching for or the wrapper needs for its request processing. These pages represent points of decision in the navigational process. During navigation, at these points the conditions,
e.g., the overall costs, always have to be checked. Finally, we have pages which cover only information without any links. An example are pages informing about costs or a page containing an online document.
In the graph three different types of links can be seen. First, a normal link which can be followed without being concerned about costs, for example, the link to the page with the cost information. Second, a link which has additional attributes such as costs, the average time to get the page or a change of the source-URL. This link is very important for the calculation of the expected search costs. Finally, a third link is shown which cannot be found in the source pages. This link is added only in the wrapper to emulate the “Back” button of the web browser. This is a very important feature of the navigation graph and the wrapper and allows us to go in all directions and navigate in the site just like a user does with the Web browser.
The process of planning begins with the navigation through the graph, the dispatch of the login and password and the execution of the initial search query. Then, the results are evaluated and the generated filter for this page will be executed on the result page. Thereafter, the first decision point is reached and the wrapper must decide if the costs and time are still in the customer’s limit. After a positive decision, the next steps are calculated and a new tree is generated with the result page as root and the documents as sub-nodes connected with links. The sub-nodes contain the information delivered by the provider. Then the attributes desired by the customer are checked, and if they are fulfilled, the search ends. If some attributes are missing, a sub-graph will be created for each document-node in the graph, with (still) empty nodes but with the links attributes. Then the overall costs are calculated performing a depth first search and a summarization of the overall costs. If the costs stay under the customer’s limit, the planner begins to follow links until the desired attributes for a document have been found. Then, the costs are checked again and the overall costs are recalculated. This is done with each node, so that the costs for the search can be kept down.
Additionally, the costs for document delivery or costs for downloading a document are included in the calculation, so that the maximum costs given by the customer will not be exceeded. The customer can be sure that the search will be performed automatically and under the conditions which he or she specified at the beginning of the search.
5 Related Work
Querying Web sources and retrieving data from semistructured and structured Web sources has become more and more important and receives attention in the database literature (see [Florescu et al. 1998] for a survey). Several researchers began their work with wrapping relational databases sources, e.g., the TSIMMIS approach in Stanford [Hammer et al. 1997]. But with the growth of the Web and the possibilities of retrieving literature over this new medium, wrappers for semi-structured information sources were built. In addition to these tools, a lot of query languages such as WebSQL [Arocena et al. 1997], WebLog [Lakshamanan et al. 1996], W3QL [Konopnicki et al. 1995] or Florid [Frohn et al. 1997] were developed. These languages offer possibilities to formulate queries on semistructured HTML pages and define rules to extract the information. However, using these languages often requires a long period of time to learn the syntax; often programming skills are required to build a wrapper for one single page. The functionality of navigation through a provider’s site is still missing. Most of them ignore the syntactical structure of HTML pages and consider only the hyper-links included.
The Araneus project [Atzeni et al. 1997] also offers a language to extract relational data from the Web. To do this, the page schemes must be defined in the ARANEUS Data Model (ADM). The language ULIXES is used to navigate within the link structure of the pages and to build relational views over the extracted data. The creation of the wrapper expects the knowledge of the language and of the site structure. Functionality like query planning or an access restriction to parts of the Web site are not provided.
Strudel [Fernandez et al. 1998] is another system which represents the data in Web Sites in a graph representation. But it offers neither electronic commerce functionality nor a generator to construct these wrappers for external Web sites.
Other projects are limited to information extraction, e.g., the InfoExtractor [Hammer et al. 1997], a tool developed by INRIA/Bull, or the Web Extractor [Garcia-Molina, Hammer, Cho et al. 1995], built by the TSIMMIS group at Stanford. They use regular
expressions to analyze the structure and to extract information. But they are limited to single pages and must be user specified for each page individually. With these extraction languages it is difficult to write a wrapper which can deal with small changes on the content of HTML pages.
None of these systems can deal with an optimization of search costs and offers functionalities such as login handling, cost monitoring, or automatic navigation in the source. Moreover, the functionality of planning a search before performing is a very important feature for a wrapper in an electronic commerce environment.
6 Conclusions and Future Work
In this paper, we present a wrapper for an electronic commerce environment. The requirements for such a wrapper include secure data transmission, login functionality and cost control. Because today’s providers differ widely in their functions, the wrapper must be very flexible and individually generated for each source. This can be reached using a modular concept. With this concept, the wrapper can be build like with a building set, each of the modules covers one specific functionality. The main components inside the wrapper are the coordination component, which is responsible for the internal wrapper protocol, and the planner, for planning a cost minimized search. The latter feature is very important for wrappers used in an electronic commerce environment with parallel search in multiple sources having different cost models.
In the future, we want to extend the planning algorithm so, that the metadata collected during a search request could be used to calculate the expected number of results and the costs depending thereby. Thus, it could be possible to stop a search and demand a refinement before the customer pays one single dollar.
Furthermore, it is planned to give the wrapper different search strategies. With these strategies it will be possible for both the provider and the customer itself to build their own wrappers for the same source having different power. Then, competition between different wrapper providers can enrich the electronic information market. Building such a powerful wrapper requires a tool for simple wrapper generation. We developed a
尊重的素材（为人处世） 思路 人与人之间只有互相尊重才能友好相处 要让别人尊重自己，首先自己得尊重自己 尊重能减少人与人之间的摩擦 尊重需要理解和宽容 尊重也应坚持原则 尊重能促进社会成员之间的沟通 尊重别人的劳动成果 尊重能巩固友谊 尊重会使合作更愉快 和谐的社会需要彼此间的尊重 名言 施与人，但不要使对方有受施的感觉。帮助人，但给予对方最高的尊重。这是助人的艺术，也是仁爱的情操。—刘墉 卑己而尊人是不好的，尊己而卑人也是不好的。———徐特立 知道他自己尊严的人，他就完全不能尊重别人的尊严。———席勒 真正伟大的人是不压制人也不受人压制的。———纪伯伦 草木是靠着上天的雨露滋长的，但是它们也敢仰望穹苍。———莎士比亚 尊重别人，才能让人尊敬。———笛卡尔 谁自尊，谁就会得到尊重。———巴尔扎克 人应尊敬他自己，并应自视能配得上最高尚的东西。———黑格尔 对人不尊敬，首先就是对自己的不尊敬。———惠特曼
每当人们不尊重我们时，我们总被深深激怒。然而在内心深处，没有一个人十分尊重自己。———马克·吐温 忍辱偷生的人，绝不会受人尊重。———高乃依 敬人者，人恒敬之。———《孟子》 人必自敬，然后人敬之；人必自侮，然后人侮之。———扬雄 不知自爱反是自害。———郑善夫 仁者必敬人。———《荀子》 君子贵人而贱己，先人而后己。———《礼记》 尊严是人类灵魂中不可糟蹋的东西。———古斯曼 对一个人的尊重要达到他所希望的程度，那是困难的。———沃夫格纳 经典素材 1元和200元 （尊重劳动成果） 香港大富豪李嘉诚在下车时不慎将一元钱掉入车下，随即屈身去拾，旁边一服务生看到了，上前帮他拾起了一元钱。李嘉诚收起一元钱后，给了服务生200元酬金。 这里面其实包含了钱以外的价值观念。李嘉诚虽然巨富，但生活俭朴，从不挥霍浪费。他深知亿万资产，都是一元一元挣来的。钱币在他眼中已抽象为一种劳动，而劳动已成为他最重要的生存方式，他的所有财富，都是靠每天20小时以上的劳动堆积起来的。200元酬金，实际上是对劳动的尊重和报答，是不能用金钱衡量的。 富兰克林借书解怨 （尊重别人赢得朋友）
硕037班 刘文3110038020 2011/4/20交互式多模型仿真与分析IMM算法与GBP算法的比较，算法实现和运动目标跟踪仿真，IMM算法的特性分析 多源信息融合实验报告
交互式多模型仿真与分析 一、 算法综述 由于混合系统的结构是未知的或者随机突变的，在估计系统状态参数的同时还需要对系统的运动模式进行辨识，所以不可能通过建立起一个固定的模型对系统状态进行效果较好的估计。针对这一问题，多模型的估计方法提出通过一个模型集{}(),1,2,,j M m j r == 中不同模型的切换来匹配不同目标的运动或者同一目标不同阶段的运动，达到运动模式的实时辨识的效果。 目前主要的多模型方法包括一阶广义贝叶斯方法（BGP1），二阶广义贝叶斯方法（GPB2）以及交互式多模型方法等（IMM ）。这些多模型方法的共同点是基于马尔科夫链对各自的模型集进行切换或者融合，他们的主要设计流程如下图： M={m1,m2,...mk} K 时刻输入 值的形式 图一 多模型设计方法 其中，滤波器的重初始化方式是区分不同多模型算法的主要标准。由于多模型方法都是基于一个马尔科夫链来切换与模型的，对于元素为r 的模型集{}(),1,2,,j M m j r == ，从0时刻到k 时刻，其可能的模型切换轨迹为 120,12{,,}k i i i k trace k M m m m = ，其中k i k m 表示K-1到K 时刻，模型切换到第k i 个， k i 可取1,2,,r ，即0,k trace M 总共有k r 种可能。再令1 2 1 ,,,,k k i i i i μ+ 为K+1时刻经由轨迹0,k trace M 输入到第1k i +个模型滤波器的加权系数，则输入可以表示为 0,11 2 1 12|,,,,|,,,???k k trace k k k i M k k i i i i k k i i i x x μ++=?∑ 可见轨迹0,k trace M 的复杂度直接影响到算法计算量和存储量。虽然全轨迹的
?哈弗曼编码 A method for the construction of minimum-re-dundancy codes, 耿国华1数据结构1北京:高等教育出版社,2005:182—190 严蔚敏,吴伟民.数据结构(C语言版)[M].北京:清华大学出版社,1997. 冯桂,林其伟,陈东华.信息论与编码技术[M].北京:清华大学出版社,2007. 刘大有,唐海鹰,孙舒杨,等.数据结构[M].北京:高等教育出版社,2001 ?压缩实现 速度要求 为了让它(huffman.cpp)快速运行，同时不使用任何动态库，比如STL或者MFC。它压缩1M数据少于100ms（P3处理器，主频1G）。 压缩过程 压缩代码非常简单，首先用ASCII值初始化511个哈夫曼节点： CHuffmanNode nodes[511]; for(int nCount = 0; nCount < 256; nCount++) nodes[nCount].byAscii = nCount; 其次，计算在输入缓冲区数据中，每个ASCII码出现的频率： for(nCount = 0; nCount < nSrcLen; nCount++) nodes[pSrc[nCount]].nFrequency++; 然后，根据频率进行排序： qsort(nodes, 256, sizeof(CHuffmanNode), frequencyCompare); 哈夫曼树，获取每个ASCII码对应的位序列： int nNodeCount = GetHuffmanTree(nodes); 构造哈夫曼树 构造哈夫曼树非常简单，将所有的节点放到一个队列中，用一个节点替换两个频率最低的节点，新节点的频率就是这两个节点的频率之和。这样，新节点就是两个被替换节点的父
LZ77压缩算法实验报告 一、实验内容 使用C++编程实现LZ77压缩算法的实现。 二、实验目的 用LZ77实现文件的压缩。 三、实验环境 1、软件环境：Visual C++ 6.0 2、编程语言：C++ 四、实验原理 LZ77 算法在某种意义上又可以称为“滑动窗口压缩”，这是由于该算法将一个虚拟的，可以跟随压缩进程滑动的窗口作为术语字典，要压缩的字符串如果在该窗口中出现，则输出其出现位置和长度。使用固定大小窗口进行术语匹配，而不是在所有已经编码的信息中匹配，是因为匹配算法的时间消耗往往很多，必须限制字典的大小才能保证算法的效率；随着压缩的进程滑动字典窗口，使其中总包含最近编码过的信息，是因为对大多数信息而言，要编码的字符串往往在最近的上下文中更容易找到匹配串。 五、LZ77算法的基本流程 1、从当前压缩位置开始，考察未编码的数据，并试图在滑动窗口中找出最长的匹 配字符串，如果找到，则进行步骤2，否则进行步骤3。 2、输出三元符号组( off, len, c )。其中off 为窗口中匹
配字符串相对窗口边 界的偏移，len 为可匹配的长度，c 为下一个字符。然后将窗口向后滑动len + 1 个字符，继续步骤1。 3、输出三元符号组( 0, 0, c )。其中c 为下一个字符。然后将窗口向后滑动 len + 1 个字符，继续步骤1。 六、源程序 /********************************************************************* * * Project description: * Lz77 compression/decompression algorithm. * *********************************************************************/ #include 实验名称：LZSS压缩算法实验报告 一、实验内容 使用Visual 6..0 C++编程实现LZ77压缩算法。 二、实验目的 用LZSS实现文件的压缩。 三、实验原理 LZSS压缩算法是词典编码无损压缩技术的一种。LZSS压缩算法的字典模型使用了自适应的方式，也就是说，将已经编码过的信息作为字典， 四、实验环境 1、软件环境：Visual C++ 6.0 2、编程语言：C++ 五、实验代码 #include -- need byte-swap function for big endian CPU */ #define READ_LE32(X) *(uint32_t *)(X) #define WRITE_LE32(X,Y) *(uint32_t *)(X) = (Y) /* this assumes sizeof(long)==4 */ typedef unsigned long uint32_t; /* text (input) size counter, code (output) size counter, and counter for reporting progress every 1K bytes */ static unsigned long g_text_size, g_code_size, g_print_count; /* ring buffer of size N, with extra F-1 bytes to facilitate string comparison */ static unsigned char g_ring_buffer[N + F - 1]; /* position and length of longest match; set by insert_node() */ static unsigned g_match_pos, g_match_len; /* left & right children & parent -- these constitute binary search tree */ static unsigned g_left_child[N + 1], g_right_child[N + 257], g_parent[N + 1]; /* input & output files */ static FILE *g_infile, *g_outfile; /***************************************************************************** initialize trees *****************************************************************************/ static void init_tree(void) { unsigned i; /* For i = 0 to N - 1, g_right_child[i] and g_left_child[i] will be the right and left children of node i. These nodes need not be initialized. Also, g_parent[i] is the parent of node i. These are initialized to NIL (= N), which stands for 'not used.' For i = 0 to 255, g_right_child[N + i + 1] is the root of the tree for strings that begin with character i. These are initialized to NIL. Note there are 256 trees. */ for(i = N + 1; i <= N + 256; i++) g_right_child[i] = NIL; for(i = 0; i < N; i++) g_parent[i] = NIL; } /***************************************************************************** Inserts string of length F, g_ring_buffer[r..r+F-1], into one of the trees (g_ring_buffer[r]'th tree) and returns the longest-match position and length via the global variables g_match_pos and g_match_len. If g_match_len = F, then removes the old node in favor of the new one, because the old one will be deleted sooner. 谈如何尊重人尊重他人，我们赢得友谊；尊重他人，我们收获真诚；尊重他人，我们自己也 获得尊重；相互尊重，我们的社会才会更加和谐. ——题记 尊重是对他人的肯定，是对对方的友好与宽容。它是友谊的润滑剂，它是和谐的调节器， 它是我们须臾不可脱离的清新空气。“主席敬酒，岂敢岂敢？”“尊老敬贤，应该应该！”共和 国领袖对自己老师虚怀若谷，这是尊重；面对许光平女士，共和国总理大方的叫了一 声“婶婶”，这种和蔼可亲也是尊重。 尊重不仅会让人心情愉悦呼吸平顺，还可以改变陌生或尖锐的关系，廉颇和蔺相如便是 如此。将相和故事千古流芳:廉颇对蔺相如不满，处处使难，但蔺相如心怀大局，对廉颇相 当的尊重，最后也赢得了廉颇的真诚心，两人结为好友，共辅赵王，令强秦拿赵国一点办法 也没有。蔺相如与廉颇的互相尊重，令得将相和的故事千百年令无数后人膜拜。 现在，给大家举几个例子。在美国，一个颇有名望的富商在散步 时，遇到一个瘦弱的摆地摊卖旧书的年轻人，他缩着身子在寒风中啃着发霉的面包。富 商怜悯地将8美元塞到年轻人手中，头也不回地走了。没走多远，富商忽又返回，从地摊上 捡了两本旧书，并说：“对不起，我忘了取书。其实，您和我一样也是商人！”两年后，富商 应邀参加一个慈善募捐会时，一位年轻书商紧握着他的手，感激地说：“我一直以为我这一生 只有摆摊乞讨的命运，直到你亲口对我说，我和你一样都是商人，这才使我树立了自尊和自 信，从而创造了今天的业绩??”不难想像，没有那一 句尊重鼓励的话，这位富商当初即使给年轻人再多钱，年轻人也断不会出现人生的巨变， 这就是尊重的力量啊 可见尊重的量是多吗大。大家是不是觉得一个故事不精彩，不够明确尊重的力量，那再 来看下一个故事吧！ 一家国际知名的大企业，在中国进行招聘，招聘的职位是该公司在中国的首席代表。经 过了异常激烈的竞争后，有五名年轻人，从几千名应聘者中脱颖而出。最后的胜出者，将是 这五个人中的一位。最后的考试是一场面试，考官们都 作文话题素材之为人处世篇：尊重 思路 人与人之间只有互相尊重才能友好相处 要让别人尊重自己，首先自己得尊重自己 尊重能减少人与人之间的摩擦 尊重需要理解和宽容 尊重也应坚持原则 尊重能促进社会成员之间的沟通 尊重别人的劳动成果 尊重能巩固友谊 尊重会使合作更愉快 和谐的社会需要彼此间的尊重 名言 施与人，但不要使对方有受施的感觉。帮助人，但给予对方最高的尊重。这是助人的艺 术，也是仁爱的情操。———刘墉 卑己而尊人是不好的，尊己而卑人也是不好的。———徐特立 知道他自己尊严的人，他就完全不能尊重别人的尊严。———席勒 真正伟大的人是不压制人也不受人压制的。———纪伯伦 草木是靠着上天的雨露滋长的，但是它们也敢仰望穹苍。———莎士比亚 多媒体数据压缩实验报告 篇一：多媒体实验报告_文件压缩 课程设计报告 实验题目：文件压缩程序 姓名：指导教师：学院：计算机学院专业：计算机科学与技术学号： 提交报告时间：20年月日 四川大学 一，需求分析： 有两种形式的重复存在于计算机数据中，文件压缩程序就是对这两种重复进行了压 缩。 一种是短语形式的重复，即三个字节以上的重复，对于这种重复，压缩程序用两个数字：1.重复位置距当前压缩位置的距离；2.重复的长度，来表示这个重复，假设这两个数字各占一个字节，于是数据便得到了压缩。 第二种重复为单字节的重复，一个字节只有256种可能的取值，所以这种重复是必然的。给 256 种字节取值重新编码，使出现较多的字节使用较短的编码，出现较少的字节使用较长的编码，这样一来，变短的字节相对于变长的字节更多，文件的总长度就会减少，并且，字节使用比例越不均 匀，压缩比例就越大。 编码式压缩必须在短语式压缩之后进行，因为编码式压缩后，原先八位二进制值的字节就被破坏了，这样文件中短语式重复的倾向也会被破坏（除非先进行解码）。另外，短语式压缩后的结果：那些剩下的未被匹配的单、双字节和得到匹配的距离、长度值仍然具有取值分布不均匀性，因此，两种压缩方式的顺序不能变。 本程序设计只做了编码式压缩，采用Huffman编码进行压缩和解压缩。Huffman编码是一种可变长编码方式，是二叉树的一种特殊转化形式。编码的原理是：将使用次数多的代码转换成长度较短的代码，而使用次数少的可以使用较长的编码，并且保持编码的唯一可解性。根据 ascii 码文件中各 ascii 字符出现的频率情况创建 Huffman 树，再将各字符对应的哈夫曼编码写入文件中。同时，亦可根据对应的哈夫曼树，将哈夫曼编码文件解压成字符文件. 一、概要设计： 压缩过程的实现: 压缩过程的流程是清晰而简单的: 1. 创建 Huffman 树 2. 打开需压缩文件 3. 将需压缩文件中的每个 ascii 码对应的 huffman 编码按 bit 单位输出生成压缩文件压缩结束。 价值工程 置，是一项十分有意义的工作。另外恶意代码的检测和分析是一个长期的过程，应对其新的特征和发展趋势作进一步研究，建立完善的分析库。 参考文献： [1]CNCERT/CC.https://www.doczj.com/doc/df1767460.html,/publish/main/46/index.html. [2]LO R,LEVITTK,OL SSONN R.MFC:a malicious code filter [J].Computer and Security,1995,14(6):541-566. [3]KA SP ER SKY L.The evolution of technologies used to detect malicious code [M].Moscow:Kaspersky Lap,2007. [4]LC Briand,J Feng,Y Labiche.Experimenting with Genetic Algorithms and Coupling Measures to devise optimal integration test orders.Software Engineering with Computational Intelligence,Kluwer,2003. [5]Steven A.Hofmeyr,Stephanie Forrest,Anil Somayaji.Intrusion Detection using Sequences of System calls.Journal of Computer Security Vol,Jun.1998. [6]李华,刘智,覃征,张小松.基于行为分析和特征码的恶意代码检测技术[J].计算机应用研究，2011，28（3）：1127-1129. [7]刘威，刘鑫，杜振华.2010年我国恶意代码新特点的研究.第26次全国计算机安全学术交流会论文集，2011，（09）. [8]IDIKA N,MATHUR A P.A Survey of Malware Detection Techniques [R].Tehnical Report,Department of Computer Science,Purdue University,2007. 0引言 现有的压缩算法有很多种，但是都存在一定的局限性，比如：LZw [1]。主要是针对数据量较大的图像之类的进行压缩，不适合对简单报文的压缩。比如说，传输中有长度限制的数据，而实际传输的数据大于限制传输的数据长度，总体数据长度在100字节左右，此时使用一些流行算法反而达不到压缩的目的，甚至增大数据的长度。本文假设该批数据为纯数字数据，实现压缩并解压缩算法。 1数据压缩概念 数据压缩是指在不丢失信息的前提下，缩减数据量以减少存储空间，提高其传输、存储和处理效率的一种技术方法。或按照一定的算法对数据进行重新组织，减少数据的冗余和存储的空间。常用的压缩方式[2,3]有统计编码、预测编码、变换编码和混合编码等。统计编码包含哈夫曼编码、算术编码、游程编码、字典编码等。 2常见几种压缩算法的比较2.1霍夫曼编码压缩[4]：也是一种常用的压缩方法。其基本原理是频繁使用的数据用较短的代码代替，很少使用 的数据用较长的代码代替，每个数据的代码各不相同。这些代码都是二进制码，且码的长度是可变的。 2.2LZW 压缩方法[5,6]：LZW 压缩技术比其它大多数压缩技术都复杂，压缩效率也较高。其基本原理是把每一个第一次出现的字符串用一个数值来编码，在还原程序中再将这个数值还成原来的字符串，如用数值0x100代替字符串ccddeee"这样每当出现该字符串时，都用0x100代替，起到了压缩的作用。 3简单报文数据压缩算法及实现 3.1算法的基本思想数字0-9在内存中占用的位最 大为4bit ， 而一个字节有8个bit ，显然一个字节至少可以保存两个数字，而一个字符型的数字在内存中是占用一个字节的，那么就可以实现2:1的压缩，压缩算法有几种，比如，一个自己的高四位保存一个数字，低四位保存另外一个数字，或者，一组数字字符可以转换为一个n 字节的数值。N 为C 语言某种数值类型的所占的字节长度，本文讨论后一种算法的实现。 3.2算法步骤 ①确定一种C 语言的数值类型。 —————————————————————— —作者简介：安建梅（1981-），女，山西忻州人，助理实验室，研究方 向为软件开发与软交换技术；季松华（1978-），男，江苏 南通人，高级软件工程师，研究方向为软件开发。 数据快速压缩算法的研究以及C 语言实现 The Study of Data Compression and Encryption Algorithm and Realization with C Language 安建梅①AN Jian-mei ；季松华②JI Song-hua （①重庆文理学院软件工程学院，永川402160；②中信网络科技股份有限公司，重庆400000）（①The Software Engineering Institute of Chongqing University of Arts and Sciences ，Chongqing 402160，China ； ②CITIC Application Service Provider Co.，Ltd.，Chongqing 400000，China ） 摘要：压缩算法有很多种，但是对需要压缩到一定长度的简单的报文进行处理时，现有的算法不仅达不到目的，并且变得复杂， 本文针对目前一些企业的需要，实现了对简单报文的压缩加密，此算法不仅可以快速对几十上百位的数据进行压缩，而且通过不断 的优化，解决了由于各种情况引发的解密错误，在解密的过程中不会出现任何差错。 Abstract:Although,there are many kinds of compression algorithm,the need for encryption and compression of a length of a simple message processing,the existing algorithm is not only counterproductive,but also complicated.To some enterprises need,this paper realizes the simple message of compression and encryption.This algorithm can not only fast for tens of hundreds of data compression,but also,solve the various conditions triggered by decryption errors through continuous optimization;therefore,the decryption process does not appear in any error. 关键词：压缩；解压缩；数字字符；简单报文Key words:compression ；decompression ；encryption ；message 中图分类号：TP39文献标识码：A 文章编号：1006-4311（2012）35-0192-02 ·192· 尊重他人的写作素材 导读：——学生最需要礼貌 著名数学家陈景润回厦门大学参加 60 周年校庆，向欢迎的人们说的第一句话是：“我非常高兴回到母校，我常常怀念老师。”被人誉为“懂得人的价值”的著名经济学家、厦门大学老校长王亚南，曾经给予陈景润无微不至的关心和帮助。陈景润重返母校，首先拜访这位老校长。校庆的第三天，陈景润又出现在向“哥德巴赫猜想”进军的启蒙老师李文清教授家中，陈景润非常尊重和感激他。他还把最新发表的数学论文敬送李教授审阅，并在论文扉页上工工整整写了以下的字：“非常感谢老师的长期指导和培养——您的学生陈景润。”陈景润还拜访了方德植教授，方教授望着成就斐然而有礼貌的学生，心里暖暖的。 ——最需要尊重的人是老师 周恩来少年时在沈阳东关模范学校读书期间 , 受到进步教师高盘之的较大影响。他常用的笔名“翔宇”就是高先生为他取的。周恩来参加革命后不忘师恩 , 曾在延安答外国记者问时说：“少年时代我在沈阳读书 , 得山东高盘之先生教诲与鼓励 , 对我是个很大的 促进。” 停奏抗议的反思 ——没有礼仪就没有尊重 孔祥东是著名的钢琴演奏家。 1998 年 6 月 6 日晚，他在汕头 举办个人钢琴独奏音乐会。演出之前，节目主持人再三强调，场内观众不要随意走动，关掉 BP 机、手提电话。然而，演出的过程中，这种令人遗憾的场面却屡屡发生：场内观众随意走动， BP 机、手提电话响声不绝，致使孔祥东情绪大受干扰。这种情况，在演奏舒曼作品时更甚。孔祥东只好停止演奏，静等剧场安静。然而，观众还误以为孔祥东是在渴望掌声，便报以雷鸣般的掌声。这件事，令孔祥东啼笑皆非。演出结束后，孔祥东说：有个 BP 机至少响了 8 次，观众在第一排来回走动，所以他只得以停奏抗议。 “礼遇”的动力 ——尊重可以让人奋发 日本的东芝公司是一家著名的大型企业，创业已经有 90 多年的历史，拥有员工 8 万多人。不过，东芝公司也曾一度陷入困境，土光敏夫就是在这个时候出任董事长的。他决心振兴企业，而秘密武器之一就是“礼遇”部属。身为偌大一个公司的董事长，他毫无架子，经常不带秘书，一个人步行到工厂车间与工人聊天，听取他们的意见。更妙的是，他常常提着酒瓶去慰劳职工，与他们共饮。对此，员工们开始都感到很吃惊，不知所措。渐渐地，员工们都愿意和他亲近，他赢得了公司上下的好评。他们认为，土光董事长和蔼可亲，有人情味，我们更应该努力，竭力效忠。因此，土光上任不久，公司的效益就大力提高，两年内就把亏损严重、日暮途穷的公司重新支撑起来，使东芝成为日本最优秀的公司之一。可见，礼，不仅是调节领导层之间关 压缩编码算法设计与实现实验报告 一、实验目的：用C语言或C++编写一个实现Huffman编码的程序，理解对数据进行无损压缩的原理。 二、实验内容：设计一个有n个叶节点的huffman树，从终端读入n个叶节 点的权值。设计出huffman编码的压缩算法，完成对n个节点的编码，并写出程序予以实现。 三、实验步骤及原理： 1、原理：Huffman算法的描述 (1)初始化，根据符号权重的大小按由大到小顺序对符号进行排序。 (2)把权重最小的两个符号组成一个节点， (3)重复步骤2，得到节点P2，P3，P4……，形成一棵树。 (4)从根节点开始顺着树枝到每个叶子分别写出每个符号的代码 2、实验步骤： 根据算法原理，设计程序流程，完成代码设计。 首先，用户先输入一个数n，以实现n个叶节点的Huffman 树； 之后，输入n个权值w[1]~w[n]，注意是unsigned int型数值； 然后，建立Huffman 树； 最后，完成Huffman编码。 四、实验代码：#include int min(HuffmanTree t,int i) { int j,flag; unsigned int k = MAX; for(j=1;j<=i;j++) if(t[j].parent==0&&t[j].weight 尊重_议论文素材 "礼遇"的动力 --尊重可以让人奋发 日本的东芝公司是一家著名的大型企业，创业已经有90 多年的历史，拥有员工8 万多人。不过，东芝公司也曾一度陷入困境，土光敏夫就是在这个时候出任董事长的。他决心振兴企业，而秘密武器之一就是"礼遇"部属。身为偌大一个公司的董事长，他毫无架子，经常不带秘书，一个人步行到工厂车间与工人聊天，听取他们的意见。更妙的是，他常常提着酒瓶去慰劳职工，与他们共饮。对此，员工们开始都感到很吃惊，不知所措。渐渐地，员工们都愿意和他亲近，他赢得了公司上下的好评。他们认为，土光董事长和蔼可亲，有人情味，我们更应该努力，竭力效忠。因此，土光上任不久，公司的效益就大力提高，两年内就把亏损严重、日暮途穷的公司重新支撑起来，使东芝成为日本最优秀的公司之一。可见，礼，不仅是调节领导层之间关系的纽带，也是调节上下级之间关系，甚至和一线工人之间关系的纽带。世界知识产权日 --尊重知识 在2000 年10 月召开的世界知识产权组织第35 届成员国大会上，我国提议将 4 月26 日定为"世界知识产权日"。这个提案经世界知识产权组织成员国大会得到了确定。2001 年4 月26 日成为第一个"世界知识产权日"。这是我国尊重知识的具体表现。 屠格涅夫与乞丐 --尊重比金钱更重要 俄罗斯文豪屠格涅夫一日在镇上散步，路边有一个乞丐伸手向他讨钱。他很想有所施与，从口袋掏钱时才知道没有带钱袋。见乞丐的手伸得高高地等着，屠格涅夫面有愧色，只好握着乞丐的手说："对不起，我忘了带钱出来。"乞丐笑了，含泪说："不，我宁愿接受您的握手。" 孙中山尊重护士 --尊重不分社会地位 有一天，孙中山先生病了，住院治疗。当时，孙中山已是大总统、大元帅了。但是，他对医务人员很尊重，对他们讲话很谦逊。平时，无论是早晨或是晚间，每当接到护士送来的药品，他总是微笑着说声"谢谢您"，敬诚之意溢于言辞。 1925 年孙中山患肝癌，弥留之际，当一位护理人员为他搬掉炕桌时，孙中山先生安详地望着她，慈祥地说："谢谢您，您的工作太辛苦了，过后您应该好好休息休息，这阵子您太辛苦了! "听了这话，在场的人都泣不成声。 毛泽东敬酒 --敬老尊贤是一种美德 1959 年6 月25 日，毛泽东回到离别30 多年的故乡韶山后，请韶山老人毛禹珠来吃饭，并特地向他敬酒。毛禹珠老人说："主席敬酒，岂敢岂敢! "毛泽东接着说："敬老尊贤，应该应该。" 周恩来不穿拖鞋接待外宾 --衣着整齐体现对人的尊重 周恩来晚年病得很重，由于工作的需要，他还要经常接待外宾。后来，他病得连脚都肿起来了，原先的皮鞋、布鞋都不能穿，他只能穿着拖鞋走路，可是，有些重要的外事活动，他还是坚持参加。他身边的工作人员出于对总理的爱护和关心，对他说："您就穿着拖鞋接待外 交互式多模型算法卡尔曼滤波仿真 1 模型建立 分别以加速度u=0、1、2代表三个不同的运动模型 状态方程x(k+1)=a*x(k)+b*w(k)+d*u 观察方程z(k)=c*x(k)+v(k) 其中，a=[1 dt;0 1],b=[dt^2/2;dt],d=[dt^2/2;dt],c=[1 0] 2 程序代码 由两个功能函数组成，imm_main用来实现imm 算法，move_model1用来生成仿真数据，初始化运动参数 function imm_main %交互式多模型算法主程序 %初始化有关参数 move_model %调用运动模型初始化及仿真运动状态生成函数 load movedata %调入有关参数初始值（a b d c u position velocity pmeas dt tg q r x_hat p_var） p_tran=[0.8 0.1 0.1;0.2 0.7 0.1;0.1 0.2 0.7];%转移概率 p_pri=[0.1;0.6;0.3];%模型先验概率 n=1:2:5; %提取各模型方差矩阵 k=0; %记录仿真步数 like=[0;0;0];%视然函数 x_hat_hat=zeros(2,3);%三模型运动状态重初始化矩阵 u_=zeros(3,3);%混合概率矩阵 c_=[0;0;0];%三模型概率更新系数 %数据保存有关参数初始化 phat=[];%保存位置估值 vhat=[];%保存速度估值 xhat=[0;0];%融合和运动状态 z=0;%量测偏差（一维位置） pvar=zeros(2,2);%融合后估计方差 for t=0:dt:tg; %dt为为仿真步长；tg为仿真时间长度 k=k+1;%记录仿真步数 ct=0; %三模型概率更新系数 c_max=[0 0 0];%混合概率规范系数 p_var_hat=zeros(2,6);%方差估计重初始化矩阵, %[x_hat_hat p_var_hat]=model_reinitialization(p_tran,p_pri,x_hat,p_var);%调用重初始化函数，进行混合估计，生成三个模型重初始化后的运动状态、方差 %混合概率计算 for i=1:3 u_(i,:)=p_tran(i,:)*p_pri(i); end for i=1:3 c_max=c_max+u_(i,:); end 关于尊重的论点和论据素材 关于尊重的论点 1.尊重需要理解和宽容。 2.尊重也应该坚持原则。 3.尊重知识是社会进步的表现。 4.尊重别人就要尊重别人的劳动。 5.尊重人才是社会发展的需要。 6.人与人之间需要相互尊重。 7.只有尊重别人才会受到别人的尊重。 8.尊重能促进人与人之间的沟通。 9.我们应该养成尊重他人的习惯。 10.对人尊重，常会产生意想不到的善果。 关于尊重的名言 1.仁者必敬人。《荀子》 2.忍辱偷生的人决不会受人尊重。高乃依 3.尊重别人的人不应该谈自己。高尔基 4.尊重别人，才能让人尊敬。笛卡尔 5.谁自尊，谁就会得到尊重。巴尔扎克 6.君子贵人而贱己，先人而后己。《礼记》 7.卑己而尊人是不好的，尊己而卑人也是不好的。徐特立 8.对人不尊敬，首先就是对自己的不尊敬。惠特曼 9.为人粗鲁意味着忘记了自己的尊严。车尔尼雪夫斯基 10.对人不尊敬的人，首先就是对自己不尊重。陀思妥耶夫斯基 11.对于应尊重的事物，我们应当或是缄默不语，或是大加称颂。尼采 12.尊重老师是我们中华民族的传统美德，我们每一个人都不应该忘记。xx 13.尊重劳动、尊重知识、尊重人才、尊重创造。《xx 大报告》 14.对别人的意见要表示尊重。千万别说：你错了。卡耐基 15.尊重人才，培养人才，是通用电器长久不败的法宝。杰克韦尔奇 16.君子之于人也，当于有过中求无过，不当于无过中求有过。程颐 17.施与人，但不要使对方有受施的感觉。帮助人，但给予对方最高的尊重。这是助人的艺术，也是仁爱的情操。刘墉 18.要尊重每一个人，不论他是何等的卑微与可笑。要记住活在每个人身上的是和你我相同的性灵。叔本华 19.要喜欢我们所不尊重的人是很难的;但要喜欢 目 录 实验一用C/C++语言实现游程编码 实验二用C/C++语言实现算术编码 实验三用C/C++语言实现LZW编码 实验四用C/C++语言实现2D-DCT变换13 实验一用C/C++语言实现游程编码 1. 实验目的 1) 通过实验进一步掌握游程编码的原理； 2) 用C/C++语言实现游程编码。 2. 实验要求 给出数字字符，能正确输出编码。 3. 实验内容 现实中有许多这样的图像，在一幅图像中具有许多颜色相同的图块。在这些图块中，许多行上都具有相同的颜色，或者在一行上有许多连续的象素都具有相同的颜色值。在这种情况下就不需要存储每一个象素的颜色值，而仅仅存储一个象素的颜色值，以及具有相同颜色的象素数目就可以，或者存储一个象素的颜色值，以及具有相同颜色值的行数。这种压缩编码称为游程编码，常用(run length encoding，RLE)表示，具有相同颜色并且是连续的象素数目称为游程长度。 为了叙述方便，假定一幅灰度图像，第n行的象素值为： 用RLE编码方法得到的代码为：0@81@38@501@40@8。代码中用黑体表示的数字是游程长度，黑体字后面的数字代表象素的颜色值。例如黑体字50代表有连续50个象素具有相同的颜色值，它的颜色值是8。 对比RLE编码前后的代码数可以发现，在编码前要用73个代码表示这一行的数据，而编码后只要用11个代码表示代表原来的73个代码，压缩前后的数据量之比约为7:1，即压缩比为7:1。这说明RLE确实是一种压缩技术，而且这种编码技术相当直观，也非常经济。RLE所能获得的压缩比有多大，这主要是取决于图像本身的特点。如果图像中具有相同颜色的图像块越大，图像块数目越少，获得的压缩比就越高。反之，压缩比就越小。 译码时按照与编码时采用的相同规则进行，还原后得到的数据与压缩前的数据完全相同。因此，RLE是无损压缩技术。 关于学会尊重的高中作文1000字以上 尊重是一杯清茶，只有真正懂它的人才能忽略它的寡淡，品出它深处的热烈。下面橙子为大家搜集整理有关学会尊重的高中作文，希望可以帮助到大家! 高中作文学会尊重曾经听说这样一个故事： 一位商人看到一个衣衫破烂的铅笔推销员，顿生一股怜悯之情。他不假思索地将10元钱塞到卖铅笔人的手中，然后头也不回地走开了。走了没几步，他忽然觉得这样做不妥，于是连忙返回来，并抱歉地解释说自己忘了取笔，希望不要介意。最后，他郑重其事地说：“您和我一样，都是商人。” 一年之后，在一个商贾云集、热烈隆重的社交场合，一位西装革履、风度翩翩的推销商迎上这位商人，不无感激地自我介绍道：“您可能早已忘记我了，而我也不知道您的名字，但我永远不会忘记您。您就是那位重新给了我自尊和自信的人。我一直觉得自己是个推销铅笔的乞丐，直到您亲口对我说，我和您一样都是商人为止。” 没想到商人这么—句简简单单的话，竟使一个不无自卑的人顿然树立起自尊，使—个处境窘迫的人重新找回了自信。正是有了这种自尊与自信，才使他看到了自己的价值和优势，终于通过努力获得了成功。不难想象，倘若当初没有那么—句尊重鼓励的话，纵然给他几千元也无济于事，断不会出现从自认乞丐到自信自强的巨变，这就是尊1 / 7 重，这就是尊重的力量! 尊重，是—种修养，一种品格，一种对别人不卑不亢的平等相待，一种对他人人格与价值的的充分肯定。任何人都不可能尽善尽美，完美无缺，我们没有理由以高山仰止的目光审视别人，也没有资格用不屑一顾的神情去嘲笑他人。假如别人在某些方面不如自己，我们不能用傲慢和不敬去伤害别人的自尊;假如自己在有些地方不如他人，我们不必以自卑或嫉妒去代替理应有的尊重。一个真正懂得尊重别人的人，必然会以平等的心态、平常的心情、平静的心境，去面对所有事业上的强者与弱者、所有生活中的幸运者与不幸者。 尊重是一缕春风，一泓清泉，一颗给人温暖的舒心丸，一剂催人奋进的强心剂。它常常与真诚、谦逊、宽容、赞赏、善良、友爱相得益彰，与虚伪、狂妄、苛刻、嘲讽、凶恶、势利水火不容。给成功的人以尊重，表明了自己对别人成功的敬佩、赞美与追求;表明了自己对别人失败后的同情、安慰与鼓励。只有要尊重在，就有人间的真情在，就有未来的希望在，就有成功后的继续奋进，就有失败后的东山再起。 尊重不是盲目的崇拜，更不是肉麻的吹捧;不是没有原则的廉价逢迎，更不是没有自卑的低三下四。懂得了尊重别人的重要，并不等于学会了如何尊重别人，从这个意义上说，尊重他人也是一门学问，学会了尊重他人，就学会了尊重自己，也就学会和掌握了人生的一大要义。 2 / 7LZSS压缩算法实验报告
尊重议论文
多媒体数据压缩实验报告
数据快速压缩算法的C语言实现
尊重他人的写作素材
压缩编码算法设计与实现实验报告
尊重_议论文素材
交互式多模型算法卡尔曼滤波仿真
关于尊重的论点和论据素材
数据压缩实验指导书
关于学会尊重的高中作文1000字以上_作文素材
相关主题
文本预览