At the begining we must state that task was not simple. There were two main problems to solve -- expression evaluator and graph viewer.
This is a standard problem. Solution is usually based on transformation of expression from infix form to binary tree. Calculating the value of the expression then means to progresivelly evalute simple subexpressions from down nodes of the tree to root node of the tree. This can be easily gained by recursion.
We were unpleasantly surprised by overal low quality of expression evaluators. Many of them does not recognize wrong expressions -- we tested behavior of program in cases where there are unbalanced braces in expression and functions without parameters. Also few evaluators crashed with run-time error when expression contains dividing with zero.
In fact, at this part of programm, we were very pleasantly surprised by some solutions. Some programms show graphs rendered and coloured in very beatiful way.
Graphics quality differs from simple wire models, through wire models with hidden unvisible lines to rendered and coloured graphs. We evaluate graphics quality of graph together with speed of rotation.
We have one suggestion to almost every participant. When you use graphics in your programm, link it with graphics engine. For example many of programms used BGI -- but only one or two had BGI linked together with programm into one part (this can be done by using RegisterBGI feature of Borland DOS compilers). We must change path for BGI driver in your programms and recompile them or copy own BGI drivers into same directory as your programm occupies. Same for BGI is true for other libraries. One of participant uses some sort of OpenGL engine for DOS. But he does not include library with solutuion -- he only gave us a link to FTP-server with this library.
Also one programm uses own graphics library. This library we obtain only as .TPU-file. But programm crashs during initialization of graphics in this unit -- we do not have access source code so we can not fix this problem (and we had not time to spent weekend with Advanced FullScreen Debugger to get over this bug). This leads to one good suggestion -- send complete source code of your solution including source of all used libraries. We guarantee you that we use this source of libraries only to evaluate your solution.
Some programms badly interprets rotation. They perform rotations around axes of screen and not around "real" axis of graph. Thus there can be used well-known "floating horizont" method for hidding of invisible lines.
There were big differences. Some programms uses ordinary input from keyboard while other runs under Windows (or DOS-based graphical library) and provide nice user interface. With all pros and cons, it is nearly sure that Microsft Windows are and will be user platform number one. So we think that if you learn how to write programms for Windows you will benefit from it in future.
At the first, we evaluate resistence to bad input of function and intervals. Then we try it with this five functions:
With every functions we try to rotate it around axes and we evaluate graphics quality and speed. Few points you can also get if your programm have good UI (it lets you correct misspelled function for example). We also scan through your source files and evaluate effectivity of your algorithms and "culture" of your code.
We hope that this comments helps you in programming and we hope also in finals of ICP and in next years of ICP and possibly in other programming competitions.
If you do not understand to some part of this comments it is my fault. My English should be better and current time also should be other (now is 1:36 a.m.).
Jiri Kosek
member of jury