[Excuse me for citing a personal message without prior permission.
Also, excuse me for repeating all the same points as in my previous
messages...]

> I think you'll find that the emphasis on symbolic programming in ICFP was
> typical of ICFP rather than the supposed application domain.

I very much expected this response.:-) Indeed ICFP must have put
_more_ emphasis, I suppose, but it is of course just one example.
Also in some other CG programs involving Bezier curves, hidden
line/surface removal, radiosity, polygons, meta balls, etc. etc. that
I wrote, most non-trivial parts were symbolic ones.  The numeric parts
were "mathematics" rather than "programming" - once I solved some
equations, the rest of the work was routine: it was just writing down

  let x = (-. b +. sqrt(b *. b -. 4. *. a *. c)) /. (2. *. a)

or things like that.

Chatting with game/CG professionals around me _strengthened_ this
impression: the symbolic parts seem even more non-trivial in realistic
applications.  For instance, just imagine implementing various kinds
of graphics editors or scripting languages for animation description!

Unfortunately, all of these are mere personal experience and
impression: just I believe that CG programs in the real world are more
symbolic than classroom exercises or laboratory experiments, for the
reasons that I wrote above and in my previous messages.  If somebody
doesn't believe this, I have no more means (and time) to convince
him/her - this is just "FYI".

--
Eijiro Sumii (http://www.yl.is.s.u-tokyo.ac.jp/~sumii/)
Research Associate, Department of Computer Science, University of Tokyo
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners