Contents authors' list error: Reference source not found 9


E. E.Kudriashova, D. P.Panchenko, O. A.Sychev VISUAL GENERATING TEXT SYSTEM "API-BUILDER"



Download 1.06 Mb.
Page36/65
Date07.08.2017
Size1.06 Mb.
1   ...   32   33   34   35   36   37   38   39   ...   65

E. E.Kudriashova, D. P.Panchenko, O. A.Sychev VISUAL GENERATING TEXT SYSTEM "API-BUILDER"

This work have for an object to create a visual generating text system API Builder oriented to work in API Windows.

Nowadays, there are many systems of visual programming, but all of them deal with object-oriented programming. Meanwhile, programming in application program interface (API) has some advantages (small file size, high performance and easy access to additional functions of Windows). The main defects of API programming are the necessity to set window coordinates digitally and to conform to the many patterns. But this is the imperfections of the compilers, not the programming technique. So, combination into one system the easiness for the programmer of visual technology with the efficiency of API Windows will allow to get the better features of these techniques, that was realized in API Builder.

There are six modes of working in API Builder: creating of a form; creating elements of the form; creating of a program text; editing of the program text; editing of the form shape (this mode allows you to create a non-rectangular forms) and creating icons, cursors and pictures for form elements. The automatized system can work with OLE objects, dynamic linked libraries and Windows clipboard.

It is necessary to mark the menu editing system of API Builder. It uses original Windows menu system contrary to majority of modern compilers (Borland C++ 5.02, Microsoft Visual C++ 5.0 etc), that use their own systems, similar to original. Many attempts to build-in the new part into the Windows menu system faile, as the work of the Windows menu system is not documented, but when creating API Builder we managed to solve the problem.

Because of the use of API Windows instead of MFC (or OWL), programs created by API Builder are more fast than the programs created by traditional object-oriented systems. This will allow our system to be a good alternative to the existed systems of visual programming.




V.Karyaev ASSEMBLER LANGUAGES INTERPRETER

The machine-oriented programming is the main form of practical students' activity at studying of different microprocessors functional organization. Traditionally such programming is based on the using of crossassemblers and program simulators. The semantic rupture between the assembler program and machine code is the main fault of such tools using. The assembler programs interpretation is effective way to avoid this rupture.

The expandable assembler programs interpreter realizing the set of assembler languages for different computer architectures was developed in Ulyanovsk State Technical University.

The interpretation is based on the using of internal representation language for assembler programs. With this purpose the program language Slang (the abbreviation of "Stack Language") was developed. The Forth language is the main prototype of Slang.

The interpreter's expandability is achieved by metadescription structure using, allowing to tune the interpreter to concrete assembler language in accordance with given metadescriptions. The special extension of Slang language is used as a metadescription language. This extension allows to describe the computer model, the assembler language syntax and semantic.

So the interpretation processing with the 3 basic stages:

1. The translation of metadescriptions. The computer model and assembler language translator are results of this stage.

2. The translation of assembler programs. The result of this process is reflected in computer model memory image as a set of pointers to Slang-procedures, according to each machine instruction from assembler text sources.

3. The interpretation of translated assembler programs. Contains of step-by-step execution of Slang-procedures pointed by the words from the memory model.

The interpreter (experimental version) was written on the Java language. It is assumed to be accessible in Internet as a Java-applet in future.

The detailed description of technical resolutions underlying the interpreter are given in report. You may contact with the developers of interpreter by e-mail basil@ulstu.ru.


S.V. Galanin THE USE OF PREDICATE PATTERNS IN THE PROBLEM OF DETECTION OF QUESTIONS

The first step in the problem of detection, identification and coding of questions is the confirmation of the truth of facts contained in a text. The confirmation is usually performed as the comparison of facts with the accumulated samples. These facts should be written as subject-predicative forms (SPF). SPF organizes lexemes of some sentence on natural language like Prologue predicate.

The present version of text translation includes 2 following steps:


  1. revealing of the elementary facts and their coding as simple sentences;

  2. translating of each sentence into SPF.

We propose the new version of translation for its effective automation due to the SPF. The new method is based on the construction of the lexemes dependence tree. The rules for trees' construction are well known [2], and this experience permits us to develop an effective computer script for such work.

The novelty of the proposed version is in the revealing of language structures reflecting the facts of existence directly in the dependence trees. Patterns (or templates) help in automation of the search of such constructions and their translation into SPF.

While building the tree, each lexeme (the node) is interpreted as a question or as some speech unit and a sentence part.

Left half of the template is a bracket description of some part of the dependence tree ready for translation. Description of the SPF form and subtree nodes is contained in the right part of the pattern.

The rules of application of patterns for the dependence tree provide parsing of homogenous sentences and their members. Templates also allow more adequate translation of some language constructions, e.g. “Let’s understand A as B”, “That is called C” and etc. Flexibility of the templates mechanism allows us to create templates directly during the parsing for the translation of some special constructions.

References

1. Галанин С.В. Автоматизация процесса подготовки текстов

к предикативной обработке// В сб.: Инофрмационные технологии,

системы и приборы. Ульяновск: УлГТУ, 1998.

2. Севбо И.П. Графическое представление синтаксических структур

и стилистическая диагностика. Киев: Наукова думка, 1981.

3. Соснин П.И. Содержательно-эволюционный подход к искуственному интеллекту. Ульяновск: УлГТУ, 1995.



Directory: confer
confer -> Tilte : a critical examination of the police relations with bbc
confer -> Eavesdropping on a virtuous circle Richard Whately and the Oriel Noetics. Elena Pasquini Douglas uwa business School
confer -> Simulation and Prediction of Storm Surges, Waves, and Morphological Changes due to Tropical Cyclones by Using a pc-based Integrated Coastal Process Model
confer -> Panel 0511 Disability and Difference I: Post-War Journeys through Disability
confer -> Do remittances have a flip side? A general equilibrium analysis of remittances, labor supply responses and policy options for Jamaica* Maurizio Bussolo and Denis Medvedev
confer -> Conference approval process made easy for acm in cooperation conferences
confer ->  Proceedings of gt2009 asme turbo Expo 2009: Power for Land, Sea and Air Orlando, Florida, USA gt2009-59981 dynamics of premixed h2/CH4 flames under near blowoff conditions
confer -> South Korea’s Economic Future: Industrial Policy, or Economic Democracy?
confer -> Asset rotator Cuff Rehabilitation Course Faculty Dr. Spero Karas
confer -> Acm word Template for sig site

Download 1.06 Mb.

Share with your friends:
1   ...   32   33   34   35   36   37   38   39   ...   65




The database is protected by copyright ©ininet.org 2020
send message

    Main page