An Algorithmic and Social Introduction to Computer Science (CSC-105 2000S)


How do we balance the need for formal specifications required by program proof techniques and the complexity of modern graphical applications?

Adan

Okay, here goes nothing. Maybe for bigger applications, it is necessary to break them down in smaller and more manageable parts. In doing so, it would probably be easier to prove these smaller parts separately rather than the entire program.

Cathy

I think that in the interest of reliability, a program should have to be outlined by formal specifications, no matter how complex or time consuming that might be. Not that I'd want to do it, but for people who would/could, I think that the payoff would be much better programs. Like an outline for a paper, specs not only structure a program's design and give order to it's complexity, but also provide groundwork for proving that it works.

Ivy

something about the way this question is phrased makes it seem so confusing to me, but if i place it in the context of what we discussed in class, it becomes a little more manageable. well, not really, because i don't think there exists an answer to this question. clearly the "professionals" haven't discovered it because program failures continue, often because this balance has not been achieved. we saw today that proofs are hard, long, painful, and require excessive amounts of formal specifications. if we consider this in the light of the "complexity of modern graphical applications" the thought of proofing all aspects of any program becomes very depressing. i want to say it's not possible but i hesitate to excuse programmers of all responsiblity or accountablity for their work by giving them such an excuse.

Jae

This is a difficult balancing act indeed. More reliable systems can take thousands of man-hours to produce through the process of development and debugging, and it has been noted that even then, the editing of code after it has been developed can lead to further problems due to mistakes in correction. Less reliable systems undermine security for the user, who must constantly take into account the possibility of obtaining inaccurate results. If a program doesn't fulfill its function, then why should we develop it? So, in balancing these two factors, I think that developers need to match the need for system reliability with the projected cost of producing successive levels of reliability in a computer program. The developer must focus in on those areas of program correctness which are most applicable to the creation of a particular reliable program.

Generally, developers are going to have to sell a product--so it has to work--but they need to minimize the cost of production through an effective organization team that can ensure greater levels of program correctness. I think the most important thing to realize here is that these ideas are on a continuum, and program correctness is not absolute in the sense that what might be perfectly reliable for one program may bear no importance in another program. Just because the mathematics of a particular proof work out doesn't mean that the program works great for the purpose it was made.

One idea that has been mentioned is the creation of a more standard program code that has more 'standards' and structural rules so that code will be produced in a more reliable manner to begin with--yet this risks limitations in the applications of a language that is produced in this more absolute fashion.

Jeana

Jeff

The formal specifications, required by program proof techniques, increase the reliability of computers because the algorithm is defined as true, however, the range of functions a program can execute is limited to the formal specifications. This relationship demonstrates itself with respect to graphical applications. The user wants the most latitude and fewest limitations when creating artwork. If the formal specifications were to be too restrictive in limiting the number of functions a modern graphical application has then the application would fail in the marketplace.

Also, if formal specifications were to be implemented on a graphics program, the user is limited to artistic designs and tools that currently exist rather than allowing the user to creatively produce work and tools with which to work

Joel

I feel like the line should be drawn, i.e. formal specifications required by program proof techniques should take precedence over complex graphical applications, when human lives are at potential risk. Like the example you gave today in class - you definitely do not want even a minor bug in a program designed to regulate scuba gear, because it could cost you your life or someone else's life.

However, when human lives are not at stake, I think the balance between proof techniques and the complexity of graphical applications is very gray. It depends on the programmer, I suppose, and how much he/she wants to be sure that his/her program works properly "always" as compared to how much he/she wants his/her program to be really cool (assuming complex graphical or other applications = cool).

I found a couple [of] semi-helpful resources on the Net. I found one site on STL complexity specifications, and although it did not say what "STL" meant, it said that "STL container, algorithm, and concept specifications include asymptotic complexity specifications." The complexity specifications are an over-simplification. I assume this means that the specifications can get infinitely large, but I don't know how that is an over-simplification.

http://infodoc.unicaen.fr/docs/STL_doc/complexity.html

I found another website that gave abstracts of speaches gives at a BRICS Workshop: Proof Theory and Complexity. L. Trevisan of MIT gave a speech called "Interactive and Probabalistic Proof-Checking," and pointed out that "'proofs are easier to check than to find.'" This probably was not a new idea, but it seems important when considering specifications required by program proof techniques because it is good to know to manage time most efficiently. Also, it could possibly lead to a new form of making proofs - guess and check! Trevisan even stated that "checking the validity of a proof has been stretched to a enexpected limits, with surprising and useful consequences that extend beyond the limits of complexity theory."

http://www.brics.dk/Activities/98/PTAC98/ptac98.html

Kevin

I would think the best way to balance this is to stop using proofs. Proofs are evil, and have obviously been co-sponsored by Satan himself. And who needs graphics, anyway? Useless buggers! We could get rid of them, too!

Seriously, though, I think that there really is no way to effectively balance the formal specifications of proofs and deeply graphical applications. I suppose some incredibly intelligent math-type could show me wrong, but the objects required for graphical applications are difficult to use to prove anything, because they don't fit so well into proofs. My best suggestion, however, is to make programs to prove these because, unfortunately, at that level, it seems that proving anything would require more man-hours than is really useful. Therefore, using some sort of proof program would be useful to help in this endeavour.

Liz

Hmmm...I'm not quite sure. I think one solution is what Sam mentioned at the end of class yesterday, and that is the development of a language that makes the specifications easier. While this does make actual programming more difficult, I think there must be a way to have a language that makes the proofs of algorithms easier while also still allowing for freedom in the design of graphical interface.

Sam


Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

This page may be found at http://www.math.grin.edu/~rebelsky/Courses/CS105/2000S/Questions/question.31.html

Source text last modified Wed Feb 16 08:16:04 2000.

This page generated on Wed Mar 15 09:18:37 2000 by Siteweaver. Validate this page's HTML.

Contact our webmaster at rebelsky@grinnell.edu