Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 10,000 papers for “Interactive programming”

Interactive programming

Gesellschaft fuer Informatik e.V., Stuttgart (Germany, F.R.). Fachgruppe Interaktives Programmieren · OpenGrey (Institut de l'Information Scientifique et Technique) · 1980

Cited by 0

Interactive programming

Gesellschaft fuer Informatik e.V., Stuttgart (Germany, F.R.). Fachgruppe Interaktives Programmieren · OpenGrey (Institut de l'Information Scientifique et Technique) · 1980

Cited by 0

Interactive Goal Programming

James S. Dyer · Management Science · 1972

The use of goal programming for the solution of the multiple criteria problem is discussed. An extension of this use is presented in the form of an algorithm which requires interaction with the relevant decision-maker in order to obtain certain information regarding his utility function defined over the permissible values of the criteria. This algorithm provides a bridge between goal programming and recently suggested interactive strategies for the optimization of the multiple criteria problem.

Cited by 223

Interactive Functional Programming

Roland Perera · University of Birmingham Institutional Research Archive (University of Birmingham) · 2013

We propose a new kind of execution environment where applications can be debugged and re-programmed while they are being used. We call our overall concept interactive programming. We develop some of the key components of interactive programming in the setting of a pure, call-by-value functional language. We illustrate our ideas via a proof-of-concept implementation called lambdaCalc, but leave several important components of the overall vision, including efficient incremental update and scaling to large programs, for future work.
\n
\nOur specific achievements are as follows. First, we show how to reify the execution of a program into a live document which can be interactively decomposed into both sequential steps and parallel slices. We give a novel characterisation of forward and backward dynamic slicing and show that for a fixed computation the two problems describe a Galois connection.
\n
\nSecond, we introduce a novel execution indexing scheme which derives execution differences from program differences. Our scheme supports the wholesale reorganisation of a computation via operations such as moves and splices. The programmer is able to see the consequences of edits on the intensional structure of the execution. Where possible, node identity is preserved, allowing an edit to be made whilst an execution is being explored and the changes to be reflected in the user's current view of the execution.

Cited by 7Open access

Interactive Programming by Example

Mikaël Mayer · Infoscience (Ecole Polytechnique Fédérale de Lausanne) · 2017

As of today, programming has never been so accessible. Yet, it remains a challenge for end-users: students, non-technical employees, experts in their domains outside of computer science, and so on. With its forecast potential for solving problems by only observing inputs and outputs, programming-by-example was supposed to alleviate complex tasks requiring programming for end-users. The initial ideas of macro-based editors paved the way to subsequent practical solutions, such as spreadsheet transformations from examples. Finding the right program is the core of the programming-by-example systems. However, users find it difficult to trust such generated programs. In this thesis, we contribute to proving that some forms of interaction alleviate, by having users provide examples, the problem of finding correct and reliable programs. We first report on two experiments that enable us to conjecture what kind of interaction brings benefits to programming-by-example. First, we present a new kind of game engine, Pong Designer. In this game engine, by using their finger, users program rules on the fly, by modifying the game state. We analyze its potential, and its eventual downsides that have probably prevented its wide adoption. Second, we present StriSynth, an interactive command-line tool that uses programming-by-example to transform string and collections. The resulting programs can also rename or otherwise manage files. We obtained the result that confirms that many users preferred StriSynth over usual programming languages, but would appreciate to have both. We then report on two new exciting experiments with verified results, using two forms of interaction truly benefiting programming-by-example. Third, on top of a programmingby- example-based engine for extracting structured data out of text files, in this thesis we study two interaction models implemented in a tool named FlashProg: a view of the program with notification about ambiguities, and the asking of clarification questions. In this thesis, we prove that these two interaction models enable users to perform tasks with less errors and to be more confident with the results. Last, for learning recursive tree-to-string functions (e.g., pretty-printers), in this thesis we prove that questioning breaks down the learning complexity from a cubic to a linear number of questions, in practice making programming-by-example even more accessible than regular programming. The implementation, named Prosy, could be easily added to integrated development environments.

Cited by 0Open access

Interactive programming using PEFPT

Q Wang, Y Yijun, Erik D’Hollander · Ghent University Academic Bibliography (Ghent University) · 1996

Current automatic parallel technology cannot detect and exploit quite a part of parallelism in real Fortran programs, for lack of application specific knowledge and its inaccuracy of dependence analysis.So it is meaningful to investigate the technique and the methodology of interactive parallel programming.In a joint project between the universities of Ghent(B) and Fudan(PRC) called PEFPT (the Parallel Programming Environment for FPT, the Fortran Parallel Transformer), we are developing an integrated toolkit to help scientific programmers to implement correct and efficient parallel programs.

Cited by 1Open access

Towards Interactive Logic Programming

Keehang Kwon, Mi-Young Park · arXiv (Cornell University) · 2012

Linear logic programming uses provability as the basis for computation. In the operational semantics based on provability, executing the additive-conjunctive goal $G_1 \& G_2$ from a program $P$ simply terminates with a success if both $G_1$ and $G_2$ are solvable from $P$. This is an unsatisfactory situation, as a central action of \& -- the action of choosing either $G_1$ or $G_2$ by the user -- is missing in this semantics. We propose to modify the operational semantics above to allow for more active participation from the user. We illustrate our idea via muProlog, an extension of Prolog with additive goals.

Cited by 0Open access

Interactive machine-language programming

Butler Lampson · 1965

The problems of machine language programming, in the broad sense of coding in which it is possible to write each instruction out explicitly, have been curiously neglected in the literature. There are still many problems which must be coded in the hardware language of the computer on which they are to run, either because of stringent time and space requirements or because no suitable higher level language is available.

Cited by 2

Concepts of Interactive Programming

Theodor J. Stewart · International series in management science/operations research/International series in operations research & management science · 1999

Cited by 12

CAMAC and interactive programming

Rimmer, Elsie Margaret · CERN Bulletin · 1973

Interactive programming in a high-level language, such as BASIC, allows simple program generation, modification, and execution, typically through keyboard/printer dialogue. Addition of CAMAC operations to such a system provides excellent facilities for setting- up, debugging and operating CAMAC hardware, and for any non-time- critical CAMAC application. (0 refs).

Cited by 0

Pediatric Interactive Original Programming

Arielle Michele Gelman, Arielle Michele Gelman, Lydia Timmins · 2015

This thesis investigates how pediatric hospitals use and potentially market interactive original programming. More specifically, the research problems regarding selling pediatric interactive original television content included lack of closed-circuit capabilities in some pediatric hospitals, competition for original programming and lack of online presence for programming. Using both qualitative and quantitative and participant observer approaches, the study revealed correlations among variables regarding in-patient interactive entertainment. By researching 167 pediatric hospitals throughout the United States, research showed the importance of positive patient experience in pediatric hospitals, the arts' effect on patient experience and pediatric interactive original programming encourages self-expression and creativity to children in isolation.

Cited by 0Open access

Interactive Programming in Java

Lynn Andrea Stein · 2003

int getValue(); } That's all there is to it. Q. In this definition of Counting, the word abstract appears twice. In the previous definition, above, it doesn't appear at all. Explain. In fact, that was so easy, let's try another interface. This one is Resetable, and it is a very simple interface. (Good interfaces often are.) Resetable has a single method: interface Resetable { abstract void reset(); } This interface is fine, but it could do with a little bit of documentation. After all, 4.3 Interface Declaration 4~13 IPIJ || Lynn Andrea Stein there are many things that an interface doesn't specify. Q. Can you identify some things that should be included in Resetable's documentation? For the precise specification of what may be included in an interface definition, in what order, and under what circumstances, see the Java Chart on Interfaces. 4.3.2 Method Footprints and Unique Names It might seem that each method in an interface would have a unique name. However, it turns out that this isn't the case -at least, not exactly. Instead of a unique name, each method in an interface (or class) definition must have a unique footprint. The method's footprint consists of its name plus its ordered list of parameter types. Only the ordered list of parameter types counts; the return type of the method, and the names given to the parameters, are not relevant to its footprint. For example, a reset() rule with no parameters (an empty parameter list, () ) has a different footprint from a reset( int newValue ) rule (with the parameter list (int) ), and both are different from reset( String resetMessage ) (parameter list (String) ). Only the parameter type matters, though, not the parameter names: reset( String resetMessage ) is the same as reset( String whatToSay ). As long as two methods have different footprints, they can share the same name. This is very common and even has its own name: overloading. Overloading allows an object to have two (or more) similar methods that do slightly different things. For example, there are two very similar mathematical rounding methods. One has the signature int round( float f ); while the other has the signature long round( double d ); The Math object has both of these methods, and if you pass Math.round a float, you get back an int, while if you pass it a double, you get back a long. This is very convenient -in both cases, a floating point number is converted to an integer, but in either case the more appropriate size is used. An alternate kind of overloading might happen if our hypothetical AlarmedCounting interface had, in addition to its void setAlarm( int whatValue, String alarmMessage ) 4~14 Specifying Behavior: Interfaces Chapter 4 IPIJ || Lynn Andrea Stein method, a second method that just allowed you to specify the alarm message, without changing the value for which it was set: void setAlarm( String alarmMessage ) If you called yourAlarm.setAlarm( 1000, Capacity reached ), you'd set the alarm message to trigger at 1000, printing the message Capacity reached. yourAlarm.setAlarm( Oops, all full ) might then be used when to change the warning to be issued when the AlarmedCounting reaches capacity. Overloading method names is the choice of the interface builder. The interface user simply makes use of the interface as it is given. 4.3.3 Interfaces are Types: Behavior Promises Now that we have these interfaces, what good do they do? Interfaces are kinds of Things: they are Java types. In Java, every interface name is automatically a type name. That is, when you are declaring a (label) name, you can declare it suitable for labeling things that implement a specific interface. In the next chapter, we will see how to declare Java classes and how to indicate what interface(s) the class implements. So, for example, the declared type of myCounting, above, was Counting: Counting myCounting; In this example, myCounting is declared to be of type Counting, i.e., something that satisfies the Counting contract (interface) that we declared in the preceding sections. For example, we might have an interface called Game that includes a getScoreCounter() method that returns a Counting: interface Game { abstract Counting getScoreCounter(); // maybe some other method signatures.... } If theWorldCupFinal is a Game, then we might say Counting myCounting = theWorldCupFinal.getScoreCounter(); In this case, we don't know anything more about the type of myCounting ; we just know that it is a Counting. Often, as users of other people's code, interfaces are the only types we need to know about. 4.3 Interface Declaration 4~15 IPIJ || Lynn Andrea Stein 4.3.4 Interfaces are Not Implementations We have seen that an interface can be used as the type of an object. You can use names associated with that type to label the object. You can pass objects satisfying that interface to methods whose parameter types are that interface type, and you can return objects satisfying that interface from a method whose return type is that interface. The Counting in the previous paragraph was an example of the power of interfaces. However, there are certain things that you cannot do with an interface. Of course, when we're manipulating that Counting object, we don't know anything about how it works inside. We don't know, for example, whether it has a touchdown part and a field goal part, or is represented in decimal or in binary, or is likely to keep going up while we're thinking about it (since players might keep scoring). To figure this out, we'd need to know more than just the interface -the contract -that it satisfies; we'd need to know how it is implemented. Interfaces are about contracts, promises. They don't, for example, tell you how to create objects that satisfy those promises. In the next several chapters, we'll learn about building implementations that satisfy these promises and about creating brand new objects that meet these specifications. To do that will require additional machinery beyond the contract/promise of an interface. 4~16 Specifying Behavior: Interfaces Chapter 4 IPIJ || Lynn Andrea Stein Style Sidebar Interface Documentation An interface should be properly documented, typically using a multi-line or javadoc comment immediately preceding its declaration. Documentation for an interface should include the following information: What kind of thing does this interface represent? Why would you want to use an object of this kind? What could it do for you? What could you do with it? What kinds of assumptions or conditions does this kind of object need to do its job? Are there any special objects that it might need to have around or to work with? What services does this kind of object provide, and how do you use them? These questions are typically answered by the individual methods, but a brief overview of what methods the interface provides is always useful. It is may also be useful for the interface to document which method(s) to use when, especially when multiple similar methods exist. The interface's documentation should make it easy for a potential user to find the method(s) s/he wants. It should also make it possible for someone seeking to implement this interface to determine whether s/he has met the intent as well as the formal specification of the interface. If I am building a stopwatch, do I want to subscribe to the Clock interface? Remember that an interface declaration is largely about what, not how. It specifies contracts and promises, not mechanism. Java provides additional support for some of these items in its javadoc utilities. See the appendix on javadoc for details.

Cited by 11

An Interactive Programming Platform

Yuan Ye, Hongxing Liu · 2011

The optimization softwares, on linear programming and nonlinear programming, are making much more difference in social, economic and engineering fields. Most current optimization softwares usually either employ classic local optimization techniques or adopt some global optimization techniques. In this paper, an interactive optimization software with a specially designed evolutionary algorithm, named an interactive optimization platform, is introduced. The key procedure of the platform design is analyzed, and the scheme of the platform is proposed, and finally the platform is implemented. The features of the designed platform include: (1) dynamically adjusting the penalty factor related to the extended objective function at interface, (2) using only two specially designed interactive evolution operators, (3) having a particular mechanism of parallel computing, (4) and a going-back mechanism. With several tests, it was indicated that the implemented platform is easy to use, and can achieve precise solutions stably, having outstanding advantages, and so, the proposed scheme is satisfactory.

Cited by 0